关于RPC的思考

粗略理解

RPC(remote protocol call)

使用RPC可以不用考虑网络传输消息的过程，而Stub（存根）正是负责具体的网络传输工作

RPC执行流程梳理

跟着箭头的方向，可以知道完整的执行流程：

• 本地调用read函数，read底层将参数打包，通过网络，传输至指定地址的远程服务器
• 远程服务器接收，并由对应的stub解析出参数
• 返回结果也一样经过打包，解包操作

注意：RPC属于同步调用，即在网络交互的时候，会挂起相应的进程

用程序表示：

可以看到，调用者是不需要编写网络传输的代码的，直接调用服务端的函数就行了

RPC框架

不同的 RPC 框架包含的组件可能会有所不同，但是一定都包含 RPC 协议相关的组件，RPC 协议包括

• 序列化
• 协议编解码器
• 网络传输栈

RPC 协议一般分为公有协议和私有协议。
例如，HTTP、SMPP、WebService 等都是公有协议。
如果是某个公司或者组织内部自定义、自己使用的，没有被国际标准化组织接纳和认可的协议，往往划为私有协议，
例如 Thrift 协议和蚂蚁金服的 Bolt 协议。

自研RPC协议

高度定制化的私有协议可以最大限度地降低成本，提升性能，提高灵活性与效率。
定制私有协议，可以有效地利用协议里的各个字段，灵活满足各种通信功能需求，
比如：CRC 校验、Server Fail-Fast 机制和自定义序列化器。

需要考虑以下三个关键问题：

1. 协议包括的必要字段与主要业务负载字段。协议里设计的每个字段都应该被使用到，避免无效字段。
　　　　2. 通信功能特性的支持。比如，CRC 校验、安全校验、数据压缩机制等。
　　　　3. 协议的升级机制。毕竟是私有协议，没有长期的验证，字段新增或者修改，是有可能发生的，因此升级机制是必须考虑的。

目前流行的开源 RPC 框架还是比较多的，有阿里巴巴的 Dubbo、Google 的 gRPC、Facebook 的 Thrift 和 Twitter 的 Finagle

gRPC

简单的来说就是：
gRPC使用了http2.0，速度对http1.1是碾压级别的
gRPC采用protoBuf序列化结构体，相比于采用json或者xml的Rest，体积更小，传输速度更快

protoBuf

proto Buffer与编程语言无关，也就是说任何编程语言都可以实现protobuf的功能

数据类型

Protobuf定义了一套基本数据类型，下表罗列出了protobuf类型和其他语言类型的映射表。
.proto文件有自己的语法和数据类型

消息

消息（message），在protobuf中指的就是我们要定义的数据结构。
就是要用protoBuf进行序列化的数据，一般是对象或者结构体

syntax代表proto的版本
类似于java的类或者是c的结构体
特别的是，需要给每一个字段指定一个id值

Dubbo

Dubbo提供了三大核心能力：

• 面向接口的远程方法调用，
• 智能容错和负载均衡，
• 服务自动注册和发现。

Dubbo具备同步远程调用，负载均衡器，服务中心的功能

• dubbo-common 公共逻辑模块，包括Util类和通用模型。
• dubbo-remoting 远程通讯模块，相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包。
• dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
• dubbo-cluster 集群模块，将多个服务提供方伪装为一个提供方，包括：负载均衡、容错、路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
• dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
• dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。
• dubbo-config 配置模块，是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细节。
• dubbo-container 容器模块，是一个Standalone的容器，以简单的Main加载Spring启动，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。

Thrift

Thrift是一个轻量级、跨语言的RPC框架，主要用于各个服务之间的RPC通信

Tars

TARS是腾讯从2008年到今天一直在使用的后台逻辑层的统一应用框架TAF（Total Application Framework），目前支持C++、Java、PHP、Nodejs、Go语言。

该框架为用户提供了涉及到开发、运维、以及测试的一整套解决方案，帮助一个产品或者服务快速实现开发、部署、测试，以及上线。

它集可扩展协议编解码、高性能RPC通信框架、名字路由与发现、发布监控、日志统计、配置管理等于一体。通过它可以快速用微服务的方式构建自己的稳定可靠的分布式应用，并实现完整有效的服务治理。

相应面试题

Q1：请说出Dubbo的实现过程

解答：
服务运行容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Q2：请说出Dubbo的负载均衡策略有哪些
所谓的负载均衡策略最终目的都是要通过某种方案得到一个索引，用于从服务列表中筛选服务

Q3：请说出Dubbo集群的容错方案

• Failover - 失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)。
• Failfast - 快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
• Failsafe - 失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
• Failback - 失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
• Forking - 并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数。
• Broadcast - 播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

Q5：请比较同为RPC框架的Dubbo与Thrift
Thrift 是跨语言的 RPC 框架。
Dubbo 支持服务治理，而 Thrift 不支持。