精通springcloud：消息驱动的微服务，发布/订阅模型

发布/订阅模型

事实上，创建Spring Cloud Stream项目的主要动机是支持持久的发布/订阅模型。在前面的小节中，我们讨论了微服务之间的点对点通信，这只是一个附加功能。但是，无论我们是否决定使用点对点通信或发布/订阅模型，编程模型仍然是相同的。

 

在发布/订阅通信中，数据通过共享主题广播。它降低了生产者(Producer) 和使用者(Consumer)的复杂性，并允许将新应用程序轻松添加到现有拓扑中，而无须对流程进行任何更改。这可以在最后提供的系统示例中清楚地看到，在该系统中，我们决定添加第二个应用程序，它将使用源微服务生成的事件。与初始架构相比，开发人员必须定义专用于每个目标应用程序的自定义消息通道。通过队列直接通信，消息只能由一个应用程序实例使用，因此，解决方案是必要的。发布/订阅模型的使用简化了该架构。

运行示例系统

要开发采用发布/订阅模型的示例应用程序，比开发采用点对点通信的示例应用程序更简单。开发人员不必覆盖任何默认消息通道以启用与多个接收器的交互。与演示向单个目标应用程序(account-service 服务)传递消息的初始示例相比，这里只需要稍微修改一下配置设置。 由于Spring Cloud Stream 默认绑定到主题，因而不必为输.入消息通道覆盖exchangeType。正如以下配置片段所示，我们仍然在将响应发送到order-service 服务时使用点对点通信。如果认真思考一下就会发现，这自有其道理。order-service 微服务发送的消息必须由account-service服务和product-service 服务接收，而来自它们的响应仅针对order-service服务。

spring:

application:

name: product-service

rabbi tmq:

host: 192.168.99.100

port: 5672

cloud:

stream:

bindings:

output:

destination: orders-in

input:

destination: orders -out

rabbit:

bindings:

output

producer :

exchangeType: direct

routingKeyExpression: ‘ “#” ’

product-service服务的主要处理方法的逻辑非常简单。它只需要从收到的订单中找到所有的productld,更改每个产品的库存数量，然后将响应发送到order-service服务。

@Autowired

ProductRepository productRepository;

@Autowired

orderSender orde rSender ;

public void process(final Order order) throws JsonProcessingException {

LOGGER. info ("Order processed: { }"，mapper . writeValueAsString (order)) ;

for (Long productId : order . getPr