RPC（远程服务调用）框架是现代互联网公司中最基础、最关键的微服务技术架构组件，它涉及到微服务的注册和发现、高可用、服务治理、服务监控，直接关系到应用服务的研发流程，对持续交付和运维直接相关联，是一个牵一发而动全身的基础技术组件。如何选择和设计好一个RPC框架，是一个互联网公司微服务技术架构中的百年大计工程。
本文对业界开源RPC框架的调研基础上，分析RPC框架的技术架构和各个关键技术模块组成，同时对各个RPC框架进行了相关技术需求数据的收集，以帮助考察对比各个RPC框架的技术参数。
- 阿里的Dubbo，开源于2011年10月
- 微博的Motan，开源于2016年5月
- Spring Cloud，开源于2014年10月
由于Spring Cloud的目标也是实现微服务架构，提供很多相关的组件，在RPC框架对比中，我们也将其加入了分析行列。
但是，本文并没有将gRpc/Thrift加入对比行列，主要是这两个框架更多关注跨语言的服务调用，不提供服务治理功能，所以对微服务技术架构无法全面支持。而本文主要是讨论能够支撑微服务架构落地的RPC框架及其技术架构。
最后讨论当前各个主流RPC框架所面临的问题，及其未来5-10年Service Mesh在引领RPC框架上的创新变化。
1. RPC架构
一个典型的RPC架构如下图所示，
它包括了如下几个组件，
- 服务提供者：远程服务的被调用方，提供服务实现。
- 服务消费者：远程服务的调用方。
- 注册中心：提供服务的注册和发现。
- 调用监控：监控远程服务调用情况。
在服务提供者/消费者内部，一般会包括如下5个组件，
- proxy：服务接口代理，将服务接口的本地调用转接为远程调用。
- service：服务的定义，这个Service的定义决定了支持的服务粒度。在Dubbo和Motan的缺省实现中，一个Service被定义为一个服务类实例的一个方法（Method），通过反射的方式调用服务的Method。
- register：服务的注册和发现，在服务启动时，注册服务URL地址到注册中心，启动后会定时从注册中心获取最新服务列表。
- protocol：对RPC的封装抽象，主要包含两个功能：一个服务导出（exporter），用于服务提供者，将服务导出并注册URL，RPC时获取服务定义并调用实现；还有就是服务引用（referer），用于服务消费者，获取远程服务URL并发起RPC。
- transport：远程服务通信层，里面包括用于远程通信的服务器端和客户端，常见使用的有Netty/Apache Mina/Grizzly等网络通信框架，简单的有直接使用OkHttp/Unirest进行Http通信。
上述是RPC的典型架构，各个RPC框架基本上都提供了上述RPC架构的各个组件，不一样之处在于语言实现及其相关组件模块。
2. RPC框架组件
业界的RPC框架百花齐放，种类繁多，各个RPC框架基本上都实现了上述典型RPC架构，不一样之处在于实现，比如，
- 不同的实现语言，比如Java语言的Dubbo和Motan，Go语言的rpcx等等
- 支持不同的注册中心，从consule、zookeeper、eureka、自带注册中心等
- 服务提供者和消费者的架构组件
其中RPC框架在服务提供者和消费者的架构组件上的实现，最能体现其框架对微服务架构的功能支持粒度和深度。
下面两个图主要列出了Dubbo和Motan的服务提供者和消费者架构组件，对比其实现模块，可以看到，两者的基本模块主要还是围绕着Service/Proxy/Protocol/Transport进行展开。理解这两个图对于解读Dubbo和Motan的开源代码会有帮助。
2.1 Dubbo的架构实现
2.2 Motan的架构实现
2.3 一个RPC框架的简单实现
请点击这里查看一个RPC的简单演示项目，也可以通过如下命令克隆项目代码到本地。
git clone git@gitee.com:pphh/simple-rpc.git
这个演示项目参考motan/dubbo的架构实现，以尽量简洁的方式演示一个RPC框架中所使用的核心组件技术，包括，
- 服务提供方和消费方实现
- 服务的注册和发现机制
- 服务集群的高可用和负载均衡
- 远程调用的底层通信实现
- 等等。
3. RPC的技术需求分析
一个远程服务调用的开发和上线，按流程先后顺序会接触到，
- 服务定义
- 服务开发
- 服务调用
- 服务通信
- 服务监控运行
下面将从这几个方面逐一分析RPC框架所涉及的各项技术需求。
1）服务的定义
RPC是一个两方（消费方和提供方）的通信调用关系，这需要在两方之间建立一个通信契约，服务定义就是实现这个目的。服务定义的内容主要包括服务名、入参请求和出参响应。
gRpc/Thrift是以一个规范的文件格式定义服务，
syntax = “proto3”;
package helloworld;
// The greeting service definition.
Service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply) {}
}
message HelloRequest {
string name = 1;
}
message HelloReply {
string message = 1;
}
而Dubbo和Motan则使用Java Interface的形式。
Public interface Greeter {
String sayHello(String name);
}
好的服务定义方式能够简洁清除地表达服务名、入参请求和出参响应，方便服务的开发和调用，服务的定义对服务的版本升级兼容也应有相应的考虑。
2）服务的开发
在服务定义好了之后，马上服务提供者需要根据定义进行服务的开发。
大多数RPC框架都对服务的开发进行了非常友好的支持，例如gRpc/Thrift提供代码的自动生成，开发者只需要继承生成的服务基类，添加相应的逻辑代码即可，Dubbo和Motan由于直接使用Java Interface，开发也是非常容易。
下面是一个Java语言服务的开发，其实现了Greeter Interface所定义的服务接口，
public class GreeterImpl implements Greeter {
public String sayHello(String name) {
return “Hello “ + name;
}
}
服务的开发一般需要考虑编程语言的支持，Dubbo和Motan主要支持Java语言，有些RPC框架支持Go语言（比如rpcx），而有些则支持多语言，这个需要根据实际情况考虑。
3）服务的调用
服务开发之后，接下来就要看服务如何被使用了。
服务调用比较多样化，主要考虑包括如下几个方面，
- 同步和异步调用的支持。
- 对容错、负载均衡的支持，对服务的多版本和分组支持，以保证高可用的目的。
- 对服务熔断和服务降级的支持，以保证服务故障隔离的目的。
容错策略解决的是，一旦发现远程调用失败，如果进行下一步操作以减少错误影响，常见的容错策略有，
- FailFast 快速失败：当消费者调用远程服务失败时，立即报错，消费者只发起一次调用请求。
- FailOver 失败自动切换：当消费者调用远程服务失败时，重新尝试调用服务，重试的次数一般需要指定，防止无限次重试。
- FailSafe 失败安全：当消费者调用远程服务失败时，直接忽略，请求正常返回报成功。一般用于可有可无的服务调用。
- FailBack 失败自动恢复：当消费者调用远程服务失败时，定时重发请求。一般用于消息通知。
- Forking 并行调用：消费者同时调用多个远程服务，任一成功响应则返回。
负载均衡机制解决的是如何在多个可用远程服务提供者中，选择下一个进行调用，常见的负载均衡策略有，
- Random 随机选择：在可用的远程服务提供者中，随机选择一个进行调用。
- RoundRobin 轮询选择：在可用的远程服务提供者中，依次轮询选择一个进行调用。
- LeastActive 按最少活跃调用数选择：在可用的远程服务提供者中，选择最少调用过的远程进行调用。
- ConsistentHash 按一致哈希选择：获取调用请求的哈希值，根据哈希值选择远程服务提供者，保证相同参数的请求总是发到同一提供者。
服务熔断是指一旦服务调用无法正常工作，在故障时间内，尽量减少对服务的调用，直接返回null或抛异常，直到服务恢复正常。
各个RPC框架对服务调用的支持程度不一，但基本的高可用和熔断措施都会提供，而且一般会有相应的扩展点供自定义。在高并发量的情况下，对高可用和熔断措施会是相当大的考验，能否正常稳定运行，是一个RPC框架走向生产环境的关键，一般会和远程服务通信模块一并进行性能测试，详细的性能测试参数见后续的远程服务通信。
4）应用开发框架集成
为了方便服务的开发和使用，RPC框架还会集成业界主流应用开发框架，例如Dubbo和Motan集成了对Spring Framework的集成。
下面是Motan以注解的形式提供服务，
@MotanService(export = “demoMotan:8002”)
public class GreeterImpl implements Greeter {
public String sayHello (String name) {
return “Hello “ + name;
}
}
下面是Motan以注解的形式消费服务，
public class HelloController {
@MotanReferer(basicReferer = “clientConfig”, directUrl = “127.0.0.1:8002”)
Greeter greeter;
public String home() {
return greeter.sayHello(“test”);
}
}
可以看到，RPC框架所集成的应用开发框架，及其集成的支持程度，其能够很大程度上影响服务开发的效率，这在评价RPC框架时也是重要考虑因素。
5）远程服务通信
服务通信组件是底层，其通信吞吐量和性能，决定了整个微服务框架的高并发，其通信一般通过性能测试报告获得。
一般的测试场景包括，
数据传输性能测试场景（考察最大通信吞吐量TPS，响应时间，10并发）
- 传入1k string，原样返回
- 传入50k string，原样返回
- 传入200k string，原样返回
- 传入1k POJO，原样返回，考察序列化模块
- 传入的string size在1k-200k随机变化，原样返回
高并发性能测试场景（考察最大通信吞吐量TPS，响应时间，负载均衡）
- 10并发1k string，原样返回
- 20并发 1k string，原样返回
稳定性测试场景（考察框架的稳定性, 通信吞吐量TPS、成功率、响应时间的趋势）
- 时长：24小时，7天，一个月
- 吞吐量：10并发 1k string，原样返回
服务消费方性能测试（考察消费方的稳定性和高可用）
- 熔断：每隔1分钟触发一次熔断，1分钟后恢复，一次轮询24小时
- 负载均衡：对每个负载均衡策略，持续运行24小时
更多的测试场景需依据业务情景进行考虑。
一份Dubbo的性能测试报告见如下链接，
- https://dubbo.gitbooks.io/dubbo-user-book/content/perf-test.html
6）服务运行监控
服务调用监控是微服务运营的一个关键环节，通过服务监控，我们可以获取服务的调用次数，调用时长，成功和失败数，及其分析整个服务调用链，获取远程服务调用的健康状态，辅助改进远程服务调用。
RPC框架对监控指标的收集和分析，是RPC框架本身重要的治理功能。
4. 开源RPC框架的技术需求指标
下表统计了Dubbo和Motan各项技术需求指标情况，同时加入了Spring Cloud在微服务架构的相关功能支持，方便对比，
| RPC框架 | Dubbon | Spring Cloud | Motan |
|---|---|---|---|
| 公司 | 阿里 | 微博 | |
| 开源时间 | 2012.1 | 2014.10 | 2016.5 |
| 框架开发语言 | Java | Java | Java |
| 项目代码量 | 120K | ? | 140K |
| 社区活跃度 | 15000+ | ? | 4000+ |
| 服务开发语言 | Java | Java | Java/PHP |
| 服务开发框架集成 | Spring Framework 4.3.10.RELEASE | ||
| 分布式服务-注册中心 | Default, Multicast, Redis, Zookeeper, Simple Registry, Direct | Netflix Eureka | Consul, Zookeeper, Direct |
| 分布式服务-高可用 | Failfast, Failover, FailSafe, FailBack, Forking, Broadcast | 通过Netflix Zuul提供FailOver | Failfast, Failover |
| 分布式服务-负载均衡 | Random, Roundrobin, LeastActive, ConsistentHash | 通过Netflix Zuul提供: Random, Roundrobin | Random, Roundrobin, LocalFirst |
| 分布式服务-服务的定义 | Java Interface | 无强契约, 支持Swagger API | Java Interface |
| 分布式服务-服务粒度 | 服务类方法Method | 服务类方法Method | |
| 分布式服务-多版本 | 支持 | 支持 | |
| 分布式服务-配置 | 无，外接 | Spring Cloud Config | 无，外接 |
| 分布式服务-服务故障 | 提供服务降级, 直接返回null | Netflix Hystrix | 服务故障隔离 |
| 远程服务调用定义-Protocol | Dubbo协议（Netty NIO）, Hessian协议, Injvm协议（内部调用）, Rmi协议（TCP）, Memcached协议, Redis协议, Thrift协议, HTTP协议 | Restful API | Motan2协议 (Netty NIO), Injvm协议（内部调用）, Yar（PHP）, Restful (JAX-RS), Grpc |
| 远程服务通信 Transport | Netty, Netty4, Apache Mima (TCP), Grizzly, P2p | Netty, Netty4 | |
| 服务调用跟踪 | Spring Cloud Sleuth | OpenTracing | |
| 性能报告 | 1k String，并发量10K+ | 1k String，并发量10K+ | |
| 序列化协议 | Hessian2序列化, Dubbo序列化, JSON序列化 | Simple序列化, Hessian2序列化 | |
| 可扩展性 | SPI，扩展点丰富 | SPI，扩展点丰富 | |
| 特色 | 开源较早的服务化框架，业界应用广泛，功能丰富 | 和Dubbo相比，提供更加简化的框架模块和架构 |
上述表格的数据统计于2018年1月25日。
注：有？标记说明该项指标待查。
5. RPC框架选择
每一个RPC框架都有其自身的特点和适应性，只有符合当前业务场景需要的RPC框架，才是最好的选择。前文对服务定义、服务开发、服务调用、服务通信和服务监控运行各个方面需要考虑的技术因素进行了描述，除此之外，我们还需要考虑更多的方面。
若准备选择已开源的RPC框架上进行自研，则还需要考虑如下几个方面，
- 生产应用：只有经过生产环境的运行和流量冲击，才能证明RPC框架的稳定性
- 架构和代码复杂度：这个关系到后续框架的可维护性和可扩展性
- 社区活跃度：好的活跃社区，有助于框架的成熟，支撑未来发展
如果选择全新自研RPC，则建议全面考虑上述因素。
6. RPC框架的未来
RPC框架发展至今，其基本的架构组件没有太大变化，服务的注册和发现、服务的通信和治理、故障熔断恢复、配置、监控等等，都是一个RPC框架需要提供实现的核心技术组件。但是2017年微服务业界对Service Mesh的热烈讨论，让我们看到对RPC框架未来5-10年的变化。
1) 当前RPC框架面临的问题
上面对RPC框架的技术需求分析中，可以看到RPC框架涉及技术广泛，架构模块组件繁多，在对微服务架构提供技术支持的同时，其框架本身的治理问题也亟待解决，这是问题之一。
还有一个更大的问题是，RPC架构本身是和语言无关的，但为了开发效率，各个RPC框架都对某一个开发语言有特定的支持。目前通过RPC框架开发微服务时，带来最大的问题便是其框架侵入性，开发者在项目的开发过程中，不仅引入框架组件，还不得不在业务代码中添加各种“胶水”配置代码。
请见一个Spring Cloud项目，在引入各个组件之后，还需通过注解方式打开各个组件开关，
@SpringBootApplication
@EnableConfigServer
@EnableEurekaServer
@EnableEurekaClient
@EnableHystrix
@EnableHystrixDashboard
@EnableTurbine
@EnableDiscoveryClient
@EnableFeignClients
@EnableZuulProxy
@EnableZuulServer
Public class Application {
SpringApplication.run (Application.class, args);
}
Dubbo和Motan对组件的注解和配置也是如此。下面是一个简化的motan服务端配置，
<beans>
<!-- 业务具体实现类 -->
<bean id=" motanDemo" class="MotanDemo"/>
<!-- 注册中心配置 -->
<motan:registry regProtocol="zookeeper" name="registry" address="127.0.0.1:2181" />
<!-- 协议配置。-->
<motan:protocol id="demoMotan" default="true" name="motan" maxConn="80000" />
<!-- 具体rpc服务配置，声明实现的接口类。-->
<motan:service interface="Demo" ref="motanDemo" export="demo:8001" >
</motan:service>
</beans>
可以看到，即使开发一个简单的项目，各个框架组件一个都不能少，框架对业务代码的侵入性强，各种服务配置的更新会直接涉及项目代码变化。特别是一旦涉及框架的升级，当前“嵌入式”的RPC框架将需要各个应用项目配合，升级时间长，依赖冲突，分散，不可控制，RPC框架的升级治理完全靠“手工”，是一项非常困难、痛苦的过程。
2) 未来5-10年
上述RPC框架面临的问题正是Service Mesh所要解决的，Service Mesh是一个基础设施层，其独立运行在应用服务之外，提供应用服务之间安全、可靠、高效的通信，并为服务通信实现了微服务运行所需的基本组件功能，包括服务注册发现、负载均衡、故障恢复、监控、权限控制等等。
Service Mesh并没有脱离RPC典型架构，它提出一个Sidecar的Proxy组件，实现RPC典型架构中的服务提供者和服务消费者功能，注册中心将成为一个更加强大的控制管理平台。
一个典型的Service Mesh部署网络拓扑图如下，
其中绿色方块为应用服务，蓝色方块为Sidecar Proxy，应用服务之间通过Sidecar Proxy进行通信，整个服务通信形成图中的蓝色网络连线，图中所有蓝色部分就形成了Service Mesh。
可以看到，通过sidecar将本地服务调用转为远程服务调用，sidecar的部署和运行独立于应用服务之外，通过这种方式减少了框架的侵入性，应用的开发语言无限制，能够做到真正的跨语言，同时整个sidecar的运行治理也将自成系统。
未来的5-10年，Service Mesh在引领RPC框架上的创新变化，为下一代微服务架构提供全新技术支持。
7. 参考文献
- Dubbo的技术文档 https://www.gitbook.com/@dubbo
- Motan的技术文档 https://github.com/weibocom/motan/wiki
- 微博轻量级RPC框架Motan正式开源：支撑千亿调用
- WHAT'S A SERVICE MESH? AND WHY DO I NEED ONE? ，作者William Morgan，为BuoYant公司CEO，讲述其对Service Mesh的定义和意义。
- Pattern: Service Mesh，作者Phil Calçado，该文章以TCP/IP在网络通信的发展历程和作用作为类比，来解释Service Mesh要解决的问题及在微服务中的作用。
