微服务架构中的HTTP vs Thrift

Question

我刚刚开始学习微服务，我有一个问题，我无法自己回答。 （我也是一名基于Java的开发人员）

我有这样的情况：

1. 我有服务A（API服务）调用Thrift服务（命名为T1）获取数据。

2. 然后我有一个服务B，它可以使用来自A的数据响应，解析这些数据，然后生成一些新数据，最后，将它返回给客户端。

问题是：我应该使用哪种？ B从A调用API并解析（例如JSON数据）与HttpClient / AsyncHttpClient连接池或B直接调用T1并重复A做什么？

恕我直言，我认为Thrift（连接池也是）比HTTP调用更快？ 我对吗？

我看到很多使用HTTP的内部服务，如弹性搜索，Neo4j，Eureka Netflix等......

那么，我应该使用哪一个？ 为什么HTTP如此受内部使用而不是像Thrift，ProtoBuf那样的RPC，......？

对不起，我的英语不好。 先感谢您。

Answer 1

通常使用HTTP和JSON或XML，因为它们是平台和语言无关的。 HTTP API允许ReSTful架构，该架构已被证明是用于开发分布式系统的可扩展模型。

从历史上看，基于RPC的分布式系统方法已经显示出许多弱点：

• 通常他们是语言依赖的。 Thrift和Protobuf更具互操作性，但它们依赖于相当具体的第三方库。 相比之下，HTTP客户端和XML或JSON数据绑定/处理器有许多实现。

• 通过将客户端和服务器升级捆绑在一起可能变得困难 - 客户端通常必须与服务器同时升级。 在真正的分布式网络中，这是不可能的。

• RPC在分布式系统中通常不是一个很好的比喻。 通过将网络抽象为实现问题，他们经常鼓励低级“聊天”接口，这些接口要么涉及过多的网络流量，要么对不可靠的网络不具有弹性。

• 当出现问题时，二进制传输格式更难分析/调试。

出于这些原因，人们倾向于选择基于HTTP的Rest-over API而不是专有的RPC API。