C# 当使用ESB（即MassTransit）时，微服务如何才能真正独立？

我正在使用MassTransit对当前的单片系统进行初步的分解研究。我使用基于队列的ESB的主要原因是，我首先要解决的一组特性是使用共享数据库作为队列

我也读过“构建微服务”，虽然我还没有完成它，但其中一个核心原则似乎是微服务本质上应该是独立的

---

我如何协调使用MassTransit这一必要的共享消息库（或至少是合同）和这些服务不必“了解”彼此的事实？

问题实际上是关于耦合的。你们的各种服务的耦合程度如何？”“独立”意味着松散耦合的程度，但为了互操作，需要某种程度的耦合。面临的挑战是在保持互操作性的同时尽可能松散地进行耦合，从而使您的组件能够协同工作以实现所需的结果

通过消息契约的耦合是松散耦合。这只需要您的每个服务都知道并理解在它们之间传递的数据（消息）的“形状”。这些服务不需要共享任何代码、主机甚至平台

在使用ESB时，这种消息共享知识是您的服务需要相互“了解”的唯一内容。根据您使用的传输类型，您可能还需要为每个服务提供其他服务的位置（URI）的知识，但同样，这是一个非常松散的耦合（空间），可以通过DNS等进一步放松。如果您选择使用代理传输，例如RabbitMQ之类的集中式排队技术，则可以消除这种空间耦合，但这需要进行其他权衡

---

请记住，MassTransit不是.NET空间中唯一可用的选项。例如，一个流行的选择是（完全公开：我为特定软件工作，NSB是我们的产品之一）。

这是一个很好的答案，我想补充一点，作为MassTransit的维护者，我看到人们试图将行为推到他们的信息中。将服务更紧密地耦合在一起。我们鼓励人们只使用消息契约的接口来帮助实现这一点。耦合不是一个大问题，你只有几个服务。但是，当您采用这种方法来添加功能时，您将得到30项服务。那么，结合就成了一个真正的挑战。谢谢，特拉维斯。这就是我一直采用的方法，虽然我仍在学习MassTransit 3的一些学习曲线，但仅通过接口“耦合”的效果很好。