微服务间异步通信模式

两种常见的基于事件的模式包括任务队列和发布-订阅。在微服务架构设计时，开发者会经常遇到这两种模式——大部分更高级的交互模式是基于这两种基本模式实现的。

作业队列

工作者（worker）从作业队列中接收任务并执行它。不管开发者运行了多少个工作者实例，一个作业应该只处理一次。这种模式也称作赢者通吃。

事件驱动的服务间异步通信

一个任务队列将工作分发给1到n个消费者。

order服务创建的每个订单都会触发一个OrderCreated事件，这个事件会放到队列中供market网关服务来进行下单。这种模式在下列场景中很有用：

（1）事件与响应该事件所要做的工作之间是一对一的关系；

（2）要完成的工作比较复杂或者花费时间较长，所以需要和触发事件区分开。

默认这种方式并不需要复杂的事件传输。有许多任务队列类库可以用，它们使用的就是日常的数据存储方案，如Redis（Resque、Celery、Sidekiq）或SQL数据库。

发布-订阅

在发布-订阅模式中，服务可以向任意的监听器发送事件。所有接收到事件的监听器都要对事件相应地做出反应。在某些情况下，这是一种理想的微服务模式：一个服务可以发送任意的事件给外界，而不需要关心谁来处理它们。

开发者需要在订单发布以后触发另一个下游操作。开发者可能要给用户发送一条推送通知，需要用它满足订单统计和推荐功能的需要。这些功能都可以通过监听同样的事件来实现。

---

除了以上两种异步通信模式外，http请求后返回一个jobid，然后通过jobid查询进度，也是一种常见模式吧？为什么没被提到。

作业队列模式：服务A把作业任务存入redis中，celery从队列中接收到任务，并执行完成，且这个作业只能被执行一次。服务A不知道能不能从队列中拿到任务的完成情况和进度？

发布订阅模式，服务B发布消息，以Kafka为例，发布主题topic到kafka集群，这个主题也只能被一个消费者组中的任一消费者消费一次，但非消费者组内的其它多个消费者也可以消费到。这种方式就比作业队列的优势在于消息多播给多个消费者组，可以消费多次。一次发送多次消费。

摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》