系统之间的通讯分为同步和异步。
这是一篇技术文章，需要一定的系统设计经验，如果有启发，请留言告诉我。
本文讨论的计算机程序定义在应用层，通信主要是交换数据信息。
也就是说各个业务系统之间如何传递数据信息。
同步（sync）就是实时响应，同时异步(async)就是发送等待式的。
异步(async)系统通讯可以说是构建服务化系统的核心。
以连接应用系统为主要目的。
提高系统可用性，稳定性，容错能力。
01 请求响应式交互
001 立即返回，轮循环取结果
接收方收到请求后立即返回收到结果。
同时后台任务继续执行相关操作，
最后的结果通过接收方轮询获取。
这样做的优势是简单明了。
同时也带来了性能消耗和轮询周期的不确定性。
在主流的 Linux 环境下，普遍的解决方案，使用系统自带的 Crontab 服务。
系统服务和应用服务之间的管理和维护是系统运行管理的一个隐患。
002 接受方注册回调地址
请求响应式通讯的第二种方式是 使用回调地址交互。
典型应用场景如下
支付系统与业务系统之间的信息通讯
业务系统会注册回调 URL 到支付平台，支付平台处理完成后，会把支付结果回传到业务系统。
业务系统再进行分发。
异步系统-注册回调
以下是支付宝开放平台，关于 app_auth_code 授权码的换取说明
在线下授权的业务场景中，商家成功将自己的应用授权给系统服务商（ISV）的第三方应用后，
商家的界面会跳转至第三方应用设置的授权回调地址。
在回调页面请求中会带上当次授权的授权码 app_auth_code 和 app_id，示例如下：
代码语言：javascript复制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 中间人订阅
了解异步调用的三种方式在实际编程开发中有什么好处呢？
- 第一点 可以根据实际应用场景，进行技术选型。
知道每个技术方案的优势和不足，在业务复杂和流量激增时如何应对和调整。
- 第二点 识别业务开发中的主流程和辅助流程。
区分核心操作和触发操作。
精炼的定义系统之间交互的消息元素 。
哪些是必须，哪些是非必须。对基本业务元素进行拆解。
本文内容参考 《左耳听风》弹力系统设计 《异步系统通信一节》 整理而成
文末是《系统化服务构建》系列文章目录
希望相关的内容对你有启发。
