我们正在尝试使用Asp.NET Core在我们当前的环境中实现微服务架构创建我们的新应用程序。第一代微服务将使用请求/回复通信模式，不需要任何Message Broker。但是，我们将在2年后拥有一个Message Broker。
是否需要花费很多努力才能使我们的微服务使用Message Broker并在两年后进行发布/订阅通信模式？
什么是好方法？我们现在应该使用类似Akka.NET的东西而不需要Message Broker吗？我们以后是否应该推动Akka.net使微服务使用发布/订阅通信模式？
谢谢并感谢各种建议。
从头开始吧。微服务的主要目的是松散耦合的服务。你最初可能没有意识到，但在某些时候你可能需要它。技术上req / resp被重构为单片。使用带有消息代理的事件驱动架构稍微复杂一点，但其好处是深远的。想象你有越来越多的微服务加入俱乐部，使用pub sub非常容易。
回到第二点，重构并包含消息代理可能是一项重大工作。例如您决定选择CQRS和事件源，这是分布式应用程序非常常见的模式。你需要系统的主要设计师。但对于简单的应用程序，可能不需要这些模式，并且根据您的业务需求，您必须决定您的服务应该具有弹性，可用性和解耦性，并且只需简单地满足需求就值得付出努力。
如果您想要真正的微服务架构，那么它可以通过消息代理进行异步通信。
希望有所帮助。