如何为分布式系统优雅的更换RPC
为啥需要更换RPC?
很多小伙伴都遇到过需要为分布式系统调用更换RPC的问题，为什么会遇到这种事呢？其实，在系统搭建初期，需求简单，架构简单，最重要的是请求量也少，所以很多系统都采用快速原型开发模式，对rpc的要求不高，随便找一个顺手的或者熟悉的rpc框架套进系统中即可。但是随着业务复杂度增高，系统承载的请求量增高，可能一开始所采用的RPC框架显现出一些致命的问题，比如大扇出问题。我们以Thrift为例。例如随着业务复杂度的增长，我们面临着如下的需求。
如图所示，每一次请求，上游服务都要获取下游A~Z一共26个服务的结果，然后把这26个服务的结果拼装返回给前端服务。有人说，26个服务是不是有些夸张了，我的系统中根本没有遇到过这个情况。这实际一点不夸张，一个业务复杂的系统经过服务拆分，最后拆成一些高内聚低耦合的独立服务，非常容易达到这样一个服务种类数，而且26还远远不是很多。那么遇到这种问题，传统的同步的RPC怎么解决这个问题呢？
以Thrift为例，如果需要访问26个服务，为了保证请求处理速度，必须要并行访问各个下游服务（不能串行请求，因为这将导致 一次请求的响应时间至少为timeA + timeB + ...... + timeZ），那么我们只能通过多线程进行并发。
通过多线程并发请求，我们基本能够达到处理一次请求至多需要 max(timeA, timeB, ......, timeZ)，但是实际上要比这个稍多。看样子我们必须弄一个请求线程池，可是这个池子要多大呢？假如现在前端请求速率为 P，那么为了保证每个请求处理时间都尽可能快，我们需要一个大小为 26 * P的线程池。虽然，初看起来可能还可以应付，毕竟请求线程在发送网络请求后，会阻塞在IO，它会放弃CPU，从而使得计算线程获得CPU，不会浪费多少CPU的资源，但是当P太大就不好了。比如P为100或者1000，这个时候线程数过多可能就会造成CPU调度开销增大，因为它会增加CPU的线程切换负担。
所以，我们更换RPC，当且仅当，当前的RPC已经造成了系统负担，对于业务量不大的系统，RPC的更换并没有必要，但是为了技术提升你也可以更换RPC，只不过收益可能不大。
需要什么样的RPC？
考虑到Thrift对于大扇出并不合适，我们可能需要下面这样工作模式的RPC。
这种反应器模型（只是简单举例子）可以减少请求线程数。这种RPC使用系统的Epoll进行后端服务的请求以及数据的接收，这样无论多少请求，只使用一个线程完成，通过Epoll的机制在数据到来或者可发送的情况下通知用户进程，只不过最后需要把接收到的数据返回给计算线程使用。这种模型其实要比Thrift那种那好一些。我自己也在业余时间实现了一个简单的RPC框架：http://www.cnblogs.com/haolujun/p/7527313.html ，比较粗糙但是足够小。
还有有很多开源的RPC框架，fbthrift，GRPC都可以应对大扇出，找到适合你的系统，并且改动量和后期维护成本最低的那个。
如何迁移到新的RPC？
把系统迁移到新的RPC上，除了改动代码外，就是要做到兼容，系统在迁移过程中可能需要在两套RPC框架上运行，并且必须做到平滑迁移。例如，一般的分布式系统可能会长成如下的样子。
服务B1~B4把自己的地址写入到ETCD中，但是由于我们一开始并未考虑到RPC的迁移，所以value对应的是服务的地址，没有服务使用的rpc类型等等。
方案1 添加新key
对于A1A2，B1B4，可以先选择一部分进行平滑过渡，例如我们选择A1，B1~B2进行迁移。
上线步骤如下：
- 下线A1，B1，B2。
- 更新A1配置，使其从新的key：service_new_rpc中读取后端服务列表。
- 更新B1,B2配置，使其在新的key：service_new_rpc中注册自己。
- 启动B1,B2。
- 启动A1。
- 对于A2，B3，B4重复如上步骤。
通过这种方式，我们可以平滑的进行服务迁移。但是它的缺点很明显，需要一个新的key，而且后期还需要一点点把服务挪回到旧的key上。
方案2 代码兼容
这个方案必须更改一些解析代码，使其能够兼容新的ETCD中value的格式，如下图。
- 首先改造A代码，使其能够兼容新地址解析格式。新地址格式在每个地址后加上RPC类型标识：T（Thrift），G（GRPC），新格式和旧格式的兼容很容易，只需在解析的时候找一下分割符，并判断分隔符最后一部分是T是G还是什么都没有，没有就默认为T。
- 改造A代码，使其能够根据后端服务在ETCD中的RPC类型使用不同的RPC框架调用后端。
- 改造B1~B4的配置，在ETCD中注册自己的时候把RPC类型顺便加上。
- 改造B1~B2，使用新RPC作为服务端，并且在注册的时候把RPC类型设置为G。
- 改造B3~B4，使用新RPC作为服务端，并且在注册的时候把RPC类型设置为G。
通过这个步骤，我们就能做到RPC的平滑迁移。这个方式的缺点也有：需要同时维护两套RPC框架，直到其中一种RPC彻底下线。但是优点也有，没有增加新key。
总结
更换RPC并不像想象中的那样困难，只要理清前后逻辑，一点点的迁移，最终你的服务会全部搞定。最重要的问题是你的系统真的达到了非得换RPC的地步了么？
