如何编排微服务

Posted 2023-03-08

【中文标题】如何编排微服务

【英文标题】：how Orchestrate microservices

【发布时间】：2018-08-05 08:41:41

【问题描述】：

我一直在尝试将我们的部分 soa 架构（Mule ESB）迁移到微服务（Spring Boot 堆栈），但我面临一个与我们有多个编排的大型流相关的问题。 基本上，我们有一个以用户 ID 作为输入的流程，响应由用户帐户、信用卡数据、股票和贷款组成。 在这个流程中，我们一开始有一个拆分器（允许发送并发请求），我们将请求发送到账户后端、3 个不同的信用卡合作伙伴、股票合作伙伴和贷款合作伙伴，最后有一个聚合器（等待所有响应并合并所有这些），最后是一个用于准备响应的节点（应用业务逻辑）。

在迁移过程中，我们开发了账户微服务、贷款微服务、股票微服务和信用卡微服务（每个合作伙伴 1 个）。这里的问题是编排，我们不能使用事件模型方法，因为我们需要在某个时间点获得所有响应。我们也考虑了编排方法，但我们不想添加与调用相关的逻辑，因为这将是对重耦合服务（N*N 连接）的退步。

我们正在考虑制作一个新的微服务，用作编排器，但我们不知道这是否是微服务概念的一个很好的解决方案。

注意：前端无法编排，因为它是一个封闭的产品，我们无法触摸它。

提前致谢。

【参考方案1】：

我们正在考虑制作一个新的微服务，用作编排器，但我们不知道这是否是微服务概念的一个很好的解决方案。

从你所描述的所有情况来看，这听起来是最合理的做法。您将此服务描述为具有自己的业务目的，这向我表明了对专门服务的潜在需求。而且它需要来自其他（更基本的）服务的输入这一事实对于复杂的域服务来说并不罕见。此外，您已经将前端聚合的替代方法列为在您的域中不起作用的东西。

需要考虑的只是确保基础服务的开发团队将他们的 API 视为面向客户（客户是您的其他服务）。这意味着他们必须在版本控制/弃用/等方面做干净的工作。 下游服务需要像对待第 3 方 API 一样对待使用的 API。例如，Google 到目前为止允许向内部服务消费收取真金白银，以激励优化相关服务的实施。