微服务学习笔记-开源RPC框架

一、PRC框架分类

RPC框架主要分为两类：

跟某种特定语言平台绑定，主要有：

• Dubbo：国内最早开源的RPC框架，由阿里巴巴公司开发并于2011年末对外开源，仅支持Java语言。
• Motan：微博内部使用的RPC框架，于2016年对外开源，仅支持Java语言
• Tars：腾讯内部使用的RPC框架，于2017年对外开源，仅支持C++语言
• Spring Cloud：国外 Pivotal 公司 2014 年对外开源的 RPC 框架，仅支持 Java 语言

与语言无关即跨语言平台，主要有：

• gRPC：Google 于 2015 年对外开源的跨语言 RPC 框架，支持常用的 C++、Java、Python、Go、Ruby、PHP、Android Java、Objective-C 等多种语言。
• Thrift：最初是由 Facebook 开发的内部系统跨语言的 RPC 框架，2007 年贡献给了Apache 基金，成为 Apache 开源项目之一，支持常用的 C++、Java、PHP、Python、Ruby、Erlang 等多种语言。

二、限定语言平台的开源RPC框架

1、Dubbo

 架构如图所示，Dubbo的架构主要包含四个角色，Consumer是服务消费者，Provider是服务提供者，Registry是注册中心，Monitor是监控系统。

具体的交互流程是Consumer一端通过注册中心获取到Provider节点后，通过Dubbo的客户端SDK与Provider建立连接，并发起调用。Provider一端通过Dubbo的服务端SDK接收到Consumer的请求，处理后再把结果返回给Consumer 

看出服务消费者和服务提供者都需要引入 Dubbo 的 SDK 才来完成 RPC 调用，因为Dubbo 本身是采用 Java 语言实现的，所以要求服务消费者和服务提供者也都必须采用Java 语言实现才可以应用。

Dubbo的调用框架是如何实现的：

• 通信框架方面，Dubbo默认采用了Netty作为通信框架。
• 通信协议方面，Dubbo除了支持私有的Dubbo协议外，还支持RMI协议、Hession协议、HTTP协议、Thrift协议
• 序列化格式方面，Dubbo支持多种序列化格式，比如Dubbo、Hession、JSON、Kryo、FST等

2、Motan

 

Motan与Dubbo的架构类似，都需要在Client端（服务消费者）和Server端（服务提供者）引入SDK，其中Motan框架主要包含下面几个功能模块。

• register：用来和注册中心交互，包括注册服务、订阅服务、服务变更通知、服务心跳发送等功能。Server端会在系统初始化时通过register模块注册服务，Client端会在系统初始化时通过register模块订阅到具体提供服务的Server列表，当Server列表发生变更时也由register模块通知Client。
• protocol：用来进行RPC服务的描述和RPC服务的配置管理，这一层还可以添加不同功能的filter用来完成统计、并发限制等功能
• serialize：将RPC请求中的参数、结果等对象进行序列化与反序列化，即进行对象与字节流的互相转换，默认使用对Java更友好的Hessian2进行序列化。
• transport：用来进行远程通信，默认使用Netty NIO进行TCP长链接方式。
• cluster：Client端使用的模块，cluster是一组可用的Server在逻辑上的封装，包含若干可以提供RPC服务的Server，实际请求会根据不同的高可用与负载均衡策略选择一个可用的Server发起远程调用。

3、Tars

 

Tars的架构交互主要包括一下几个流程：

• 服务发布流程：在web系统上传server的发布包到patch，上传成功后，在web上提交发布server请求，由register服务传达到node，然后node拉去server的发布包到本地，拉起server服务
• 管理命令流程：web 系统上的可以提交管理 server 服务命令请求，由 registry 服务传达到 node 服务，然后由 node 向 server 发送管理命令。
• 心跳上报流程：server 服务运行后，会定期上报心跳到 node，node 然后把服务心跳信
  息上报到 registry 服务，由 registry 进行统一管理。
• 信息上报流程：server 服务运行后，会定期上报统计信息到 stat，打印远程日志到log，定期上报属性信息到 prop、上报异常信息到 notify、从 config 拉取服务配置信息。
• client 访问 server 流程：client 可以通过 server 的对象名 Obj 间接访问 server，client会从 registry 上拉取 server 的路由信息（如 IP、Port 信息），然后根据具体的业务特性（同步或者异步，TCP 或者 UDP 方式）访问 server（当然 client 也可以通过 IP/Port直接访问 server）。

