01-分析同步通讯/异步通讯的特点及其应用

同步通讯/异步通讯

微服务间通讯有同步和异步两种方式

同步通讯: 类似打电话场景需要实时响应(时效性强可以立即得到结果方便使用),而且通话期间不能响应其他的电话(不支持多线操作)
异步通讯: 类似发邮件场景不需要马上回复并且可以多线操作(适合高并发场景)但是时效性弱响应会有延迟

`同步通讯的缺点`

微服务间基于Feign的调用就属于同步方式,虽然调用可以实时得到结果但是存在一些问题

耦合度高: 每次加入或删除业务都需要去支付服务中改动原来的代码
性能/吞吐能力下降: 调用者(支付服务)需要等待服务提供者响应完成后才能执行下一步的操作,如果调用链过长则响应时间等于每次调用服务的时间之和
资源浪费: 调用者(支付服务)在等待服务提供者响应过程中啥也不干却一直占用着CPU和内存,高并发场景下会极度浪费系统资源
级联失败: 如果服务提供者(仓储服务)出现问题会导致所有的请求都卡在这里,最后随着请求越来越多支付服务也会将系统资源耗尽导致整个微服务故障

// 用户支付完成支付服务调用其他服务
public void PaymentService() {// 调用订单服务完成订单状态修改orderService.doSth();// 调用物流服务从仓库分配响应的库存并准备发货storageService.doSth();messageService.doSth();...
}

`异步通讯`

异步调用的常见实现是事件驱动模式,如购买商品时用户支付后需要调用订单服务完成订单状态修改，调用物流服务从仓库分配响应的库存并准备发货

支付服务是事件发布者(publisher),在支付完成后只需要发布一个支付成功的事件(event),事件中带上订单Id
订单服务和物流服务是支付成功事件的订阅者(Consumer),订阅者监听到自己订阅的事件发布后就会执行对应的业务逻辑代码
Broker: 事件发布者与订阅者之间的并不是直接通信(解耦合),发布者只负责发布事件到Broker(不关心订阅者),订阅者负责从Broker订阅事件(不关心发布者)

异步通讯的优点