这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天

RPC简介

概念理解

IDl

全称是（Interface Description Language）文件

IDL通过一种中立的方式来描述接口，使得在不同平台上运行的对象和用不同的语言编写的程序可以互相通信

生成代码

通过编译器工具把IDL文件转换成语言对应的静态库

编解码

从内存中表示到字节序列的转换称为编码，反之为解码，也常常叫做序列化和反序列化

通信协议

规范了数据在网络中的传输内容与格式。除了必须的请求/响应数据外，通常还会包含额外的元数据

网络传输

通常基于成熟的网络库走TCP/UDP传输

一次完整的RPC

其中Caller和Calle可以理解成呼叫者和被叫者

两者通过标准的IDL文件来生成代码，使用相同的传输协议。

Caller充当客户端（Client），Callee充当服务端（Server）

例如，我现在期望RPC调用远程的一个函数GetToken（），那么我们需要在本地构建一个Client，通过Client与远程服务端通信

这里我觉得比较难理解的是客户端和服务端，因为在应用过程中，通常有一个网关的角色，网关来处理HTTP请求，并RPC调用远程函数来处理请求，在这里，网关不仅充当了服务端（Server），也充当了客户端（Client），它既是HTTP请求的服务端，也是RPC调用的客户端

RPC的优势

• 单一职责，有利于分工协作和运维开发
• 可拓展性强，资源使用率优
• 故障隔离，服务的整体可用性高

在开发过程中，我们可以把各个接口进行分组，每个或几个人负责一个组的开发，这样进度可以并发提升

同时，故障隔离的比较立体的例子就是，如果你当前服务宕机/因特殊原因不可用，你可以直接下线这个服务，而其他服务不受影响

分层模型

分层模型个人认为在开发过程的很多地方都会涉及，核心理念应该就是大事化小（相对通俗一点），这样开发效率会提升，同时项目结构性更强

RPC关键指标

稳定性

为了让服务可靠性加强，我们使用了如下策略来强化稳定性：

• 熔断：保护调用方，防止被调用的服务出现问题而影响到整个链路
• 限流：保护被调用方，防止大流量把服务压垮
• 超时控制：避免浪费资源在不可用节点上

易用性

我们期望一个RPC框架具备强易用性，例如：

• 开箱即用：合理的默认参数选项、丰富的文档
• 周边工具：生成代码工具、脚手架工具

例如，我们希望一个RPC框架可以有一个简单易用的命令行工具，它支持：

• 生成服务代码脚手架
• 支持Protobuf和Thrift
• 内置功能丰富的选项
• 支持自定义的生成代码插件

（其实就是字节自己的Kitex框架嘛。。）

不过在我用过的RPC框架中，基本上都会带有命令行工具来支持代码生成

基本上所有的RPC框架易用性都很高，但是各个框架都有自己不同的点

拓展性

RPC框架需要支持一定的拓展性

例如：中间件、选项、编解码层、协议层、网络传输层、代码生成工具插件拓展

强的拓展性可以带来更高的业务覆盖面。

观测性

实际上就是可以观察业务程序的当前状态

我们可以使用Log、Metric和Tracing等来观测一个正在运行的程序

个人理解上，观测性就是在不打断程序运行的情况下确认程序的内部运行情况

其中Tracing链路追踪可以定位到问题的所在，Log可以较为直观的分析运行的状况

但是除了这三件套之外，对于框架来说还是不够的，还需要支持观测一些自身状态，例如环境变量、配置、缓存信息和Client/Server初始化参数等

小结

• 框架通过中间件来注入各种服务治理策略，保障服务的稳定性
• 通过提供合理的默认配置和方便的命令行工具可以提升框架的易用性
• 框架应当提供丰富的拓展点，例如核心的传输层和协议层
• 观测性除了传统的Log、Metric和Tracing外，内置的状态暴露服务也很有必要
• 性能可以从多个层面去优化，例如选择高性能的编解码协议和网络库