我总是鼓励在不知道存在其他服务（隔离）的情况下设计每项服务。
几天前，我正在阅读有关微服务架构编排的编排和优点，我遇到了这个话题， 假设我们有一个由3种服务组成的系统：订购，付款，发货。如果我使用协调器，协调器知道何时以及如何调用每个服务。事实上它的职责是知道如何以及何时调用什么服务，但在编排中，我不知道何时付款服务不知道订购服务是否存在如何订阅其活动（当然至少订购系统需要付款型号）？
当我开始认为，如果我们在订购服务中有一种方法可以返回订购信息，然后是付款数据和运输数据，那么我会变得更加困惑。它将如何返还付款和运输数据？
答案 0 :(得分：1)
当支付服务不知道订购服务存在时，它将如何订阅其活动（确定至少订购系统需要有支付模式）？
如果业务目的需要，服务可以知道另一个服务。只要确保你没有弄清楚目的并确保任何一项服务的独立开发过程，例如：正确地编辑您的API并制定过时策略。谷歌甚至对团队之间的服务使用征收内部费用。
也允许使用两种服务使用的代码库，只要您像处理第三方库一样处理这些库依赖项。
如何退回付款和发货数据？
根据聚合过程的复杂性，您可以拥有负责依赖于支付和运输服务的业务范围的第3服务，或者您拥有允许合并/拆分请求的专用聚合器组件从前端（有时作为API Gateway的一部分实现）。如果您的聚合逻辑很复杂，请创建专用服务，否则您可以使用通用aggregator。