远程过程调用(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风格的服务。这样,外部客户也可以使用该电商的一些核心服务(如快递服务)