我知道消息传递系统是无阻塞和可扩展的，应该在微服务环境中使用。
我所质疑的用例是：
假设有一个管理 Jmeter 板客户端负责发送api请求来创建item对象。有一个提供api端点的微服务，它使用mysql数据库来存储项目。还有一种微服务，它使用ElasticSearch来进行文本搜索。
如果此管理 Jmeter 板客户端：
答。发送2个api调用；1调用mysql服务和另一个elasticsearch服务
或者
b。向mysql服务和elasticsearch服务都要使用的主题发送消息？
考虑a或b的利弊是什么？
我在想，当只有2个微服务在使用这个主题时，这有点过分了。而且，管理员创建item对象的频率非常小。
2条答案
按热度按时间z8dt9xmd1#
就像软件架构中的许多东西一样，这取决于。您的需求、sla和业务需求应该使它更清晰。
正如您所注意到的，消息传递系统并没有阻塞，而且更具可伸缩性，但是，api通信也有它的优点。
一般来说，restapi最适合于请求/响应交互，其中客户端应用程序通过http向api后端发送请求。
消息流最适合于在出现新数据或事件时发出通知，您可能希望对其采取操作。
在您特定的情况下，我会选择一个更具可伸缩性和非阻塞性的消息传递系统。
dtcbnfnu2#
您的a方法是将“路由”逻辑耦合到应用程序中。假设您需要执行一个api调用来审核您的请求，那么您将需要更改代码并向应用程序逻辑添加另一个调用。正如您所说的，这种方法是同步的，除非您不提供线程逻辑，否则您的调用将被排成一行并且不会扩展，即调用mysql-->wait response，然后调用elastic search-->wait response。。。在任何情况下，如果您需要立即一致性，也就是说，一个操作的结果调用提供了第二个操作，那么您可以选择这种方法。
b方法将路由逻辑解耦，因此，对事件感兴趣的任何其他服务都可以订阅主题并执行预期的操作。完全异步和可扩展。在这里，你将有最终的一致性，你必须恢复任何可能的失败。