假设我只有 2 个服务 Billing 和 Orders 以及一个 API 网关，它可能会向这些服务发送请求以进行计费或创建订单。
鉴于这种新的订单场景：
我的应用程序逻辑应该放在哪里？对这些服务的调用是否应该同步完成（在其余 api 中）？还是每个服务都应该负责调用另一个？例如：
新用户订单请求 -> Rest API -> 调用订单服务创建订单 ->（如果成功）Rest API ->（如果成功）调用计费服务
或者
新用户订单请求 -> Rest API -> 调用订单服务创建订单 -> 返回响应。然后订单服务从那里异步接收东西？
谢谢！
【问题讨论】：
标签： architecture microservices
新用户订单请求 -> Rest API -> 调用订单服务创建订单 -> 返回响应。然后订单服务从那里异步获取东西？
异步执行一些不必同步处理的事情总是一个好主意！然而，这并不总是可能的。例如，如果您必须在订单服务的响应中返回一个帐单 ID - 这必须是一个同步用例。
新用户订单请求 -> Rest API -> 调用订单服务创建订单 ->（如果成功）Rest API ->（如果成功）调用计费服务
您在此描述中称为Rest API 的东西实际上是一项业务服务（创建订单，然后 - 如果成功 - 创建计费信息 - 是业务逻辑）。您的网关应该非常愚蠢，我建议您不要自己编写它们！ There is plenty of gateway solution out there!
假设网关现在与订单（并且只与订单）服务通信，您需要某种方式让计费服务知道，它需要为此订单创建计费信息！我从您的问题中假设这不一定需要同步发生，所以我同意 sean-farmar 的观点：使用某种异步通信让计费服务知道您创建了一个新订单。还要考虑计费服务也发送一条消息，一旦它完成创建计费信息，因此订单服务可以接收此通知并将账单的 ID 添加到订单中。像这样你完全异步：
由于这是异步发生的，并且您的消息可能会以某种方式被缓冲，因此两个服务中的一个可能会死掉而不会关闭另一个。一旦他们重新活过来 - 他们只需要处理未完成的消息！
顺便说一句：更新只是意味着终止并启动服务的新版本 - 这意味着您现在可以安全地更新服务，而不会影响系统的正常运行时间或 SLA！
如果有帮助，请告诉我！
【讨论】：
您的问题不完整，但我可以尝试从标题中猜出问题...
每个组件都应该有自己的业务逻辑，组件（或微服务）需要完全自治，不共享任何内容，无代码无数据。
组件可以引发事件（使用消息传递）来传达附加的事实。
有意义吗？
【讨论】：