分类：后端开发

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在微服务架构的相关功能支持，方便对比，

上述表格的数据统计于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. 参考文献

1. Dubbo的技术文档 https://www.gitbook.com/@dubbo
2. Motan的技术文档 https://github.com/weibocom/motan/wiki
3. 微博轻量级RPC框架Motan正式开源：支撑千亿调用
4. WHAT'S A SERVICE MESH? AND WHY DO I NEED ONE? ，作者William Morgan，为BuoYant公司CEO，讲述其对Service Mesh的定义和意义。
5. Pattern: Service Mesh，作者Phil Calçado，该文章以TCP/IP在网络通信的发展历程和作用作为类比，来解释Service Mesh要解决的问题及在微服务中的作用。