关于Blocking RPC的思考

前言

近日,考虑到重构之前的系统,涉及到如何设计一个阻塞型RPC调用,场景如下:

Web Server A 想要call 在Web Server B的一个方法F,方法F执行操作为CURD虚拟机,其中启动VM与克隆VM需要花费数分钟级别的时间。

解决思路与分析

1. 同步

实现方式:声明B的方法F为同步方法:A起一个Thread调用F,当成功执行后,执行对应业务逻辑。

Pros:
B的业务逻辑简单。
Cons:
A中维持一大堆的TCP连接,消耗大量TCP资源;同时,导致在不稳定的Network环境下,错误处理逻辑麻烦。

2. 简单异步回调

实现方式:B的方法F为异步方法,A在调用的时候提前约定,或者传入CallBack URL接口以参数形式传入。类似于third party login的解决方案。

Pros:
1. A在调用后立即返回,无需维持大量的TCP连接。
Cons:
1. 增加API的复杂层度,须为每个阻塞型API都创建一个CallBack接口,增大代码的维护难度。

3. 异步回调与MQ解耦

实现方式:B的方法F为异步方法,A调用后返回。另开一个Thread监听

Pros:
1.  通过MQ的方式,解耦了Server A与Server B,同时,接口数量大大减小。
2. 同时,可以打开Log功能已备查验。

Cons:
2. 增加了Deploy成本,当然可以采取Brokerless的MQ如ZeroMQ等来实现。

4. 异步与轮询

实现方式:B的方法F为异步方法,A的调用后,A周期性poll B的查询接口,查询是否完成。其实有点RESTFul的思想。

Pros:
1. 增加与查询接口相分离,减少了A与B的依赖。

Cons:
1. 无中心化的Audit系统,出问题后不易被查验。
2. 增加部分poll的逻辑,增加代码的复杂性。

总结:

引用Guo Yu的那句话,还是看应用场景的复杂度。简言之,
2与3是属于Callback大类的,系统之间通过消息传递来实现业务驱动。
4是属于Poll大类的,系统之间具有自己的高度主动权。


No comments:

Post a Comment