双向消息传递节俭 [英] Thrift for Bidirectional Messaging
问题描述
我很好奇 Thrift 是否适合我的用例?我正在制作另一个消息传递系统，其中有一个客户端和一个服务器，但是客户端和服务器都向另一个发起请求消息，并不是所有的消息都可能是请求，只是通知.
回到 10 年前，我使用手工制作的基于二进制的编解码器做到了这一点.回到 5 年前，我再次使用 Google Protocol buffers 做到了这一点.但我现在听到更多关于 Thrift 的消息.
Thrift 可以简单地用作编解码器，还是真的围绕请求/回复模式构建?我需要保持传输不可知，因为我将使用自定义消息传递总线、websockets 和可能的 zeromq.
我也在考虑消息包和协议缓冲区，因为我知道它们非常适合非请求/回复消息传递模式.
谢谢.
我只与 Thrift 的 C++ 版本密切合作，所以这个答案是基于此 - 其他语言也可能如此，并且可能不是.
不过，根据我的经验，Thrift 是相当模块化的 - 为您提供了一个完整的堆栈，可以处理 RPC、套接字通信、数据序列化以及基本上介于两者之间的任何事情.
您首先在 Thrift IDL 文件中指定数据结构和服务，其方式类似于在类中指定成员变量(用于数据结构)和成员函数(用于服务)(在 C++/Java/等).您可以使用 Thrift 编译器编译它们以生成特定于语言的源文件，然后您可以在您的应用程序中实现这些源文件.
如果您使用完整的堆栈，那么只需创建必要的对象(服务器、协议、传输等)并打开客户端和服务器之间的连接(服务器实现 IDL 指定的功能)).然后客户端可以调用服务器上的函数，就像服务器是本地对象一样，使用自定义数据结构(或只是一些标准 Thrift 数据类型)作为参数和返回值.
这些函数默认是阻塞的，也就是说，它们在返回之前需要服务器的回答.但是，您也可以将函数指定为 oneway(只要它们返回 void)，在这种情况下，您只需发送函数调用，然后立即继续.>
然而，只有使用完整的 Thrift 堆栈才会出现这种情况.您通过实例化各种对象(协议、传输、处理程序、服务器等)来创建您的客户端和服务器，虽然我自己从未尝试过，但我不明白为什么您不能创建一个例如传输的派生实现，然后使用它而不是 Thrifts 自己的传输.
如果你只是想使用 Thrift 以跨平台的方式定义数据结构，你也可以这样做，然后使用 Thrift 来序列化这些(忽略堆栈的其余部分和 RPC 的东西)，然后通过您自己的传输将这些作为二进制数据发送.
I am curious if Thrift is a good fit for my use case? I am making yet another messaging system, where there is a client and server, but both client and server and initiate a request message to the other, and not all messages may be request, just notifications.
Go back 10 years ago I did this with a hand-rolled binary based codec. Go back 5 years and I did it again using Google Protocol buffers. But I'm hearing more about Thrift now.
Can Thrift be used simply as a codec, or is it really built around the request/reply pattern? I need to remain transport agnostic as I will be using a custom messaging bus, websockets and likely zeromq.
I'm also considering messagepack and protocol buffers as I know they do lend themselves well to non request/reply messaging patterns.
Thanks.
I've only worked closely with the C++ version of Thrift, so this answer is based on that - it might be true for other languages also, and it might not.
From my experience though, Thrift is rather modular - giving you a complete stack that can handle RPC, socket communication, serialization of data, and basically anything inbetween.
You start out by specifying your data structures and services in a Thrift IDL-file, in a way that resembles how you would specify member variables (for data structures) and member functions (for services) in a class (in C++/Java/etc.). You compile these with the Thrift compiler to generate language-specific source files, which you can then implement in your application.
If you use the complete stack, it's then just a matter of creating the necessary objects (servers, protocols, transports, etc.) and open a connection between a client and a server (where the server implements the IDL-specified functions). The client can then call the functions on the server, just as if the server was a local object, using the custom-defined data structures (or just some of the standard Thrift datatypes) as parameters and return values.
The functions are blocking by default, that is, they require an answer from the server before they return. You can however also specify functions as oneway (as long as they return void), in which case you'll just send off the function call, and proceed immediately.
However, all this is only the case if you use the complete Thrift stack. You create your clients and servers by instantiating the various objects (protocols, transports, handlers, servers, etc.), and, although I've never tried it myself, I can't see why you shouldn't be able to create a derived implementation of for instance the transport, and then use that instead of Thrifts own transports.
If you just want to use Thrift to define data-structures in a cross-platform way, you can also do that, then use Thrift for serializing these (ignoring the rest of the stack and the RPC-stuff), and then send these as binary data over your own transport.
这篇关于双向消息传递节俭的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
