什么时候使用 Rest API 而不是 AMQP 在内部微服务之间进行通信更好或更合理？
我知道使用 Rest API 服务会更加相互依赖，所以我们是否可以说我们应该始终避免这种情况并使用 AMQP？
xar*_*rgs 13
什么时候使用 Rest API 而不是 AMQP 在内部微服务之间进行通信更好或更合理？
这在很大程度上取决于您的业务/域运营以及您的需求。确实，在大多数情况下，两个微服务之间的大多数通信（或在大多数用例中）将通过队列完成。在某些情况下，需要通过 Rest API 直接调用或者是更好的选择。这取决于您的业务需求。我认为如果你想获得最好的结果，你应该根据情况使用这两种方法。例如，假设您有一个在线商店应用程序并且有 4 个微服务：
通过 Rest API 使用直接调用
例如，假设您想要完成订单并添加一种付款方式，您将使用该方式为购物车中的产品付款。举例来说，您使用信用卡付款。如果您的业务逻辑表明在关闭订单之前信用卡必须有效，您需要从订单微服务调用支付微服务。此调用将以同步方式与通过 Rest API 的直接调用同步，后者将等待响应。在这种情况下，您需要等待响应，因为您的进一步逻辑取决于您的信用卡（付款方式）是否有效。
在这种情况下，发布事件订单微服务并在支付微服务中侦听该事件将产生更多延迟、更复杂的事件处理逻辑和回滚场景。有人可能会问一个问题：
如果支付微服务宕机或无法访问怎么办？
无论您使用直接调用还是对队列进行更复杂的操作都没有关系。如果没有支付微服务，您将无法继续/完成您的操作。在这种情况下，您可能会返回内部服务器错误或类似错误，并要求客户重试该操作。有时，某些微服务之间的耦合度高于其他微服务之间的耦合度。这取决于微服务架构的设计和操作的复杂性。
使用队列
大多数时候，微服务之间的通信案例可以通过队列完成。典型的例子是，如果您在网上商店创建新产品。产品微服务使用有关该产品的所有信息创建一个产品。当产品被创建并存储在产品微服务数据库中时，会发布一个事件，如“ProductCreatedEvent”。products-inventory-micro-service 正在侦听事件“ProductCreatedEvent”，并将有关该产品的信息保存到 Product-inventory-micro-service-db（例如产品数量、每个商店的可用性等）。产品库存微服务将产品包含在其库存中后，该产品就可以销售。此时客户可以将该产品放入购物车。回到产品的创造。事实上，当您创建产品时，它不必立即显示在库存中。从业务角度来看，您可以接受这样的情况：您刚刚创建的产品（最终）出现在库存中，延迟为 50 毫秒、100 毫秒、1 秒、10 秒或 10 分钟。即使产品库存微服务在产品创建期间关闭，它也不会停止产品创建操作。一旦产品库存微服务启动并运行，它将处理“ProductCreatedEvent”并且产品将可供销售。
这两个操作示例经过简化，只是为您提供可能存在不同用例的示例。当然，您可以通过不同的方式做到这一点，但想法是给您一个例子。您可以看到，这两个具有完全不同业务上下文的操作可以根据业务需求以两种不同的方式完成。
我知道使用 Rest API 服务会更加相互依赖，所以我们是否可以说我们应该始终避免这种情况并使用 AMQP？
绝对不是。使用微服务的分布式系统将需要通过 Rest API 或其他协议（如 SOAP（或其他协议））使用从微服务到微服务的直接调用。有时你需要同步和阻塞调用。对于大多数运营和业务领域来说，这种情况可能很少见，但在需要时将其作为一个选项仍然非常重要。您可以在此处阅读此答案，了解微服务如何相互通信。