我应该使用哪种消息模式？

Question

我想开发一个微服务体系结构应用程序，它可以将文本消息从一个通信提供者发送到另一个通信提供者，而我只是在考虑更改体系结构最适合应对巨大的工作量波动。

通过REST委托发送一条短信，然后发送到Whatsapp、Telegram和电子邮件。因此，发送消息的端点无法知道消息可以以多快或多可靠的速度传递给外部提供者。

到目前为止，我只为我的微服务使用了请求应答模式，并且不知道在这个使用过程中是否值得特别注意保持服务异步和使用发布-订阅模式？你认为这是个好主意吗?还是不值得用一个消息brocker引入更多的复杂性？在只有发送消息的端点使用发布-订阅的情况下，混合解决方案会更好吗？会是一个基于事件的解决方案吗？

我的发布-订阅堆栈: Kubernetes流中的微服务，并部署在Kubernetes上。

我的请求回复堆栈: Go中的微服务与gRCP一起部署在Kubernetes上。

Answer 1

我对Go没有任何经验，但对我来说，微服务的关键要素之一是尽可能松散地进行交流。事件处理是减少发送方和接收方之间耦合的一种方法，因为(如果实现得当)，发送方不需要知道谁在监听，接收方不需要知道是谁发送的。

但是，当一个服务告诉另一个服务做一些事情时，这种耦合就会(部分)返回，至少从时间的角度看是这样:当发送方想调用API时，接收方必须始终处于启动和运行状态。

为什么会发送短信？导致发送的业务事件是什么？

举个例子，我假设某个网站上的人下了订单，你想用Whatsapp、电报和电子邮件来确认订单。在本例中，我将创建一个事件OrderPlaced。然后，您可以创建一个倾听该事件并决定发送Whatsapp、电报或邮件的服务。

这就是命令和事件之间的区别:事件总是描述过去发生的事情(OrderPlaced)。一个命令告诉另一个组件做一些事情(SendConfirmation)。

这里的关键是，您从订单处理服务中提取了一个责任，并将其隔离到一个单独的服务中。如果你愿意的话，你还可以创建三种服务来收听同样的事件:一种是Whatsapp，一种是电报，另一种是电子邮件。这将是最终的脱钩。如果要创建第四种通知可能性，则不需要更改任何组件。您可以只部署一个新服务。这降低了您的Whatsapp被打破的风险，当您添加第四个通知(或更改电报)。

编辑:要回答你的问题:是的，我认为使用事件是个好主意。确定是否需要发送确认与处理订单是一种不同的责任，因此您应该隔离它们。

希望这能有所帮助。