对于整个微服务浪潮来说，我还是一个新手。我一直在研究良好的微服务环境背后的架构和原理。
定义微服务的主要内容之一应该是每个服务的松散耦合性质。 微服务A 永远不要直接调用微服务B ，否则您将有效地创建一个整体式系统，从而失去体系结构模式提供的可伸缩性。
问题/示例
如果我开发了一个返回GUID的微服务（例如），则可以合理地建议环境中的其他微服务可以在需要时直接调用GUID服务。
我知道可以使用多种排队系统将数据从一项服务传递到下一项服务，但是在我看来，它们主要用于插入，删除或更新。
我无法理解如何将队列用于简单读取（例如我的GUID示例），以及为什么您不只是直接从另一个微服务调用GUID服务。
注意：返回GUID只是一个示例，我知道大多数语言都可以在内部生成它们
对此有些澄清，将不胜感激。
答案 0 :(得分：2)
您不应照原样遵守所有规则。
此规则有很多例外，许多系统的实践证明它不适用于每种情况或系统。
我不同意微服务A不应将微服务B称为一般规则的限制，因为它不适用于所有情况。我已经使用了多个系统 微服务，而我们不遵循这一点。
微服务之间的通信：
您可以使用多种方式在微服务之间进行通信，例如：
事件（使用队列）
命令-通过API直接调用另一个微服务（这是对微服务的某种指令） 需要进行更改（创建，更新，删除）。
查询-通过API直接调用另一个微服务（例如获取GUID的示例）。 再次有人会说这也是一个命令。 在同时使用CQRS的同时，经常结合使用查询作为术语。
共享的Db（大多数在线资源会告诉您不要这样做 由于多种原因） 通常，不建议使用此方法。
一般
您应该根据自己的需求来使用系统，而不是基于固定的规则，例如 “微服务A绝不能呼叫微服务B”。
我将举例说明为什么：
示例：
假设您拥有“微服务A”和“微服务B”。您的“微服务B”正在使用“微服务A”通过Kafka发布的事件。消费事件时，“微服务B”正在其自己的数据库中存储一些相关的“外部”数据（将其复制）。 这是一种常见的方法，它在每次需要一些数据时都不调用“微服务A”。例如，这很常见 如果“微服务A”是某些具有系统配置设置或类似设置的服务。
让我们说您有灾难的场景，其中数据库和“微服务B”中的所有数据都被破坏或损坏。 为了解决该问题，您可以恢复备份并应用最近一次的应用最新事件，比如说过去1小时，其中 您的“微服务B”已关闭并解决了问题（如果将事件处理实现为幂等）。在这种情况下一切都很好。
另一方面，如果您的系统在生产中运行了一段时间。经过一段时间，您开发了“微服务C”并决定 部署到生产中。事实证明，您需要“微服务A”产生的一些数据。您需要在“微服务C”上存储这些数据 作为外部数据，类似于您在“微服务B”中获得的数据。您如何获得这些数据？ 您是否消耗了“微服务A”中的所有事件？在理想世界中，您将永远将所有活动保留在卡夫卡。在这种情况下，您会 只需订阅事件并应用所有事件即可将所需的所有数据保存在“微服务C”中。 实际上，您需要为您的Kafka设置一些Retention Period，可以说5天。如果您的系统运行时间超过5天，则无法通过事件重新创建数据。
在这种情况下，您需要直接使用Command / Query调用服务并填充“微服务C”数据库。
这只是一个例子，您需要直接致电。
摘要：
还有许多其他示例，这种方法也有效。 例如，您经常需要同步调用另一个微服务，并且您将要等待响应（取决于您的业务场景）。最好的方法是直接通过Command / Query调用另一个微服务。