Thrift, Avro, Protocolbuffers - Sont-ils tous morts?
Travailler sur un projet animalier (cassandra, spark, hadoop, kafka) nécessite un cadre de sérialisation des données. En vérifiant les trois cadres communs - à savoir Thrift, Avro et Protocolbuffers - j'ai remarqué que la plupart d'entre eux semblent être morts-vivants avec 2 versions mineures par an au plus.
Cela me laisse avec deux hypothèses:
- Ils sont aussi complets qu’un tel cadre devrait être et reste en mode maintenance tant qu’aucune nouvelle fonctionnalité n’est nécessaire.
- Il n’ya aucune raison d’exister pour un tel cadre - je n’explique pas pourquoi. Si oui, quelles sont les alternatives?
Si quelqu'un peut me donner un indice sur mes hypothèses, toute contribution est la bienvenue.
L'avantage de Thrift par rapport à Protobuf est que Thrift offre un cadre complet de RPC et de sérialisation. Plus Thrift prend en charge plus de 20 langues cibles et ce nombre ne cesse de croître. Nous sommes sur le point d'inclure le noyau .NET et le support de Rust sera disponible dans un avenir pas si lointain.
Le fait qu'il n'y ait pas eu autant de rejets de Thrift au cours des derniers mois est sûrement un problème à résoudre, et nous en sommes parfaitement conscients. Par ailleurs, la stabilité générale de la base de code est assez bonne, aussi peut-on créer une fourche Github et couper elle-même une branche à partir du maître actuel - bien entendu avec les mesures de qualité habituelles.
La principale différence entre Avro et Thrift est que Thrift est typé de manière statique, alors qu'Avro utilise une approche plus dynamique. Dans la plupart des cas, une approche statique répond assez bien aux besoins. Dans ce cas, Thrift vous permet de tirer parti des meilleures performances du code généré. Si ce n'est pas le cas, Avro pourrait être plus approprié.
Il convient également de mentionner qu’outre Thrift, Protobuf et Avro, il existe d’autres solutions sur le marché, telles que Capt'n'proto ou BOLT.
Le protocole Buffers est un framework très mature, ayant été introduit pour la première fois il y a près de 15 ans chez Google. Ce n'est certainement pas mort: presque tous les services de Google l'utilisent. Mais après tant d’utilisation, il n’ya probablement pas grand-chose à changer à ce stade. En fait, ils ont publié une version majeure (3.0) cette année, mais la version visait autant à supprimer des fonctionnalités qu’à les ajouter.
Le système RPC associé à Protobuf, gRPC , est relativement nouveau et a eu beaucoup plus d’activité récemment. (Cependant, il est basé sur le système RPC interne de Google, qui a connu environ 12 ans de développement.)
Je ne connais pas autant Thrift ou Avro, mais ils existent aussi depuis un moment.
Concernant l'épargne: autant que je sache, elle est vivante et donne des coups de pied. Nous l'utilisons pour la sérialisation et les API internes où je travaille et cela fonctionne très bien pour cela.
Des éléments manquants tels que le multiplexage de la connexion et des clients plus conviviaux ont été ajoutés dans le cadre de projets tels que Twitter Finagle de Twitter.
Bien que je qualifie notre utilisation de semi-intensive uniquement (c’est-à-dire que nous ne considérons pas les performances en premier: elles devraient être faciles à utiliser et exemptes de bogues avant tout le reste), nous n’avons rencontré aucun problème jusque là.
Donc, en ce qui concerne l'épargne, je dirais que cela entre dans votre première catégorie. [*]
Protocolbuffers est une alternative à la partie sérialisation de thrift, mais il ne fournit pas les offres thrift de la boîte à outils RPC.
Je ne connais aucun autre projet associant RPC et la sérialisation dans un package unique aussi simple à utiliser et complet.
[*] En tout cas, une fois que vous commencez à l'utiliser et que vous voyez tous les avantages, il est difficile de le placer dans votre deuxième catégorie :)
Ils sont tous très utilisés dans de nombreux endroits, je dirais donc votre première hypothèse. Je ne sais pas ce que vous attendez d'un calendrier de publication, mais cela me semble normal pour une bibliothèque de cette taille et de cette maturité. Heck, Avro 1.8.0 est sorti au début de 2016 et la plupart des choses utilisent encore Avro 1.7.7 (par exemple, Spark, Hadoop). https://avro.Apache.org/releases.html