RPC浮想联翩

最近在浏览学习有关RPC的文章的时候，不由自主的联想到之前做过联机交易平台（下简称OOTS）。

不落俗套的来一下RPC定义，RPC（Remote Procedure Call）远程过程调用。顾名思义，调用远程（非本机）的程序如同本地调用一般方便。为什么OOTS会跟RPC产生联系呢。下面来看看RPC的几个基础概念。

通讯

RPC

“远程”意味着就必须进行网络通讯，Socket是网络通讯的基础，为了保证系统间交互的稳定、可靠、高效，一般都会采用Tcp协议。减少Socket连接过程的消耗，一般会采用双工长链接方式。

OOTS

OOTS作为联机交易平台，通讯组件是起必不可少的组成部分。由于业务的特性，通讯模块主要支持Tcp协议，支持单工、双工、长链接、短链接等不同的通讯模式。

Socket I/O模式

RPC

常规有如下几种模式，可在介绍RPC的文章找到详细说明：
1 阻塞I/O
2 非阻塞I/O
3 I/O多路服用
4 异步I/O

OOTS

OOTS是在UNIX上面运行，采用C语言编写，没有其他高级语言（比如java、python）这么丰富的多线程、协程的高级特性，但是在UNIX C环境下个人认为也是另一方面的极致体现。

主要的设计理念更接近异步I/O模式

每个通讯模块采用1+2子进程模式，主进程负责Socket监听、连接、状态监听；
两个子进程分别监听IN/OUT两个管道，分别代表Socket数据的读/写；
主进程监听到数据之后就会写入到“IN”管道；
主进程从“OUT”管道中读取数据写入到对应的Socket连接中实现数据返回；

协议

数据包的大小会直接影响到通讯的效率，在并发处理的时候这是很致命的问题，通讯包的协议结构就显得非常重要。

RPC，一般采用Head+Body模式

OOTS，主要在金融支付领域运用，金融领域有一套国际通用的协议-8583协议。简单的来说，是一套采用位图编码的协议。

协议报文结构：

报文长度(2字节)+TPDU(5字节)+报文头(6字节)+域数据(指令码(0域 2字节 消息类型)+位图(8字节)+其他域数据。

TPDU头 = ID（60H） + 目的地址（N4） + 源地址（N4），长度为10字节，压缩时用BCD码表示为5个字节长度的数值。

报文头 = 应用类别定义（N2 ）+软件总版本号（N2） + 终端状态（N1） + 处理要求 （N1）+ 软件分版本号（N6），总长度为12字节，压缩时用BCD码表示为6个字节长度的数值。

数据序列化

对应就是OOTS的打包/解包，包就是数据包，结构化、格式化的数据包，打包就是将离散数据按照协议进行格式化处理，解包就是结构化的数据进行解析。

这个过程我们可以想象成打包快递包裹和拆快递包裹的过程。

每次收到老家寄来的投食包裹，打开的瞬间都不得不佩服老妈打包的艺术，从左到右、从底层到表面，全方位无死角的塞满了这个箱子。箱子是四四方方的，虾饺、糕点、红糖、薯粉、生蚝尽量用小方盒装，小方盒装依次码起；鱼、虾、鱿鱼等海鲜就分小袋包装，由于形状不一，各种交错叠加；各种间隙在塞上配菜等稍微可以压缩的食物。

为什么说这个，其实是想让大家能理解为什么需要序列化，以及序列化做了什么。序列化其实就是将数据按照有序的格式填充到在有限的数据包中，提高数据的传输效率。

可靠性

复杂的网络环境决定要保证网络的可靠性，除了常规的socket连接，还需要有额外的手段来辅助。Tcp协议为了数据的可靠性，连接过程需要建立三次握手过程。短连接频繁的建立连接是非常大的消耗，长连接更适合需要频繁交互的情况，比如RPC的大部分框架就采用长连接模式。长连接需要保证双方在经历三次握手之后能一直保持连接有效、可用。这个需要怎么处理呢，通讯框架一般都会提供KeepAlive功能来维持连接的状态。具体实现原理是怎样呢。我们试想一下，如果两个系统之间一直有频繁的数据交互，我们还会担心这个问题，大部分情况下是不需要担心这个问题。只是链路空闲情况下，容易出现问题。所以我们需要在知道链路空闲的情况，主动发起心跳检测，用于检测链路监控状况。常规操作就是维持每个链路的空闲超时时间，比如5分钟之内没有数据交互，则需要发起心跳包。

虚链，一种在长连接模式下且缺少心跳包情况下容易出现又极其恶心的问题。从系统层面，连接是正常的，但是数据就是无法发送或者响应。每当重启服务重新建立连接即可解决，空闲一段时间就又出现。

总结

最后附上OOTS的实现流程图