这是我参与「第三届青训营 -后端场」笔记创作活动的的第2篇笔记
基本概念
远程函数调用（RPC）
一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
实际上就是一个系统提供可供其他系统调用的函数，当其他系统传输正确的参数并调用相应函数，则可以在该系统中执行相应的系统功能。这就是最为常见的，使用远程函数调用的系统接口方式。
系统间数据交互的目的，就是一个系统中的功能执行结果，以数据的形式被被传输到另外一个系统，并在利用此结果数据，在另外这个系统中执行相应的系统功能。
远程函数调用（RFC）这种接口模式，就是数据会直接传输相应系统，并在此系统中直接执行系统功能。
我们可以形象的理解为，被调用的系统A，将其系统的账号和密码交给了外部系统B，外部系统B在必要时，会登陆到A系统中，用系统B中的正确参数，也就是数据，去执行A系统中的系统功能。
RPC需要解决的问题
- 函数映射：如何将路由与函数对应
- 数据转换成字节流：数据如何转换成字节流进行传输
- 网络传输：保证机器之间的通信
一次RPC的完整过程
IDL(Interface description language)文件
IDL通过一种中立的方式来描述接口，使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信
生成代码
通过编译器工具把IDL文件转换成语言对应的静态库
编解码
从内存中表示到字节序列转换称为编码，反之为解码，也常叫做序列化和反序列化
通信协议
规范了数据在网络中的传输内容和格式，除必须的请求/响应数据外，通常还会包含额外的元数据
网络传输
通常基于成熟的网络库，用TCP/UDP传输
RPC的好处
- 单一职责，有利于分工协作和运维开发
- 可扩展性强，资源使用率更优
- 故障隔离，服务的整体可靠性更高
RPC分层
整个 RPC 的调用过程涉及到一个过程和几个概念，我们来总结下：
- Client：调用端，以本地调用方式调用服务，就相当于上面的 Server A。
- client stub：接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体（序列化）；client stub找到服务地址，并将消息发送到服务端。
- server stub：收到消息后进行解码，反序列化；server stub根据解码结果调用本地的服务；本地服务执行并将结果返回给server stub。server stub将返回结果打包成消息并发送至消费方。
- client stub接收到消息，并进行解码，反序列化，服务消费方得到最终结果。
RPC框架的关键指标
稳定性
保障策略
- 熔断：保护调用方，防止被调用的服务出现问题而影响到整个链中，在被调用的服务出现问题时有一个兜底的方案
- 限流： 保护被调用方，防止大流量把服务压垮
- 超时控制：避免浪费资源在不可用节点上
- 负载均衡：保证各服务节点的流量平均分配
- 重试：一定程度保证服务的正常响应，一定程度上消除因网络暂时中断带来的问题
易用性
- 合理的默认参数选项（约定大于配置），丰富的文档
- 有丰富的生成代码工具、脚手架工具
扩展性
- 可以自己扩展，比如增加中间件
观测性
- Log, Metric, Tracing
- 内置观测性服务
高性能
可以利用连接池，多路复用，使用高性能的编解码协议和网络库来提高性能
既有HTTP,为什么用RPC
RPC 只是一种设计而已
RPC 只是一种概念、一种设计，就是为了解决 不同服务之间的调用问题, 它一般会包含有 传输协议 和 序列化协议 这两个。
但是，HTTP 是一种协议，RPC框架可以使用 HTTP协议作为传输协议或者直接使用TCP作为传输协议，使用不同的协议一般也是为了适应不同的场景。
RPC框架功能更齐全
应用开发到一定的阶段的强烈需求驱动的。如果我们开发简单的单一应用，逻辑简单、用户不多、流量不大，那我们用不着。当我们的系统访问量增大、业务增多时，我们会发现一台单机运行此系统已经无法承受。此时，我们可以将业务拆分成几个互不关联的应用，分别部署在各自机器上，以划清逻辑并减小压力。此时，我们也可以不需要RPC，因为应用之间是互不关联的。
当我们的业务越来越多、应用也越来越多时，自然的，我们会发现有些功能已经不能简单划分开来或者划分不出来。此时，可以将公共业务逻辑抽离出来，将之组成独立的服务Service应用 。而原有的、新增的应用都可以与那些独立的Service应用 交互，以此来完成完整的业务功能。
总结
RPC框架在微服务在应用广泛，可以说是不可或缺的一部分。总得来说，RPC框架主要目地是让分布式或者微服务系统中不同服务之间的调用像本地调用一样简单。
RPC 的两个核心模块是：通讯和序列化
