导读
天下大势，分久必合合久必分。软件也是一样。
微服务是最新的架构风格，有望解决我们以前的架构风格所遇到的所有问题。就像其他风格一样，它也有自己的挑战。下面我们来讨论的问题是如何在保持服务尽可能自主的同时实现微服务之间的耦合。在这里，将描述四个选项，并在结论中选择一个明确最好的方式。
对我来说，微服务是一种自主服务，它对一项业务能力负全部责任。完整的职责包括演示，API，数据存储和业务逻辑。Autonomous是我的关键词，通过使服务自治，可以更改服务，而不会对其他服务产生影响或影响最小。如果服务是自治的，那么一个服务中的操作问题应该对其他服务的功能没有影响。
这听起来都是个好主意，但服务永远不会是完全孤立的岛屿。服务实际上总是依赖于其他服务提供的数据。例如，假设购物车微服务作为网上商店的一部分，一些其他服务必须将商品放入购物车中，并且购物车内容必须提供给其他服务以完成订单并将其发送。现在的问题是如何在保持最大自主权的同时实现这些耦合。这篇博客文章的目的是解释在保持最大自治权的同时应该遵循哪种模式来结合微服务。
我将在两个方面构建模式; 交互模式，以及使用此模式交换的信息。
交互模式：请求 - 回复与发布 - 订阅。
请求 - 回复意味着一个服务执行特定 的信息请求（或采取某些操作）。然后它期待一个回应。因此，请求服务需要知道什么是aks以及在哪里询问它。这仍然可以异步实现，当然你可以放置一些抽象，使得请求服务不必知道其他服务的物理地址，仍然有一点是一个服务明确询问 特定 信息（或者要采取的行动）并在功能上等待回应。
发布 - 订阅：使用此模式，服务将自身注册为对某些信息感兴趣，或者能够处理某些请求。然后，相关信息或请求将被发送给它，并且它可以决定如何处理它。在这篇文章中，我们假设存在某种中间件来处理已发布消息到订阅服务的交付。
交换的信息：事件与查询/命令
事件是无法争论的事实。例如，创建编号为123的订单。事件只说明发生的事情。他们没有描述由于这种事件会发生什么。
查询/命令：两者都传达应该发生的事情。查询是对信息的特定请求，命令是对接收服务采取某些操作的特定请求。
将这两个维度放在矩阵中会产生4个选项来实现微服务之间的耦合。那么每个选项的优缺点是什么？哪一个最适合达到最大自治权？
在下面的描述中，我们将使用2个服务来说明每个模式。负责管理订单的订单服务，以及负责运送物料的运输服务，例如订单中包含的物品。像这样的服务可以是网上商店的一部分，然后可以包含购物车，产品（搜索）服务等服务。
1.请求回复事件：
在此模式中，一个服务向特定的 其他服务询问发生的事件（自上次询问以来）。这意味着这两种服务之间的依赖性很强。对于与订单相关的事件，Shipping服务必须知道要连接的服务。还存在运行时依赖性，因为如果订单服务可用，则送货服务将仅能够发送新订单。
由于Shipping服务仅接收事件，因此必须根据这些事件中的信息自行决定何时可以发送订单。订单服务不需要了解有关运输的任何信息，它只是提供说明订单发生的事件的事件，并且有责任完全对请求事件的服务采取行动。
2.请求 - 回复命令/查询：
在此模式中，装运订单服务将要求装运服务发送订单。这意味着强耦合，因为订单服务明确要求特定服务来处理运输。现在，订单服务必须确定订单何时准备发货。它意识到航运服务的存在，它甚至知道如何与它进行交互。如果在运输订单之前应考虑与订单本身无关的其他因素（例如客户的信用状态），那么订单服务应在请求运输服务发运订单之前考虑到这一点。现在，业务流程已融入体系结构中，因此无法轻松更改体系结构。
同样存在运行时依赖性，因为订单服务必须确保将运送请求成功传送到运输服务。
3.发布 - 订阅活动
在Publish-Subscribe with Events中，Shipping服务将自己注册为对与Orders相关的事件感兴趣。注册后，它将接收与订单相关的所有事件，而不知道订单事件的来源是什么。它松散地耦合到Order事件的来源。运输服务需要保留事件中收到的数据的副本，以便在订单准备好发货时可以得出结论。
订单服务需要不了解运输。如果多个服务提供包含运输服务相关数据的订单相关事件，则运输服务无法识别。如果提供订单事件的服务（其中一个）已关闭，则运输服务将无法识别，它只会收到较少的事件。此服务不会阻止送货服务。
4.发布 - 订阅命令/查询
在Publish-Subscribe with Command / Queries中，Shipping服务将自身注册为能够运送东西的服务。然后它接收所有想要运送东西的命令。运输服务不必知道运输命令的来源，另一方面，订单服务不知道哪个服务将负责运输。从这个意义上讲，它们是松散耦合的。但是，订单服务意识到订单必须在发出发货命令后才能发货，这确实使联接更加强大。
结论
现在我们已经描述了四个选项，我们回到最初的问题，上述4的哪种模式提供了最大的自治权？
两个请求 - 应答模式都意味着两个服务之间的运行时耦合，这意味着强耦合。命令/查询模式都暗示一个服务知道另一个服务应该做什么（在上面的示例中，订单服务知道另一个服务负责运送），这也意味着强耦合，但这次是在功能级别上。这留下了一个选项：
3。发布 - 订阅事件。
在这种情况下，两个服务都不会从运行时和功能角度了解彼此的存在。对我而言，这是实现服务之间最大自治的明显赢家。
下一个问题：是否应该始终使用Publish-Subscribe与事件相结合的服务？
答案：如果您唯一关心的是服务的最大自主权，答案是肯定的，但是，应该在帐户中考虑更多因素。总是使用这种模式进行耦合需要付出代价。例如，数据被复制，必须采取措施来处理丢失的事件，事件驱动的体系结构确实增加了对基础架构的额外要求，并且可能存在额外的延迟。