4、Spring Cloud

 Spring Cloud 是为了解决微服务架构中服务治理而提供的一系列功能的开发框架，它是完全基于 Spring Boot 进行开发的，Spring Cloud 利用 Spring Boot 特性整合了开源行业中优秀的组件，整体对外提供了一套在微服务架构中服务治理的解决方案。因为 SpringBoot 是用 Java 语言编写的，所以目前 Spring Cloud 也只支持 Java 语言平台，它的架构图可以用下面这张图来描述。

Spring Cloud微服务架构由多个组件组成的，各个组件的交互流程如下：

• 请求统一通过API网关Zuul来访问内部服务，先经过Token进行安全认证。
• 通过安全认证后，网关Zuul从注册中心Eureka获取可用服务节点列表。
• 从可用服务节点中选取一个可用节点，然后把请求分发到这个节点。
• 整个请求过程中，Hystrix组件负责处理服务超时熔断，Turbine组件负责监控服务间的调用和熔断相关指标，Sleuth组件负责调用链监控ELK负责日志分析。 

 5、对比选型

4 种限定语言的开源 RPC 框架后，我们该如何选择呢？

如果你的语言平台是 C++，那么只能选择 Tars；而如果是 Java 的话，可以选择Dubbo、Motan 或者 Spring Cloud。这时你又要问了，它们三个又该如何抉择呢？

仔细分析，可以看出 Spring Cloud 不仅提供了基本的 RPC 框架功能，还提供了服务注册组件、配置中心组件、负载均衡组件、断路器组件、分布式消息追踪组件等一系列组件，也难怪被技术圈的人称之为“Spring Cloud 全家桶”。如果你不想自己实现以上这些功能，那么 Spring Cloud 基本可以满足你的全部需求。而 Dubbo、Motan 基本上只提供了最基础的 RPC 框架的功能，其他微服务组件都需要自己去实现。不过由于 Spring Cloud 的 RPC 通信采用了 HTTP 协议，相比 Dubbo 和 Motan 所采用的私有协议来说，在高并发的通信场景下，性能相对要差一些，所以对性能有苛刻要求的情况下，可以考虑 Dubbo 和 Motan。

三、跨语言平台的开源RPC框架

1、gRPC

 原理是通过 IDL（Interface Definition Language）文件定义服务接口的参数和返回值类型，然后通过代码生成程序生成服务端和客户端的具体实现代码，这样在 gRPC 里，客户端应用可以像调用本地对象一样调用另一台服务器上对应的方法。

主要特性包括三个方面：

• 通信协议采用了 HTTP/2，因为 HTTP/2 提供了连接复用、双向流、服务器推送、请求优先级、首部压缩等机制，所以在通信过程中可以节省带宽、降低 TCP 连接次数、节省CPU，尤其对于移动端应用来说，可以帮助延长电池寿命。
• IDL 使用了ProtoBuf，ProtoBuf 是由 Google 开发的一种数据序列化协议，它的压缩和传输效率极高，语法也简单，所以被广泛应用在数据存储和通信协议上。
• 多语言支持，能够基于多种语言自动生成对应语言的客户端和服务端的代码。

2、Thrift

 Thrift 是一种轻量级的跨语言 RPC 通信方案，支持多达 25 种编程语言。为了支持多种语言，跟 gRPC 一样，Thrift 也有一套自己的接口定义语言 IDL，可以通过代码生成器，生成各种编程语言的 Client 端和 Server 端的 SDK 代码，这样就保证了不同语言之间可以相互通信。它的架构图可以用下图来描述。

 Thrift RPC 框架的特性：

• 支持多种序列化格式：如 Binary、Compact、JSON、Multiplexed 等。
• 支持多种通信方式：如 Socket、Framed、File、Memory、zlib 等。
• 服务端支持多种处理方式：如 Simple 、Thread Pool、Non-Blocking 等。

3、对比选型 

 从成熟度上来讲，Thrift 因为诞生的时间要早于 gRPC，所以使用的范围要高于 gRPC，在HBase、Hadoop、Scribe、Cassandra 等许多开源组件中都得到了广泛地应用。而且Thrift 支持多达 25 种语言，这要比 gRPC 支持的语言更多，所以如果遇到 gRPC 不支持的语言场景下，选择 Thrift 更合适。

但 gRPC 作为后起之秀，因为采用了 HTTP/2 作为通信协议、ProtoBuf 作为数据序列化格式，在移动端设备的应用以及对传输带宽比较敏感的场景下具有很大的优势，而且开发文档丰富，根据 ProtoBuf 文件生成的代码要比 Thrift 更简洁一些，从使用难易程度上更占优势，所以如果使用的语言平台 gRPC 支持的话，建议还是采用 gRPC 比较好。