Http 编排微服务

编排微服务的标准模式是什么

如果一个微服务只知道它自己的领域，但是有一个数据流需要多个服务以某种方式交互，那么该怎么做呢

假设我们有这样的东西：

• 发票
• 装运

为了便于讨论，假设订单发货后，应该创建发票

在某个地方，有人在

GUI

中按下一个按钮，“我完成了，让我们开始吧！” 在一个经典的整体式服务体系结构中，我想说要么有一个

ESB

来处理这个问题，要么发货服务知道发票服务并调用它

但是，在这个崭新的微服务世界里，人们是如何处理这个问题的呢

我确实明白这可以被认为是高度基于意见的。但它有一个具体的方面，因为微服务不应该做上述工作。 因此，必须有一个“根据定义，它应该做什么”，这不是基于意见的

---

拍摄。

因此您有两项服务：

发票微服务

装运微服务

在现实生活中，你会有一些东西，你持有秩序的状态。我们称之为订单服务。接下来是订单处理用例，它们知道当订单从一种状态转换到另一种状态时该做什么。所有这些服务都包含一组特定的数据，现在您需要一些其他的东西来完成所有的协调。这可能是：

• 一个简单的GUI，了解您的所有服务并实现用例（“我完成了”调用发货服务）
• 一个业务流程引擎，它等待一个“我完成了”事件。该引擎实现用例和流程
• 一个编排微服务，比如订单处理服务本身，它知道您的域的流程/用例
• 还有什么我没想到的吗

主要的一点是控件是外部的。这是因为所有应用程序组件都是松散耦合的独立构建块。如果您的用例发生更改，您必须在一个位置更改一个组件，即编排组件。如果添加不同的订单流，则可以轻松添加另一个不会干扰第一个业务流程的业务流程。微服务思想不仅是关于可伸缩性和实现奇特的REST API，还涉及清晰的结构、减少组件之间的依赖性以及重用在整个业务中共享的公共数据和功能

---

嗯，马克

试图在这里总结不同的方法

域事件 这方面的主要方法似乎是使用域事件，其中每个服务发布关于发生了什么的事件，其他服务可以订阅这些事件。 这似乎与Martin Fowler在这里描述的智能端点、哑管道的概念相一致：

代理 另一种似乎很常见的方法是将业务流包装在自己的服务中。 其中，代理协调微服务之间的交互，如下图所示：

构图的其他模式 这本书包含各种构图模式。

这本书详细描述了@Rogerasing在回答中提到的风格

在第43页“编排与编舞”下，书中写道：

当我们开始对越来越复杂的逻辑建模时，我们必须处理 管理跨业务流程的问题 个人服务的边界。借助微服务，我们将 这一限制比平常要快。[…]实际上 实现这个流程，我们可以使用两种风格的体系结构 跟着。有了配器，我们依靠一个中枢大脑来引导和控制 推动这个过程，就像管弦乐队的指挥一样。具有 在编排过程中，我们通知系统的每个部分它的工作，并让它 确定细节，就像舞者找到自己的路一样 在芭蕾舞中对周围的人做出反应

本书接着解释了这两种风格。编排风格更符合的是SOA理念，而编排风格则对应于Martin Fowler的文章中提到的

编排风格

在这种风格下，上述书提到：

让我们来考虑一下，业务流程解决方案对于 这个流程。在这里，可能最简单的方法就是 我们的客户服务是中心大脑。在创造方面，它谈论 致忠诚积分银行、电子邮件服务和邮政服务[…]， 通过一系列请求/响应调用。这个 然后，客户服务本身可以跟踪客户所在的位置 过程它可以检查客户的帐户是否已设置 向上发送，或发送电子邮件，或发送邮件。我们得走了 流程图[…]并将其直接建模为代码。我们甚至可以使用 为我们实现这一点的工具，可能使用适当的 规则引擎。商业工具正是以这种形式存在的 业务流程建模软件的开发。假设我们使用同步 请求/响应，我们甚至可以知道每个阶段是否有效[…] 这种编排方法的缺点是客户 服务可能会变得过于中央管理机构。它可以 成为网络中间的枢纽和逻辑的中心点 开始生活。我已经看到这种方法导致了少量的 智能“上帝”服务告诉贫血的CRUD服务该做什么

注意：我想当作者提到工具时，他指的是类似的东西（例如）。事实上，有一组很棒的模式来进行这种编排，它还提供了不同v的评估细节