我对整个微服务潮流相当陌生。我一直在研究良好的微服务环境背后的架构和原理。
定义微服务的主要内容之一应该是每个服务的松散耦合性质。微服务A永远不应该打电话微服务B直接，或者您正在有效地创建一个整体系统，该系统失去了架构模式提供的可扩展性。
问题/例子
例如，如果我开发一个返回 GUID 的微服务，那么建议环境中的其他微服务在需要时可以直接调用 GUID 服务是合理的。
我知道可以使用各种排队系统将数据从一项服务传递到另一项服务，但在我看来，它们主要用于插入、删除或更新。
我无法理解如何使用队列进行简单读取（如我的 GUID 示例）以及为什么不直接从另一个微服务调用 GUID 服务。
注意：返回 GUID 只是一个示例，我知道大多数语言都能够在内部生成它们
如果能澄清这一点，我们将不胜感激。
您不应该按原样遵守每条规则。
该规则有许多例外，并且许多系统的实践证明它并不适用于每种情况或系统。
我不同意微服务 A 永远不应该调用微服务 B 作为一般规则的限制，因为它并不适用于所有情况。我曾使用过多个系统
微服务，而我们却没有遵循这一点。
微服务之间的通信：
您可以使用多种方式在微服务之间进行通信，例如：
事件（使用队列）
命令 - 通过 API 直接调用另一个微服务（这是对微服务的某种指令）
需要进行更改（创建、更新、删除）。
查询 - 通过 API 直接调用另一个微服务（例如获取 GUID 的示例）。
有些人又会说这也是一个命令。
使用 Query 作为术语时，通常会结合使用CQRS https://martinfowler.com/bliki/CQRS.html以及。
共享数据库（大多数在线资源会告诉你不要这样做
出于多种原因）
一般来说，这不是推荐的方法。
一般来说
您应该根据您的需求来使用您的系统，而不是基于像这样的固定规则
“微服务 A 永远不应该调用微服务 B”。
我给你举个例子，为什么：
Example:
假设您有“微服务 A”和“微服务 B”。您的“微服务 B”正在消费“微服务 A”通过 Kafka 发布的事件。 “微服务 B”在使用事件时将一些相关的“外部”数据存储在自己的数据库中（复制它）。
这是一种常见的方法，即每次需要“微服务 A”的一些数据时都不会调用它。这很常见，例如
如果“微服务A”是具有系统配置设置或类似的某些服务。
假设您遇到灾难场景，您的数据库和“微服务 B”中的所有数据都被破坏或损坏。
为了解决这个问题，您可以恢复备份并应用最近 1 小时的最新事件
您的“微服务 B”已关闭并解决问题（如果您的事件处理实现为幂等）。在这种情况下一切都很好。
另一方面，如果您的系统在生产环境中运行了一段时间。经过某个时间点，您开发“微服务 C”并决定
将其部署到生产中。事实证明，您需要“微服务A”产生的一些数据。您需要“微服务 C”上的数据
作为外部数据，类似于“微服务 B”。你如何获得这些数据？
您消费了“微服务A”的所有事件吗？在理想的世界中，您将永远保留卡夫卡中的所有事件。在这种情况下你会
只需订阅事件并应用所有事件即可将您需要的所有数据保存在“微服务C”中。
实际上你需要设置一些保留期限 https://www.cloudkarafka.com/blog/2018-05-08-what-is-kafka-retention-period.html比如说 5 天。如果您的系统运行时间超过 5 天，您将无法从事件重新创建数据。
在这种情况下，您需要直接使用 Command/Query 调用服务并填充“微服务 C”数据库。
这只是您需要直接调用的一种边缘情况示例。
Summary:
还有许多其他例子表明这种方法也是有效的。
例如，很多时候，您需要同步调用另一个微服务，并且您需要等待响应（取决于您的业务场景）。最好的方法是使用命令/查询直接调用另一个微服务。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
