ペットプロジェクト(cassandra、spark、hadoop、kafka)に取り組んでいます。データシリアル化フレームワークが必要です。一般的な3つのフレームワーク(Thrift、Avro、Protocolbuffers)を確認すると、ほとんどの場合、それらのほとんどが1年に2つのマイナーリリースで死んでいるように見えます。
これにより、2つの前提があります。
誰かが私の仮定にヒントをくれるなら、どんな入力でも歓迎です。
Protobufと比較したThriftの利点は、Thriftが完全なRPCおよびシリアル化フレームワークを提供することです。さらに、Thriftは約20以上のターゲット言語をサポートしており、その数はまだ増え続けています。 .NETコアを含めようとしており、近い将来にRustがサポートされます。
過去数か月間にThriftのリリースがそれほど多くなかったという事実は、確実に対処する必要があるものであり、私たちはそれを完全に認識しています。一方、コードベースの全体的な安定性は非常に良好であるため、Githubフォークを実行し、現在のマスターからブランチを独自にカットすることもできます-もちろん、通常の品質尺度で。
AvroとThriftの主な違いは、Thriftが静的に入力されるのに対して、Avroはより動的なアプローチを使用することです。ほとんどの場合、静的アプローチはニーズに非常によく適合します。その場合、Thriftを使用すると、生成されたコードのパフォーマンスが向上します。そうでない場合は、Avroの方が適している可能性があります。
また、Thrift、Protobuf、Avroの他に、Capt'n'protoやBOLTなどのソリューションが市場に出回っていることにも言及する価値があります。
プロトコルバッファは非常に成熟したフレームワークであり、15年前にGoogleで初めて導入されました。確かに死んでいるわけではありません。Google内部のほぼすべてのサービスで使用されています。しかし、あまりにも多く使用した後、おそらくこの時点で変更する必要のあるものはほとんどありません。実際、彼らは今年メジャーリリース(3.0)を行いましたが、リリースは機能の追加と同様に機能の削除に関するものでした。
Protobufに関連付けられているRPCシステム、 gRPC は比較的新しく、最近ではさらに多くのアクティビティがあります。 (ただし、これはGoogleの内部RPCシステムに基づいており、約12年間の開発が行われています。)
私はThriftやAvroについてはあまり知りませんが、彼らもしばらくの間そうです。
Rif約に関して:私が知る限り、それは生きており、蹴っている。私が働いているシリアル化と内部APIに使用し、そのためにうまく機能します。
接続の多重化やよりユーザーフレンドリーなクライアントなどの欠落しているものが、Twitterの Finagle などのプロジェクトを通じて追加されました。
私はそれを半集中的のみとして使用することを特徴づけますが(つまり、パフォーマンスを最初に見ていない:それは使いやすく、他の何よりも前にバグが発生していません)これまでのところ、問題は発生していません。
だから、rif約に関しては、あなたの最初のカテゴリーに分類されると思います。[*]
Protocolbuffersは、thriftのシリアル化部分の代替手段ですが、RPCツールボックスthriftが提供するものではありません。
RPCとシリアル化を、このように使いやすく、完全な単一のパッケージにブレンドする他のプロジェクトを知りません。
[*]とにかく、一度使い始めてすべての利点を確認したら、2番目のカテゴリに入れるのは難しいです:)
それらはすべて非常に多くの場所で使用されているので、最初の仮定を述べたいと思います。リリーススケジュールに対するあなたの期待を私は知りませんが、そのサイズと成熟度のライブラリについては私には普通のようです。ヘック、Avro 1.8.0は2016年の初めにリリースされましたが、ほとんどのものはまだAvro 1.7.7を使用しています(例:Spark、Hadoop)。 https://avro.Apache.org/releases.html