话说上个系列好像朋友们都表示有点难理解，难道是数学公式太多了？大数据计数原理1+0=1这你都不会算(十)No.77 。希望这次可以写简单点，像大蕉这样的小小白都可以理解那种。上一篇文章我们讲到一些关于企业系统间交互，顺便开了一下坑。企业神奇中间件-RPC No.96
拷一段过来先，回顾一下。
RPC（Remote Procedure Call），远程过程调用，从最简单最抽象的模式来看，就是下面这个图这样。客户端调用某个方法，然后中间经过一系列的过程，调用到服务端的某个方法。服务端进行处理之后，做出相应，然后逐层原路返回到客户端。
是不是很简单，一般来说，开发者只需要关注蓝色（ functions ）部分，而至于红色部分（ stub句柄 ） 和黄色部分（socket 网络）部分呢，框架层面会把它解决掉。蓝色部分，服务端开发者要做的事情就是定义某个接口，客户端开发者要做的事情就是调用某个接口，一切开发模式都跟本地调用无差别。
RPC 在企业内部有三个非常非常重要的作用。
1、抛弃厚重的 HTTP 头，减少网络带宽消耗。
2、默认使用信任的 TCP 长连接，减少各种身份确认以及网络握手消耗。
3、面向开发者友好，开发者可以跟开发本地程序一样调用别人的服务。
HTTP请求交互：
一次 HTTP 请求
客户端：你准备好我要发送了啊。
服务端：好吧你发送吧。
客户端：你真的准备好我真的要发送了啊。
客户端：发送请求。
服务端：响应请求。
客户端：你准备好我要关闭了啊。
服务端：好吧你关闭吧。
服务端：我关闭连接了。
客户端：好的我知道你关闭了。
ps:
HTTP 1.0 默认不打开长连接，客户端想持有长连接要加上"Connection:keep-alive"的 header。
HTTP 1.1 默认打开长连接，服务端返回报文有 "Connection:keep-alive" 表示是一个长连接。
HTTP 2.0 默认打开长连接支持多路复用，即在一个连接中可发起多次请求和响应。
RPC交互过程：
客户端：你准备好我要发送了啊。
服务端：好吧你发送吧。
客户端：你真的准备好我真的要发送了啊。
客户端：发送请求。
服务端：响应请求。
客户端：发送请求。
服务端：响应请求。
客户端：发送请求。
服务端：响应请求。
连接永远不会有连接关闭的一天，除非目标机器挂了通道崩了之类的。
连接的打开和关闭是一个成本，虽然 HTTP 已经支持了长连接，但是抛去这些不讲，繁重的 HTTP 头也是会把网络搞崩。HTTP 全名 HyperText Transfer Protocol - 超文本传输协议，顾名思义，这个应该是用来完成一些请求很少但是响应文本比较多的协议，而对于高效率高并发的企业级应用来说，还是需要使用一些私有化的协议来进行系统间的交互，以减少一大堆在这个场景没有用处的头信息浪费带宽。
好目光继续回到 RPC 本身，先来讲讲现在各种 RPC 框架的套路。根据我的观察，现在各种 RPC 框架无论支持多少协议，无论是用什么语言实现的，一般都离不开下面这种套路。先明确一个观念，在 RPC 中我们把调用方叫 Consumer 消费者，服务端叫 Provider 生产者。
套路是这样的。
关于 RPC 的调用路径
1、Consumer 调用代理 Proxy，无论是主动调用还是被动调用，都是调用。
2、对请求进行序列化 Serializer。
3、序列化完再转成二进制，交给 Socket 或者 其他网络 IO 层。
4、将二进制写入 Channal 通道中。
5、Channal 直接飞到 服务端。
6、服务端 Socket 读取 Channal 获得二进制体。
7、对请求进行 Deserializer 反序列化，还原原始请求。
8、然后将请求交给服务端的代理 Proxy。
9、代理调用到真正的 Provider 。
10、Provider 对请求做出相应。
然后再依次 9.8.7.6.5.4.3.2.1 原路返回。
综上所述，所以完整的是交互这样的，蓝色是请求，红色是响应。
关于注册中心
当然，类似 Dubbo 这类框架呢，还会提供一小部分服务治理的能力，比如搞一个注册中心，Provider 在启动的时候向注册中心暴露自己的ip和端口和各种服务的地址。然后 Consumer 在调用的时候，先问一下 Register 注册中心有哪些机器是我能调用的，这个时候会有一层路由策略或者 HA 的策略。获取到地址列表之后呢，Consumer 再根据自己路由策略进行第二波路由。嗯，好像稳了。谨记喔，即使没有注册中心，上边这套机制也是可以正常工作的喔，只要能以各种方式发现目标服务的存在。
未完待续。。。