我一直在努力将部分我们的soa架构（Mule ESB）迁移到微服务（Spring Boot堆栈），但是我面临着与大流量相关的问题，我们有几个流程。 基本上我们有一个用户ID作为输入的流量，响应是用户帐户，信用卡数据，股票和贷款的复合。 在这个流程中，我们在开始时有一个分离器（允许发送并发请求），我们向账户后端，3个不同的信用合作伙伴，股票合作伙伴和贷款合作伙伴发送请求，最后有一个agregattor（等待所有响应）并合并所有这些）最后一个节点用于准备响应（应用业务逻辑）。
在迁移过程中，我们开发了帐户微服务，贷款微服务，股票微观服务和信用卡微服务（每个合作伙伴1个）。这里的问题是编排，我们不能使用和事件模型方法，因为我们需要在某一点获得所有响应。我们也考虑了编排方法，但是我们不想添加与我们的微服务如何协调调用的逻辑，因为这将是重度耦合服务（N * N连接）的后退。
我们正在考虑制作一个可用作协调器的新微服务，但我们不知道这是否是微服务概念的良好解决方案。
注意：前端无法进行编排，因为它是一个封闭的产品，我们无法触摸它。
提前致谢。
答案 0 :(得分：1)
我们正在考虑制作一个将用作协调器的新微服务，但我们不知道这是否是微服务概念的良好解决方案。
从你描述的所有内容来看，这听起来是最合理的事情。您将此服务描述为具有自己的业务目的，这表明我可能需要专门的服务。而且它需要来自其他（更基本的）服务的输入这一事实对于复杂的域服务来说并不罕见。此外，您已经在前端列出了聚合的替代方法，即在您的域中无效的内容。
需要考虑的是确保基本服务的开发团队将其API视为面向客户（客户是您的其他服务）。这意味着他们必须在版本控制/弃用/等方面做清洁工作。 下游服务需要像使用第三方API一样处理消费的API。例如谷歌到目前为止，允许内部服务消费收取实际资金，以激励优化依赖服务的实施。