我们正在尝试实现微服务体系结构，以使用Asp.NET Core在当前环境中创建我们的新应用程序。我们的第一代微服务将使用请求/答复通信模式，并且不需要任何Message Broker。但是，两年后我们将拥有一个Message Broker。
两年后，在开发方面是否需要花费大量精力使我们的微服务适应使用Message Broker并采用发布/订阅通信模式？
什么是好的方法？我们是否应该已经在没有Message Broker的情况下使用像Akka.NET这样的东西？我们是否应该稍后再添加Akka.net，以使微服务使用发布/订阅通信模式？
感谢并提出各种建议。
答案 0 :(得分：1)
从一开始就采取正确的做法。微服务的主要目的是松耦合服务。您可能最初没有意识到，但有时可能需要它。技术上req / resp是重构的整体。将事件驱动的体系结构与消息代理一起使用稍微复杂一点，但好处却是深远的。想象一下，有越来越多的微服务加入俱乐部，使用pub sub非常容易。
回到第二点，稍后可能需要大量精力进行重构和包含消息代理。例如您决定选择CQRS和事件源，这对于分布式应用程序是非常常见的模式。您将需要系统的主要重新架构师。但是对于简单的应用程序，可能不需要这些模式，并且根据您的业务需要，您必须决定服务的弹性，可用性和分离性，如果可以简单地满足需求，那么值得付出努力。
如果您想使用真正的微服务架构，那么它将从消息代理可能进行的异步通信开始。
希望有帮助。