第6章 分布式服务调用中间件

远程过程调用（Remote Proredure Call, RPC）是一种非常传统的技术，通过它，可以跨进程、跨机器（操作系统可以相同，也可以不同）进程过程调用

6.1 分布式服务调用中间件简介

• RPC的基础是序列化（marshalling）和反序列化（unmarshalling），因为一切RPC消息、参数、返回值和异常等都需要被序列化后才能跨节点传递。
• gRPC是谷歌公司根据自己的原有产品Protocol Buffers的基础上，开发并开源的产品。
• Thrift是Facebook为了解决不同语言（PHP、Python、C++等）写的大量服务之间的通信问题而开发的
• 阿里巴巴在RPC基础上，还需要对服务进行管理（即所谓的服务治理），开发Dubbo/DubboX和Motan
• 百度sofa-pbrpc，解决内网中大量的异步调用问题，采用epoll+Protocol Buffers

6.2 分布式服务调用中间件的实现原理

Dubbo是阿里巴巴开源的、基于Java的著名“RPC+分布式服务治理”框架。

6.2.1 Dubbo的架构

• Dubbo服务器：对外提供服务的组件，服务由Java语言的接口描述。
• Dubbo客户端：Dubbo服务的消费者
• 服务注册中心：所有的Dubbo服务必须先向服务注册中心注册
• 服务监控中心：服务端与客户端每隔一定时间，就将一些监控信息（如某个方法的调用次数、调用时消耗的时长等）发给服务监控中心

6.2.2 Dubbo中各组件的交互

• 1.Dubbo服务器端启动后向服务注册中心它提供的服务列表
• 2.Dubbo客户端向服务注册中心查询提供某个服务的服务端列表
• 3.服务注册中心返回服务提供者的地址列表给Dubbo客户端，如果有变更，服务注册中心将采用长链接推送变更数据给消费者
• 4.Dubbo客户端从服务提供者地址列表中，基于某种软负载均衡算法，选一个提供者进行调用，如果调用失败，就选另一个重试
• 5.Dubbo服务端将执行结果返回给Dubbo客户端
• 6.Dubbo客户端和服务端，在内存中累计调用次数和调用时长，每隔一段时间就发送一次统计数据给服务监控中心。

6.2.3 Dubbo的实现及特点

• Dubbo仅支持Java语言
• Dubbo与Spring的集成非常好
• Dubbo的服务注册中心支持ZooKeeper、Redis和IP多播
• Dubbo支持多种负载均衡机制：随机（random）、轮询（round robin）、最少活跃调用数（least active）、一致性哈希（consistent hash）

6.2.4 Dubbox

Dubbox是当当网开源的基于Dubbo的升级版

• 支持REST风格的远程调用（HTTP+JSON/XML）:
• 有了REST调用支持，Dubbo就可以支持REST风格的“微服务”
• 支持基于Kryo和FST的Java高效序列化实现，显著提高了Dubbo RPC的性能

6.3 其他分布式服务调用中间件

6.3.1 Protocol Buffers

谷歌的Protocol Buffers 是在RPC中常用的一种序列化和反序列化库，与语言和平台无关。

6.3.2 gRPC

• Protocol Buffers 只解决了数据的序列化和反序列化问题，要想使用RPC，还得有个框架，以解决消息的发送、解析、路由、线程管理等一系列问题。
• gRPC是谷歌开源的、基于Protocol Buffers的优秀的RPC调用中间件
• gRPC可以很好地解决企业内部服务间的通信问题。
• grpc-gateway可以解决外部客户通过REST服务来调用内部的gRPC服务

6.3.3 Thrift

Facebook为了解决不同语言之间的RPC问题。

6.3.4 Motan

是新浪微博开源的一个与Dubbo/Dubbox非常类似的RPC框架

6.3.5 sofa-pbrpc

百度采用“epoll+线程池”方式，因此对高吞吐、低延迟、高并发连接数的场景支持的非常好

6.4 分布式服务调用中间件的应用

• 下半部分使用gRPC实现的各个核心业务，每个都是独立的微服务，拥有自己的缓存、自己的存储和自己的开发团队。
• 上半部分运行在Web服务器中：gRPC服务的REST代理是一些微服务的REST包装，使用grpc-gateway实现，对外部客户提供REST风格的服务。这样，外部客户也可以使用该电商的一些核心服务（如快递服务）