我知道消息传递系统是无阻塞且可伸缩的，应该在微服务环境中使用。
我要询问的用例是：
想象一下，有一个管理仪表板客户端负责发送API请求以创建Item对象。有一个微服务提供API端点，该端点使用应在其中存储Item的MySQL数据库。还有另一种将弹性搜索用于文本搜索目的的微服务。
此管理仪表板客户端是否应该：
A。发送2个API调用； 1调用MySQL服务和另一个elasticsearch服务
或
B。向主题发送消息以供MySQL服务和elasticsearch服务使用？
考虑A或B时有什么优缺点？
我认为当只有2个微服务正在使用此主题时，这有点过头了。另外，管理员创建Item对象的频率非常小。
答案 0 :(得分：1)
与软件体系结构中的许多事情一样，这取决于。您的要求，SLA和业务需求应使其更加清晰。
正如您所指出的，消息传递系统并没有阻塞并且具有更大的可伸缩性，但是，API通信也使它更具优势。
通常，REST API最适合于客户端应用程序通过HTTP向API后端发送请求的请求/响应交互。
消息流最适合在发生新数据或事件时您可能要采取行动的通知。
在您的特定情况下，我将使用具有更高可伸缩性和非阻塞性的消息传递系统。
答案 1 :(得分：-1)
您的一种方法是将“路由”逻辑耦合到您的应用程序中。假设您需要执行API调用来审核您的请求，那么您将需要更改代码并将另一个调用添加到应用程序逻辑中。如您所说，这种方法是同步的，除非您不提供线程逻辑，否则您的调用将排成一行并且无法扩展，即，调用mysql->等待响应，然后调用弹性搜索->等待响应， ... 在任何情况下，如果需要立即保持一致（例如，将一个动作的结果调用提供给第二个动作），则可以使用这种方法。
B方法将路由逻辑解耦，因此，对该事件感兴趣的任何其他服务都可以订阅该主题并执行预期的操作。完全异步和可扩展。在这里，您将具有最终的一致性，并且必须恢复任何可能的故障。