Net大型系统间调用的问题

阳光穿透心脏的1/2处 2022-08-07 00:27 23阅读 0赞

**提到分布式系统, 但系统间的交互尤为重要, 下面从实现原理,动态扩展(负载均衡),异构交互(java,php等实时交互)和技术风险等**

**目录**

1、组件形式(DLL形式)

2、RabbitMQ的RPC模式

3、WebAPI(http)

4、TcpAPI(WCF net.tcp)

5、Thrift

--------------------

##    1、组件形式(DLL形式) ##

>实现原理  
炼金炉可以单独一个solution, 维护资金相关操作的代码. 交易平台可直接引用炼金炉生成的某些DLL,以此来实现调用逻辑的问题  
**>动态扩展(负载均衡)**  
组件随宿主系统,完全支持动态扩展,   
LB只需要网站层采用Nginx即可  
**>异构交互(java,php等实时交互)**  
不支持异构交互  
**>技术风险**  
某些同步操作可能需要分布式锁, 或者代码逻辑采用乐观锁的方式, 这个要看具体的逻辑是否能容忍.  
如果采用ibatis作为dal,那么sql-xml要跟随DLL一起侵入到宿主系统,有一定的维护复杂度

## 2、RabbitMQ的RPC模式 ##

**>实现原理**  
调用方将调用信息按照一定的序列化协议序列成字节流,发送至特定的method-call-queue,然后读取  
Callback-queue(此时会被lock住). 服务提供方接收调用请求,处理逻辑,并将结果序列化后发送至callback-queue,调用进程被唤醒,接收结果,继续执行.参考如下:图  
![Center][]  
**>动态扩展(负载均衡)**  
RabbitMQ本身就已经充当了LB的角色,  
作为Sever的consumer可随时扩展.  
**>异构交互(java,php等实时交互)**  
当序列化协议定义清晰并有完善文档的时候, 可以完美支持异构系统交互  
**>技术风险**  
序列化协议有一定的维护成本  
需要健壮的RabbitMQ集群!

## **3、WebAPI(http)** ##

**>实现原理**  
调用方将调用信息按照一定的序列化协议序列成字节流, 然后调用服务方的HTTP-API, 然后读取处理结果.  
**>动态扩展(负载均衡)**  
Nginx做LB, 内网DNS完善的情况下, 很容易做动态扩容.  
**>异构交互(java,php等实时交互)**  
当序列化协议定义清晰并有完善文档的时候, 可以完美支持异构系统交互  
**>技术风险**  
序列化协议有一定的维护成本  
需要内网的DNS解析  
内部各模块namespace有一定的维护管理成本.

## **4、TcpAPI(WCF net.tcp)** ##

**>实现原理**  
如果采用直接tcp交互, 那基本就只能选择WCF net.tcp方式, 因为自己维护tcp-remoting的类库,开发代价太大,异常风险太高.  
调用方调用服务方的WCF-net.tcp接口, 然后读取处理结果.   
不需要自定义序列化协议.  
**>动态扩展(负载均衡)**  
Nginx可以做tcp-stream的LB  
**>异构交互(java,php等实时交互)**  
因wcf本身序列化协议的复杂程度, 几乎不支持异构系统.  
**>技术风险**  
Nginx对于stream的负载均衡支持较为复杂, 学习维护成本较高, 对于这种方式的健壮性我也持谨慎态度(比如我们系统发布等环节)

具体的部署实例，见我的另一篇《[NET架构部署方案][NET]》

## **5、Thrift** ##

**>实现原理**  
开源的跨语言交互中间件,内建独立的序列化协议,社区支持还不错,各语言驱动支持也比较完备.  
**>动态扩展(负载均衡)**  
它本身就是LB,各种service可动态扩容  
**>异构交互(java,php等实时交互)**  
对异构系统支持较好.  
**>技术风险**  
对于零经验的我们来说,学习部署维护成本都很高,应对突发情况和疑难问题的手段十分有限.

**综合分析下来, 个人倾向于方式2和方式3, 用好这两种方式的关键点在于序列化协议的定义维护和管理.**

**请大家给出自己看法,谢谢!**

[Center]: /images/20220805/10bfdc02baaa4bb7b025eaa9d455cc59.png
[NET]: https://blog.csdn.net/alex_xfboy/article/details/48207305