这是我参与「第五届青训营 」笔记创作活动的第14天
1 RPC 相关的基本概念
1.1 RPC定义
RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。 它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。
1.2 起源
RPC 这个概念术语在上世纪 80 年代由 Bruce Jay Nelson（参考[1]）提出。 这里我们追溯下当初开发 RPC 的原动机是什么？在 Nelson 的论文 Implementing Remote Procedure Calls（参考[2]） 中他提到了几点：
简单：RPC 概念的语义十分清晰和简单，这样建立分布式计算就更容易。
高效：过程调用看起来十分简单而且高效。
通用：在单机计算中「过程」往往是不同算法部分间最重要的通信机制。
通俗一点说，就是一般程序员对于本地的过程调用很熟悉，那么我们把 RPC 做成和本地调用完全类似，那么就更容易被接受，使用起来毫无障碍。 Nelson 的论文发表于 30 年前，其观点今天看来确实高瞻远瞩，今天我们使用的 RPC 框架基本就是按这个目标来实现的。
1.3 分类
RPC 调用分以下两种：
- 同步调用：客户端等待调用执行完成并获取到执行结果。
- 异步调用：客户端调用后不用等待执行结果返回，但依然可以通过回调通知等方式获取返回结果。若客户端不关心调用返回结果，则变成单向异步调用，单向调用不用返回结果。
异步和同步的区分在于是否等待服务端执行完成并返回结果。
2 RPC 框架的分层设计
一个最简单的RPC框架分成三个部分:注册中心、服务端、客户端。以下是一个最简单的结构流程图.
组成部分：
-
注册中心：用于注册和获取服务。
-
服务端：指提供服务的一方，也叫服务提供方 Provider
-
客户端：指调用服务的一方，也叫服务消费者 Consumer
流程：
-
服务端把服务信息注册到注册中心，通常包含服务端地址、接口类和方法
-
客户端从注册中心获取对应服务的信息
-
客户端根据服务的信息，通过网络调用到服务端的接口
3 衡量RPC框架的一些核心指标
3.1 稳定性
当网络发生单通、连接被防火墙 Hang 住、长时间 GC 或者通信线程发生非预期异常时，会导致链路不可用且不易被及时发现。特别是异常发生在凌晨业务低谷期间，当早晨业务高峰期到来时，由于链路不可用会导致瞬间的大批量业务失败或者超时，这将对系统的可靠性产生重大的威胁。
从技术层面看，要解决链路的可靠性问题，必须周期性的对链路进行有效性检测。目前最流行和通用的做法就是心跳检测。
心跳检测机制分为三个层面：
1.TCP 层面的心跳检测，即 TCP 的 Keep-Alive 机制，它的作用域是整个 TCP 协议栈。
2.协议层的心跳检测，主要存在于长连接协议中。例如 MQTT 协议。
3.应用层的心跳检测，它主要由各业务产品通过约定方式定时给对方发送心跳消息实现。
心跳检测的目的就是确认当前链路可用，对方活着并且能够正常接收和发送消息。
3.2 易用性
开箱即用
周边工具
3.3 扩展性
可以与其他流行开源产品糅合
3.4 高性能
可以提高很高并发量的组件
