如何为分布式系统优雅的更换RPC

内容预览:
  • 那么遇到这种问题,传统的同步的RPC怎么解决这个问题呢? 以Thrift为例...~
  • 还有有很多开源的RPC框架,fbthrift,GRPC都可以应对大扇出,找到适合你...~
  • 例如,一般的分布式系统可能会长成如下的样子~

为啥需要更换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

对于A1~A2,B1~B4,可以先选择一部分进行平滑过渡,例如我们选择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的地步了么?

以上就是:如何为分布式系统优雅的更换RPC 的全部内容。

本站部分内容来源于互联网和用户投稿,如有侵权请联系我们删除,谢谢。
Email:[email protected]


0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论