什么时候和为什么使用Thrift比使用简单的套接字/网络编程更好的解决方案？

Question

我想在一个项目中使用Thrift，但是我需要很多理由来解释为什么它比仅仅使用通过网络发送的简单套接字和结构要好。我试图提出的每一个论点都归结于这样一个事实:简单的套接字编程对于小型应用程序来说更容易更快地实现。显然，是否使用它在很大程度上取决于项目，但我的具体情况是在c/c++中与windows服务应用程序( c++或c#)对话的linux应用程序。我试图编译一个优点和缺点的列表(主要是优点)，用于使用节约，而不是仅仅通过套接字发送一个简单的函数。以下是我迄今汇编的关于节俭的信息(我承认其中一些信息可能不准确，或者可能需要我做更多的解释/澄清)(我在http://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html上发现了很多这样的信息)：

另一种RPC和序列化框架选项，即由一个用于处理分布式对象通信/RPC和序列化的库和一个编译器组成。节俭是Apache license 2.0下的一个免费的开放源代码框架，它允许软件用户可以自由地使用软件用于任何目的、分发软件、修改软件以及根据许可条款分发修改后的软件版本，而不必担心版税。此外，它还可以与GPL3.0授权内容相结合，只要许可证的组合工作也是GPL3.0。节俭是一个相当新的框架，它起源于Facebook开发的RPC框架，然后作为开源发布。它自2008年前后就已经存在，并且拥有一个蓬勃发展的用户群体。 在默认情况下，节俭使用行业标准JSON或其他内置的协议选择来定义数据类型和协议；但是，它也支持自定义的备用接口描述语言。节约库本身可以用多种语言(与平台无关)编译，而Thrift编译器可以从多种语言的接口/配置文件中自动生成类、服务器、客户端和存根/骨架代码。节俭有阻塞/非阻塞服务器选项可供选择。如果使用的话，将需要编写有限的网络代码，因为所有这些代码都包括在内。需要编写IDL文件来定义用于序列化/反序列化的数据包数据/命令。 节俭支持以下基本类型：

• 布尔值:布尔值(真或假)
• 字节:一个8位有符号整数。
• i16: 16位有符号整数
• i32: 32位有符号整数
• i64: 64位有符号整数
• 双:64位浮点数
• 字符串:使用UTF-8编码的文本字符串。

和下列复杂类型：

• 记录
• 结构
• 容器
• 例外情况
• 服务

节约支持长期模式演化，它允许对模式(例如新字段和数据类型/属性)进行修改，而不会丢失旧接口文件之间的任何向后兼容性。当然，客户机/服务器逻辑仍然需要修改，以支持模式更改带来的新特性。消息/命令被标记为标识符，因此接收端可以将它们与架构匹配。在编译中需要一个额外的步骤来编译存根/骨架代码来处理接口文件中定义的消息。

在模式更改(允许软件更新而不破坏旧的现场系统)、独立于平台、不需要编写任何代码的RPC和服务器之间，除了如何处理客户机和服务器之间来回发送的命令/数据之外，使用Thrift还可以实现向后兼容。

Answer 1

当然，节俭是好的，但不是所有的项目。好处：

• 节省异步套接字编程:在异步引擎中，只有一种方法可以工作，在节俭中，您可以选择最适合您的方法(单线程、并行或异步)
• 节俭是一个框架。你少写样板代码。您不实现传输、协议等。
• 节俭是以定义为基础的，这些定义形成了一种自我文档。当新的人加入你的团队时，这在大型项目中非常有用。看一看这些定义，您就可以了解系统内部的内容。
• 节俭支持20多种语言。这意味着，如果您已经有了一个节俭定义文件，就可以提供所有的语言客户端。此外，如果您想要更改服务器的平台(例如c++、->、java或其他什么)，那么这对所有基础设施都是自动透明的(更少的工作了)。

缺点：

• 节约略慢于谷歌的原型缓冲区(基准测试表明，它是10%，无论是TBinary协议还是TCompact协议)
• 节俭永远比不上像boost::asio或python的扭曲这样的专用异步引擎。它不是为这个笨蛋设计的。

来总结--如果您需要通过api提供具有复杂功能的服务，那么节约是一个不错的选择。此外，如果您需要在不同的平台上有客户，节俭是一个很好的选择。但是如果你需要一个非凡的表现，你可以把它和protobuf进行比较。如果您需要提供非常简单的结构(计算可能很复杂，但传输本身很容易)，那么就考虑boost:asio，扭曲或类似的东西。

您可以看看我关于节俭的演讲，有一节是关于好处和限制的。

Answer 2

很难从你的课文中提取出一个问题，或者更好的“问题”。这一切归结为“我是否应该使用高级别框架？”，然后是一些避免高级别框架的理由，因为从零开始实现它要容易得多。

在我看来，这种方法听起来更喜欢汇编程序，而不是3GL+语言，因为这些编译器倾向于生成100 k二进制文件，在这些二进制文件中，汇编程序专家在10k中也会这样做，而特性则是前者的两倍。

在这两种情况下，如果该产品工作并满足所有的要求，那么它是好的，无论你怎么做。那么什么才是好的决策基础呢？

当今软件开发的关键是生产力，以及生产力的核心:稳定性、可维护性(尤其是源代码的可访问性)和更改或扩展事物的灵活性。

如果汇编程序专家是唯一一个理解他的代码的人，或者如果他需要三周而不是五天来完成它，那么很可能您有问题。

你想从二进制切换到JSON吗？您希望使用另一个结构的另一个API调用，以及Foobar结构中的另外两个字段？您需要将传输从套接字更改为HTTP吗？您希望通过一些MQ系统连接模块，但尽可能保留它们之间的逻辑接口？你希望你的新同事在原始套接字编程方面没有你所拥有的那么多经验，去做这件事？考虑到这些目标而设计的高级别框架可以使这些更改变得非常容易。

另一方面，你选择的框架可能无法满足你当前的特殊需求，这是有一定风险的。因此，这或多或少是一种权衡，但在大多数情况下，与投资相比，你从中得到的好处要多得多。

关于C++/C#在Windows和Linux上的连接问题:这正是Apache设计的场景之一。