Thrift が私のユースケースに適しているかどうか知りたいですか? クライアントとサーバーがあり、クライアントとサーバーの両方が他方への要求メッセージを開始し、すべてのメッセージが要求ではなく、通知だけである可能性がある、さらに別のメッセージングシステムを作成しています。
10 年前にさかのぼると、手作業でバイナリ ベースのコーデックを使用してこれを行いました。5 年前にさかのぼって、Google プロトコル バッファを使用してもう一度やり直しました。しかし、Thrift のことをよく耳にするようになりました。
Thrift は単純にコーデックとして使用できますか? それとも、本当に要求/応答パターンを中心に構築されていますか? カスタム メッセージング バス、websocket、およびおそらく zeromq を使用するため、トランスポートにとらわれないままにする必要があります。
メッセージパックとプロトコル バッファも、非要求/応答メッセージ パターンに適していることがわかっているため、検討しています。
ありがとう。
私はThriftのC++バージョンと密接に連携しただけなので、この回答はそれに基づいています.他の言語にも当てはまるかもしれませんし、そうでないかもしれません.
ただし、私の経験から言えば、Thrift はかなりモジュール化されており、RPC、ソケット通信、データのシリアル化、および基本的にその間のすべてを処理できる完全なスタックを提供します。
クラス (C++/Java/etc) でメンバー変数 (データ構造用) とメンバー関数 (サービス用) を指定する方法に似た方法で、Thrift IDL ファイルでデータ構造とサービスを指定することから始めます。 .)。これらを Thrift コンパイラでコンパイルして言語固有のソース ファイルを生成し、それをアプリケーションに実装できます。
完全なスタックを使用する場合は、必要なオブジェクト (サーバー、プロトコル、トランスポートなど) を作成し、クライアントとサーバー (サーバーが IDL で指定された関数を実装する場所) の間の接続を開くだけです。クライアントは、サーバーがローカル オブジェクトであるかのように、カスタム定義されたデータ構造 (または標準の Thrift データ型の一部) をパラメーターおよび戻り値として使用して、サーバー上の関数を呼び出すことができます。
関数はデフォルトでブロックされています。つまり、返される前にサーバーからの応答が必要です。ただし、関数をoneway(返される限りvoid) として指定することもできます。その場合、関数呼び出しを送信して、すぐに続行します。
ただし、これは完全な Thrift スタックを使用する場合にのみ当てはまります。さまざまなオブジェクト (プロトコル、トランスポート、ハンドラー、サーバーなど) をインスタンス化することによってクライアントとサーバーを作成します。たとえば、トランスポートの派生実装を作成し、Thrift 独自のトランスポートの代わりにそれを使用します。
Thrift を使用してクロスプラットフォームの方法でデータ構造を定義したいだけの場合は、Thrift を使用してこれらをシリアライズし (残りのスタックと RPC を無視して)、これらを次のように送信します。独自のトランスポートを介したバイナリ データ。