Net大型系统间调用的问题_系统之间互相调用怎么避免中间环节出问题-优快云博客

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

1、组件形式(DLL形式)

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

2、RabbitMQ的RPC模式

>实现原理
调用方将调用信息按照一定的序列化协议序列成字节流,发送至特定的method-call-queue,然后读取
Callback-queue(此时会被lock住). 服务提供方接收调用请求,处理逻辑,并将结果序列化后发送至callback-queue,调用进程被唤醒,接收结果,继续执行.参考如下:图

>动态扩展(负载均衡)
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架构部署方案》

5、Thrift

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

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

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