本文详细探讨了同步通讯和异步通讯在信息传递中的区别，以及它们分别带来的优势和不足。通过对支付流程的案例分析，突显了同步通讯可能面临的阻塞和服务依赖问题，而异步通讯通过引入事件驱动模式和消息代理（Broker）成功解决了这些挑战，实现了服务解耦、性能提升和流量削峰。然而，异步通讯也并非没有考验，对消息代理可靠性的依赖和系统架构的复杂性都是需要仔细权衡的因素。在实际应用中，选择采用同步通讯还是异步通讯应当根据具体的业务场景和需求，以最优方式满足系统的通讯要求。
一、同步通讯的优点和问题
1、同步通讯介绍
同步通讯是指在进行信息交流时，发送者和接收者在数据传输的过程中需要保持一致的时间步调，即发送者发出数据后需要等待接收者完成对数据的处理，然后再进行下一步操作。
如图所示，支付完成后，支付服务需要依次请求订单服务、仓储服务、短信服务等等，需要等待上一个服务提供者的响应才可以走到下一个服务提供者，而且一旦遇到一个服务出问题，会导致整个流程都出现问题。
2、同步通讯的优点
3、同步调用的问题
微服务间基于Feign的调用就属于同步方式，存在一些问题。
-
耦合度高，每次加入新的需求都要修，导致资源浪费。
-
调用链中的每个服务在等待响应过程中不能释放请求占用的资源，高并发场景下性能下降，会极度浪费系统资源。
-
级联失败会导致调用者需要等待服务提供者的响应。如果服务提供者出现问题，所有调用方都会跟着出问题。
-
如果调用链过长，则响应时间等于每次调用的时间之和。如同多米诺骨牌一样，迅速改原来的代码会导致整个微服务群故障。
二、异步通讯的优点和问题
1、异步通讯介绍
异步调用常见实现就是事件驱动模式。
如下图，支付服务在完成支付以后，需要订单服务、仓储服务、短信服务各自完成自己的业务。
但是与同步调用不同，我们现在是事件儿驱动模式，不会像之前那样由支付服务来调用这三个服务，而是引入了一个东西叫 Broker（消息代理）。
当用户支付成功时，即触发一个特定事件。这个事件随后由我们的消息代理（broker）进行管理。订单服务、仓储服务和短信服务会向消息代理注册，以表达对支付成功事件的关注，并请求在事件发生时得到通知。这种机制被称为事件代理。
在订阅方面，一旦成功完成订阅，支付服务在未来检测到有用户支付成功时，将发布一个事件，宣告有人支付了，订单号为1001。消息代理随即发出通知，将消息传递给订单服务、仓储服务和短信服务。订单服务会立即响应，更新订单状态；仓储服务负责完成库存扣减和发货；而短信服务则负责发送相应的短信通知。
整个过程通过事件代理实现，确保各服务在业务事件发生时能够协同工作。
2、异步通讯的优点
3、异步调用的问题
-
依赖于Broker的可靠性、安全性、吞吐能力： 异步通讯架构中的消息队列作为Broker，其可靠性、安全性和吞吐能力直接影响整个系统。如果消息队列出现故障或不稳定，可能导致消息传递的延迟或丢失。
-
架构复杂了，业务没有明显的流程线，不好追踪管理： 异步通讯引入了消息队列和异步处理机制，使得系统架构更加复杂。由于消息的异步传递，业务流程线不再直观，可能导致追踪和管理业务流程的困难，特别是在故障排查和调试时。
三、同异步通讯总结
同步通讯在信息传递中要求发送者和接收者保持一致的时间步调，虽然简单直观，但容易面临服务依赖、阻塞等问题，尤其在微服务架构中可能导致级联失败。相反，异步通讯以事件驱动模式和消息代理的方式解决了同步通讯的局限性，实现了服务解耦、性能提升和流量削峰。然而，异步通讯也伴随着对消息代理可靠性和系统架构复杂性的挑战。
在实际应用中，选择采用同步通讯还是异步通讯需根据具体的应用场景和需求，平衡各自的优缺点。同步通讯适用于简单的、直观的业务流程，而异步通讯则更适合复杂的、高并发的系统，尤其在需要实现松耦合、提高系统性能、处理大量并发请求的场景中表现出色。因此，综合考虑业务特点和系统要求，合理选择通讯方式对于构建可靠、高效的分布式系统至关重要。