与使用简单的套接字/网络编程相比，何时以及为什么使用Thrift会是更好的解决方案？

Question

我想将Thrift用于一个项目，但是我有很多理由，为什么它比仅使用通过网络发送的简单套接字和结构更好。我试图做出的每一个论点总是归结为这样一个事实，即对于小型应用程序而言，简单的套接字编程更容易实现。显然，是否使用它很大程度上取决于项目，但是我的情况尤其是与Windows服务应用程序（c ++或c＃）对话的c / c ++中的linux应用程序。我正在尝试编译使用节俭的利弊列表（主要是利弊），而不只是通过套接字发送简单的函数。这是我到目前为止收集的关于节俭的信息（我承认其中一些可能不准确，或者我可能需要更多的解释/说明）（我发现了许多此类信息）http://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html）：

Thrift是另一个RPC和序列化框架选项，由用于处理分布式对象通信/ RPC和序列化的库和一个编译器组成。Thrift是Apache License 2.0下的一个免费的开放源代码框架，该框架允许软件的用户自由地出于任何目的使用该软件，对其进行分发，对其进行修改以及在该版本下分发该软件的修改版本。许可条款，无需担心使用费。此外，只要合并作品的许可也是GPL 3.0，它就可以与GPL 3.0许可的内容结合。Thrift是一个相当新的框架，它起源于Facebook开发的RPC框架，然后作为开源发布。它自2008年左右开始存在，并拥有一个繁荣的用户社区。

默认情况下，Thrift使用行业标准JSON或其他内置协议选择来定义数据类型和协议；但是，它也支持自定义的备用接口描述语言。Thrift库本身可以以多种语言（独立于平台）进行编译，并且Thrift编译器可以从界面/配置文件以多种语言自动生成类，服务器，客户端和存根/骨架代码。Thrift具有阻止/阻止服务器选项供您选择。如果使用Thrift，则需要编写受限的网络代码，因为所有代码都包含在内。需要编写IDL文件来定义用于序列化/反序列化的数据包数据/命令。

Thrift支持以下原始类型：

• bool：布尔值（正确或错误）
• 字节：8位有符号整数
• i16：16位有符号整数
• i32：32位有符号整数
• i64：64位有符号整数
• double：64位浮点数
• 字符串：使用UTF-8编码编码的文本字符串

以及以下复杂类型：

• 记录
• 结构
• 货柜
• 例外情况
• 服务

Thrift支持长期的模式演变，这允许修改模式（例如新字段和数据类型/属性）而不会丢失旧接口文件之间的任何向后兼容性。当然，仍然需要修改客户端/服务器逻辑以支持架构更改中的新功能。消息/命令用标识符标记，因此接收端可以将它们与模式匹配。编译存根/骨架代码以处理接口文件中定义的消息时，需要执行额外的编译步骤。

使用Thrift可在模式更改（允许软件更新而不会破坏较旧的现场系统），平台独立性以及无需编写任何代码（无需处理之间的来回命令/数据）的嵌入式RPC和服务器之间实现向后兼容性。客户端和服务器。

Answer 1

当然，节俭是件好事，但不适用于所有项目。优点：

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

缺点：

• 节俭比Google的protobuffers慢一些（基准测试表明它是TBinary或TCompact协议的10％）
• 节俭永远不会击败诸如boost :: asio或python的twitter这样的专门异步引擎。它不是为这种小女孩设计的。

综上所述 -如果您需要通过api提供具有复杂功能的服务，节俭是一个不错的选择。此外，如果您需要在不同平台上拥有客户，节俭是一个不错的选择。但是，如果您需要出色的性能，请将其自己与protobuf进行比较。而且，如果您需要使用非常简单的结构（计算可能很复杂，但是传输本身很简单），则可以考虑使用boost :: asio，类似扭曲的东西。

您可以看一下我关于节俭的演讲，其中一节介绍了好处和限制。

Answer 2

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

对我来说，这种方法听起来很像更喜欢汇编程序而不是 3GL+ 语言，因为这些编译器往往会生成 100k 二进制文件，而汇编程序大师会在 10k 中执行相同的操作，但具有两倍的功能。

无论哪种情况，如果产品有效并满足所有要求，那么无论您是如何做到的，都可以。那么什么是一个好的决策基础呢？

当今软件开发的关键是生产力，以及生产力的必然结果：稳定性、可维护性（特别是源代码的可访问性）以及更改或扩展事物的灵活性。

如果汇编大师是唯一理解他的代码的人，或者如果他需要三周而不是五天来完成它，那么很可能你遇到了问题。

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

另一方面，总是存在一定的风险，即您选择的框架可能无法满足您当前的特定需求，这是正确的。因此，这或多或少是一种权衡，但在大多数情况下，与您的投资相比，您从中获得的收益要多得多。

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