微服务架构中的HTTP vs Thrift

Lie*_* Le 6 java microservices

我刚刚开始学习微服务,我有一个问题,我无法自己回答.(我也是一名基于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,......?

对不起,我的英语不好.先感谢您.

sis*_*hus 8

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

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

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

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

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

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

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