假设我只有2个服务结算和订单以及一个API网关，这些网关可能会向这些服务扇出请求以进行结算或创建订单。
鉴于此新订单方案：
我的应用逻辑应该放在哪里？并且是否应该同步完成对这些服务的调用（在其余的api内）？或者每个服务应该负责打电话给另一个？例如：
新用户订单请求 - ＆gt; Rest API - ＆gt;调用订单服务来创建订单 - ＆gt; （如果成功）Rest API - ＆gt; （如果成功）调用结算服务
或
新用户订单请求 - ＆gt; Rest API - ＆gt;调用订单服务来创建订单 - ＆gt;返回响应。那么从那里开始异步订购服务？
谢谢！
答案 0 :(得分：2)
新用户订单请求 - ＆gt; Rest API - ＆gt;调用订单服务来创建订单 - ＆gt;返回响应。那么从那里开始异步订购服务？
异步执行不需要同步处理的内容总是一个好主意！然而，它并不总是可行的。例如，如果您必须返回结算ID以及订单服务的响应 - 必须是同步用例。
新用户订单请求 - ＆gt; Rest API - ＆gt;调用订单服务来创建订单 - ＆gt; （如果成功）Rest API - ＆gt; （如果成功）调用结算服务
您在此说明中调用Rest API的内容实际上是一项业务服务（创建订单，然后 - 如果成功 - 创建帐单信息 - 是业务逻辑）。你的网关应该是非常愚蠢的，我建议你不要自己写！ There is plenty of gateway solution out there！
假设网关现在与订单（并且只是订单）服务进行通信，您需要某种方式让计费服务知道，它需要为此订单创建帐单信息！我从你的问题中假设这不一定需要同步发生，所以我同意sean-farmar对此：使用某种异步通信让计费服务知道你创建了一个新订单。在完成创建结算信息后，还要考虑结算服务以发送消息，因此订单服务可以接收此通知并将订单的ID添加到订单中。像这样你完全异步：
由于这是异步发生的，并且您的消息可能以某种方式被缓冲，因此其中一个服务可以在不关闭另一个服务的情况下死亡。一旦他们再次生活 - 他们只需要处理好的消息！
顺便说一下：更新只是意味着杀死并启动新版本的服务 - 这意味着您现在可以安全地更新服务，而不会影响系统或SLA的正常运行时间！
请告诉我这是否有用！
答案 1 :(得分：1)
您的问题尚不完整，但我可以尝试从标题中猜出问题......
每个组件都应该拥有自己的业务逻辑，组件（或微服务）需要完全自治，不需要共享，没有代码，没有任何数据。
组件可以引发事件（使用消息传递）来传达附加的事实。
有意义吗？