系统服务化构建-异步系统通信的三种方式

系统之间的通讯分为同步和异步。

这是一篇技术文章，需要一定的系统设计经验，如果有启发，请留言告诉我。

本文讨论的计算机程序定义在应用层，通信主要是交换数据信息。

也就是说各个业务系统之间如何传递数据信息。

同步（sync）就是实时响应，同时异步(async)就是发送等待式的。

异步(async)系统通讯可以说是构建服务化系统的核心。

以连接应用系统为主要目的。

提高系统可用性，稳定性，容错能力。

01 请求响应式交互

001 立即返回，轮循环取结果

接收方收到请求后立即返回收到结果。

同时后台任务继续执行相关操作，

最后的结果通过接收方轮询获取。

这样做的优势是简单明了。

同时也带来了性能消耗和轮询周期的不确定性。

在主流的 Linux 环境下，普遍的解决方案，使用系统自带的 Crontab 服务。

系统服务和应用服务之间的管理和维护是系统运行管理的一个隐患。

002 接受方注册回调地址

请求响应式通讯的第二种方式是 使用回调地址交互。

典型应用场景如下

支付系统与业务系统之间的信息通讯

业务系统会注册回调 URL 到支付平台，支付平台处理完成后，会把支付结果回传到业务系统。

业务系统再进行分发。

异步系统-注册回调

以下是支付宝开放平台，关于 app_auth_code 授权码的换取说明

在线下授权的业务场景中，商家成功将自己的应用授权给系统服务商（ISV）的第三方应用后，

商家的界面会跳转至第三方应用设置的授权回调地址。

在回调页面请求中会带上当次授权的授权码 app_auth_code 和 app_id，示例如下：

http://example.com/doc/toAuthPage.html?app_id=2015101400446982&app_auth_code=ca34ea491e7146cc87d25fca24c4cD11`

系统服务商（ISV）解析出 app_auth_code 后，调用 alipay.open.auth.token.app 接口，并在接口代码中通过传入 app_auth_code 来换取 app_auth_token 的授权码

但凡基于开放平台的应用系统，回调地址通讯是通用解决方案。

分布式系统的服务设计需要向无状态看齐

这里的回调还是有数据状态的耦合。

02 使用订阅的方式

接收方和发送方以消息队列为交互枢纽。

发送方把消息或者数据发送到消息中心的消息队列中，接收方从消息中心获取数据。

实际开发中，我们通常会约定一个队列名称，消息发送方和接收方共同维护这个队列。

订单订阅时序图

如图，业务系统之间通过事件进行通讯，也就是事件驱动设计，服务之间通过交换信息，完成整个流程的驱动。

下图是基于事件驱动的发布订阅模型

发布订阅模型

03 使用 Broker 方式

Broker 方式也叫做中间人订阅方式。

Broker 作为系统间通讯的中间角色，彻底分离消息发送方和接收方，也就是上游系统和下游系统。

常见的消息队列组件都还可以认为是这样的角色。

Broker

总结

本文主要分析了异步系统通信的三种方式

• 1 请求响应
• 2 直接订阅
• 3 中间人订阅

了解异步调用的三种方式在实际编程开发中有什么好处呢？

• 第一点 可以根据实际应用场景，进行技术选型。

知道每个技术方案的优势和不足，在业务复杂和流量激增时如何应对和调整。

• 第二点 识别业务开发中的主流程和辅助流程。

区分核心操作和触发操作。

精炼的定义系统之间交互的消息元素 。

哪些是必须，哪些是非必须。对基本业务元素进行拆解。

本文内容参考 《左耳听风》弹力系统设计 《异步系统通信一节》 整理而成

文末是《系统化服务构建》系列文章目录

希望相关的内容对你有启发。