分布式微服务中的第三方系统交互规范( 二 ) _分布式

单向通知式API：包括服务的命令消息通道，以及服务接受的命令式消息的具体类型和格式。

3.1.2 记录事件发布服务还可以使用发布/订阅的方式对外发布事件。此API风格的规范包括事件通道以及服务发布到通道的事件式消息的类型和格式。
消息和消息通道模型是一种很好的抽象，也是设计服务异步API的好方法。但是，为了实现服务，需要选择具体的消息传递技术并确定如何使用它们的能力来实现设计。
3.2 使用代理消息消息代理是所有消息的中介节点。发送方将消息写入消息代理，消息代理将消息发送给接收方。使用消息代理的一个重要好处是发送方不需要知道接收方的网络位置。另一个好处是消息代理缓冲消息，直到接收方能够处理它们。有许多消息代理可供选择。流行的开源消息代理包括：

Apache RocketMQ

RabbitMQ

Apache Kafka

3.3 并发处理和消息顺序如何在保留消息顺序的同时，横向扩展多个接收方的实例。为了同时处理消息，拥有多个实例是一个常见的要求。而且，即使单个服务实例也可能使用线程来同时处理多个消息。使用多个线程和服务实例来并发处理消息可以提高应用程序的吞吐量。但同时处理消息的挑战是确保每个消息只被处理一次，并且是按照它们发送的顺序来处理的。
Kafka使用consumer group，特定的每个事件都发布到同一个分片，而且该分片中的消息始终由同一个接收方实例读取。这样做就能够保证按顺序处理这些消息。
3.4 重复消息处理理想情况下，消息代理应该只传递一次消息，但保证有且仅有一次的消息传递通常成本很高。相反，大多数消息代理承诺至少成功传递一次消息。当系统正常工作时，保证传递的消息代理只会传递一次消息。但是客户端、网络或消息代理的故障可能导致消息被多次传递。假设客户端在处理消息后、发送确认消息之前，它的数据库崩溃了，这时消息代理将再次发送未确认的消息，在数据库重新启动时向该客户端或客户端的另一个副本发送。
3.4.1 编写幂等消息处理器如果应用程序处理消息的逻辑是满足幂等的，那么重复的消息就是无害的。通常情况下应用程序逻辑通常不是幂等的。或者可能正在使用消息代理，该消息代理在重新传递消息时不会保留排序。重复或无序消息可能会导致错误。在这种情况下，就必须编写跟踪消息并丢弃重复消息的消息处理程序。
3.4.2 跟踪消息并丢弃重复消息消息接收方使用message id跟踪它已处理的消息并丢弃任何重复项。

【分布式微服务中的第三方系统交互规范】