微服务的交互模式。

服务与服务之间的交互模式可以分为以下3类。

同步调用模式

在同步调用模式中,服务1调用服务2,服务1的线程阻塞等待服务2返回处理结果,如果服务2一直不返回处理结果,则服务1一直等待超时为止。

同步调用模式如下图所示。

同步调用模式适用于大规模、高并发的短小操作,而不适用于后端负载较高的场景,例如:几乎所有JDBC的实现完全使用BIO同步阻塞模式。

接口异步调用模式

在接口异步调用模式中,服务1请求服务2受理某项任务,服务2受理后即可返回个i服务1其受理结果,如果受理成功,则服务1继续做其他任务,而服务2异步的处理这项任务,直到服务2处理完这项任务后,才反向的通知服务1任务已经完成,服务1再后续处理。

接口异步调用模式如下图所示。

接口异步调用模式适用于非核心链路上负载较高的处理环节,这个环节经常耗时较长,并对时效性要求不高。例如:在B2C电商系统中,一件商品售卖成功后,需要给相应的商户入账收入,这个过程对时效性要求不高,可以使用接口异步调用模式。

消息队列异步处理模式

消息队列异步处理模式利用消息队列作为通信机制,在这种交互模式中,通常服务1只需将某种事件传递给服务2,而不需要等待服务2返回结果。在这样的场景下,服务1与服务2可以充分解耦,并且在大规模、高并发的微服务系统中,消息队列对流量具有消峰的功能。

消息队列异步处理模式如下图所示。

消息队列异步处理模式与接口异步调用模式类似,多应用于非核心链路上负载较高的处理环节中,并且服务的上游不关心下游的处理结果,下游也不需要向上游返回处理结果。例如:在电商系统中,用户下订单支付且交易成功后,后续的物流处理适合使用消息队列异步处理模式,因为物流发货属于物流和配送系统的职责,不应该影响交易,所以交易系统不需要对其有感知。

以上三种交互模式普遍应用于服务化和微服务架构中,他们之间没有绝对的好坏,只需要在特定场景下做出更适合的选择。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值