RPC：如何在线上环境里兼容多种RPC协议

为什么要支持多种协议

RPC 是能够帮助我们在开发过程中完成应用之间的通信，而又不需要我们关心具体通信细节的工具

既然应用之间的通信都是通过 RPC 来完成的，而能够完成 RPC 通信的工具有很多，比如像 Web Service、Hessian、gRPC 等都可以用来充当 RPC 使用。这些不同的 RPC 框架都
是随着互联网技术的发展而慢慢涌现出来的，而这些 RPC 框架可能在不同时期会被我们引入到不同的项目中解决当时应用之间的通信问题，这样就导致我们线上的生成环境中存在各种各样的 RPC 框架。

很显然，这种混乱使用 RPC 框架的方式肯定不利于公司技术栈的管理，最明显的一个特点就是我们维护 RPC 框架的成本越来越高，因为每种 RPC 框架都需要有专人去负责升级维护。因为我们需要把所有的应用都改造成新的RPC使用方式。

问题是，对于多人团队来说，有什么办法可以让其把多个 RPC 框架统一到一个工具上呢？

为了解决上面升级过程中遇到的问题，你可能还会想到另外一个方案，那就是在应用升级的过程中，先不移除原有的 RPC 框架，但同时接入新的 RPC 框架，让两种 RPC 同时提供服
务，然后等所有的应用都接入完新的 RPC 以后，再让所有的应用逐步接入到新的 RPC上。这样既解决了上面存在的问题，同时也可以让所有的应用都能无序地升级到统一的RPC 框架上。

在保持原有 RPC 使用方式不变的情况下，同时引入新的 RPC 框架的思路，是可以让所有的应用最终都能升级到我们想要升级的 RPC 上，但对于开发人员来说，这样切换成本还是有点儿高，整个过程最少需要两次上线才能彻底地把应用里面的旧 RPC 都切换成新 RPC。

那有没有更好的方式可以让应用上线一次就可以完成新老 RPC 的切换呢？关键就在于要让新的 RPC 能同时支持多种 RPC 调用，当一个调用方切换到新的 RPC 之后，调用方和服务提供方之间就可以用新的协议完成调用；当调用方还是用老的 RPC 进行调用的话，调用方和服务提供方之间就继续沿用老的协议完成调用

怎样优雅的处理多协议

要让新的 RPC 同时支持多种 RPC 调用，关键就在于要让新的 RPC 能够原地支持多种协议的请求。

• 协议的作用就是用于分割二进制数据流，每种协议约定的数据包格式是不一样的，而且每种协议开头都有一个协议编码，我们一般叫做magic number。
• 当RPC收到了数据包之后，我们可以先解析出magic number来。获取到magic number后，我们就很容易的找到对应的数据格式，然后用对应协议的数据格式去解析收到的二进制数据包
• 协议解析过程就是把一连串的二进制数据变成一个 RPC 内部对象，但这个对象一般是跟协议相关的，所以为了能让 RPC 内部处理起来更加方便，我们一般都会把这个协议相关的对象转成一个跟协议无关的 RPC 对象。这是因为在 RPC 流程中，当服务提供方收到反序列化后的请求的时候，我们需要根据当前请求的参数找到对应接口的实现类去完成真正的方法调用。如果这个请求参数是跟协议相关的话，那后续 RPC 的整个处理逻辑就会变得很复杂。
• 当完成了真正的方法调用以后，RPC 返回的也是一个跟协议无关的通用对象，所以在真正往调用方写回数据的时候，我们同样需要完成一个对象转换的逻辑，只不过这时候是把通用对象转成协议相关的对象。

在收发数据包的时候，我们通过两次转换实现 RPC 内部的处理逻辑跟协议无关，同时保证调用方收到的数据格式跟调用请求过来的数据格式是一样的。整个流程如下图所示：