编排微服务

时间：2015-03-18 08:52:57

标签： http orchestration hypermedia microservices

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

如果微服务只知道自己的域名，但是有一个数据流要求多个服务以某种方式进行交互，那么该怎么办呢？

我们说我们有这样的事情：

发票
装运

为了论证，让我们说一旦订单发货，就应该创建发票。

在某个地方，有人按下GUI中的按钮，＆＃34;我已经完成了，让我们这样做！＆＃34; 在一个经典的整体服务架构中，我说有一个ESB处理这个，或者发货服务知道发票服务，只是调用它。

但是，在这个勇敢的微服务新世界中，人们处理这个问题的方式是什么？

我确实认为这可以被认为是基于意见的。但是它有一个具体的方面，因为微服务不应该做到这一点。因此，必须有一个＆＃34;它应该是什么，而不是＃34;，这不是基于意见的。

拍摄。

7 个答案:

答案 0 :(得分：269)

书籍Building Microservices详细描述了@RogerAlsing在答案中提到的风格。

在Orchestration vs Choreography下的第43页，该书说：

当我们开始模拟越来越复杂的逻辑时，我们必须处理管理跨越的业务流程的问题个人服务的边界。有了微服务，我们就会受到打击这个限制比平常更快。 [...]实际上实现这个流程，我们可以有两种架构跟随。通过编排，我们依靠中心大脑来指导和推动这个过程，就像管弦乐队的指挥一样。同编舞，我们通知系统的每个部分，并让它弄清楚细节，就像舞者一样，找到自己的方式在芭蕾舞剧中对周围的人做出反应。

然后，本书继续解释这两种风格。业务流程样式更多地与orchestration/task services的SOA思想相对应，而编排样式对应于Martin Fowler的文章中提到的dumb pipes and smart endpoints。

业务流程风格

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

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

注意：我认为当作者提到工具时，他指的是BPM之类的内容（例如Activity，Apache ODE，Camunda）。事实上，Workflow Patterns Website有一套很棒的模式来进行这种编排，它还提供了不同供应商工具的评估细节，这有助于以这种方式实现它。我不认为作者暗示需要使用这些工具之一来实现这种集成方式，但是可以使用其他轻量级编排框架，例如， Spring Integration，Apache Camel或Mule ESB

但是，other books我已经阅读过有关微服务的主题，一般来说，我在网络上找到的大部分文章似乎是disfavor this approach的编排，而是建议使用下一个。

编舞风格

在编舞风格下，作者说：

通过精心设计的方法，我们可以改为拥有客户 service以异步方式发出事件，称Customer 创建。电子邮件服务，邮政服务和忠诚度积分银行然后只需订阅这些事件并作出相应的反应[...] 这种方法明显更加分离。如果有的话它只是为了达到创建客户所需的其他服务需要订阅事件并在需要时完成工作。该缺点是我们看到的业务流程的明确视图 [工作流程]现在只能隐含地反映在我们的系统中[...] 这意味着需要额外的工作来确保您可以监控并追踪正确的事情发生了。例如，你会吗？知道忠诚点银行是否有错误，并且由于某种原因没有设置正确的帐户？我喜欢处理这个问题的一种方法是建立一个明确匹配视图的监控系统 [工作流程]中的业务流程，但随后跟踪每个流程服务作为独立的实体，让你看到奇怪的异常映射到更明确的流程流。 [流程图] [...]不是驱动力，而只是一个透镜我们可以看到系统的行为方式。一般来说，我发现了更倾向于编排方法的系统更多松散耦合，更灵活，更易于改变。你做需要做额外的工作来监控和跟踪整个系统的流程但是，边界。我发现了最重要的精心策划实施变得非常脆弱，变化成本更高。考虑到这一点，我非常希望能够进行精心设计系统，每项服务都足够聪明，可以理解其中的角色整个舞蹈。

注意：到目前为止，我仍然不确定编排是否只是event-driven architecture（EDA）的另一个名称，但如果EDA只是一种方法，那么其他方法是什么？（另见What do you mean by "Event-Driven"?和The Meanings of Event-Driven Architecture）。此外，像CQRS和EvenSourcing这样的东西似乎与这种建筑风格产生了共鸣，对吧？

现在，这之后很有趣。微服务书并不假设微服务将用REST实现。事实上，在本书的下一部分中，他们将继续考虑基于RPC和SOA的解决方案，最后考虑REST。这里重点是微服务并不意味着REST。

那么，HATEOAS呢？

现在，如果我们想要遵循RESTful方法，我们不能忽视HATEOAS或Roy Fielding将非常高兴地在他的博客中说我们的解决方案不是真正的REST。在REST API Must be Hypertext Driven上查看他的博文：

我对因调用任何基于HTTP的人数感到沮丧接口REST API。制作REST需要做些什么建筑风格明确了超文本是一个概念约束？换句话说，如果应用程序的引擎状态（和因此API）不是由超文本驱动的，那么它不可能 RESTful，不能是REST API。期。是否有一些破损的手册某处需要修复？

所以，正如你所看到的，Fielding认为如果没有HATEOAS，你就不会真正构建RESTful应用程序。对于守备HATEOAS是协调服务的方法。我只是在学习这一切，但对我来说，HATEOAS没有明确定义实际跟踪链接背后的驱动力是谁或是什么。在可能是用户的UI中，但在计算机到计算机的交互中，我认为需要由更高级别的服务来完成。

根据HATEOAS，API消费者真正需要知道的唯一链接是启动与服务器通信的链接（例如POST /订单）。从现在开始，REST将执行流程，因为在此端点的响应中，返回的资源将包含指向下一个可能状态的链接。然后，API使用者决定要关注的链接并将应用程序移动到下一个状态。

尽管听起来有多酷，但客户端仍然需要知道链接是否必须是POST，PUTed，GETed，PATCHed等。客户端仍需要确定要传递的有效负载。客户端仍然需要知道如果失败该怎么办（重试，补偿，取消等）。

我对这一切都相当新，但对我来说，从HATEOAs的角度来看，这个客户端或API使用者是一个高阶服务。如果我们从人的角度来思考它，你可以想象一个网页中的最终用户，决定要遵循的链接，但是网页的程序员还必须决定使用什么方法来调用链接，以及有效载荷通过。所以，就我而言，在计算机到计算机的交互中，计算机扮演最终用户的角色。这就是我们所谓的业务流程服务。

我想我们可以将HATEOAS用于编排或编排。

API网关模式

Chris Richardson提出了另一个有趣的模式，他也提出了他所谓的API Gateway Pattern。

在单一体系结构中，应用程序的客户端，例如web   浏览器和本机应用程序通过加载发出HTTP请求   平衡器应用于N个相同的实例之一。但在一个   微服务架构，巨石已被取代   服务的集合。因此，我们需要回答一个关键问题   是客户与之互动的？

应用程序客户端（例如本机移动应用程序）可以制作   RESTful HTTP请求到各个服务[...]表面上   这似乎很有吸引力。但是，可能会有一个   个人API之间的粒度明显不匹配   客户要求的服务和数据。例如，显示一个   网页可能需要调用大量服务。   例如，Amazon.com   describes怎么样   页面需要拨打100多项服务。甚至可以提出这么多要求   通过高速互联网连接，更不用说更低的带宽，   更高延迟的移动网络将是非常低效的并且导致   用户体验不佳。

更好的方法是让客户少量生产   每页请求，可能只有一个，通过Internet到a   前端服务器称为API网关。

API网关位于应用程序的客户端和   微服务。它提供了为客户量身定制的API。该   API网关为移动客户端和a提供粗粒度API   为使用高性能的桌面客户端提供更细粒度的API   网络。在此示例中，桌面客户端发出多个请求   检索有关产品的信息，作为移动客户端   提出单一请求。

API网关通过向某些请求发出请求来处理传入请求   高性能LAN上的微服务数量。 Netflix，for   例，   describes   每个请求如何平均支持六个后端服务。在这   例如，来自桌面客户端的细粒度请求很简单   代理相应的服务，而每个粗粒度   来自移动客户端的请求通过聚合结果来处理   调用多种服务。

API网关不仅可以优化客户端之间的通信   和应用程序，但它也封装了细节   微服务。这使得微服务无需进化   影响客户。例如，两个微服务可能是   合并。另一个微服务可能被分成两个或更多个   服务。只需要更新API网关以反映这些   变化。客户不受影响。

现在我们已经了解了API网关如何介入   应用程序及其客户端，现在让我们来看看如何实现   微服务之间的沟通。

这听起来非常类似于上面提到的业务流程风格，只是意图略有不同，在这种情况下，它似乎都是关于性能和简化交互。

进一步阅读

我最近在NGINX Blog发表了一系列很多文章，我建议深入研究所有这些概念：

答案 1 :(得分：30)

尝试在这里汇总不同的方法。

域事件

这种主导方法似乎是使用域事件，其中每个服务都发布有关已发生事件的事件，其他服务可以订阅这些事件。这似乎与Martin Fowler在此描述的智能端点，哑管的概念密切相关：http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes

Domain events

代理

另一个看起来很常见的apporach是将业务流程包装在自己的服务中。代理协调微服务之间的交互，如下图所示：

Proxies

答案 2 :(得分：6)

那么，微服务的编排与不是“微观”的旧SOA服务的编排有何不同？一点都没有。

微服务通常使用http（REST）或消息/事件进行通信。业务流程通常与业务流程平台相关联，这些业务流程允许您在服务之间创建脚本化交互以自动化工作流。在旧的SOA时代，这些平台使用了WS-BPEL。今天的工具不使用BPEL。现代编排产品的示例：Netflix Conductor，Camunda，Zeebe，Azure Logic Apps，Baker。

请记住，业务流程是一种复合模式，它提供了多种功能来创建复杂的服务组合。微服务通常被视为不应参与复杂组合而更自主的服务。

我可以看到在协调工作流中调用微服务来进行一些简单的处理，但我没有看到微服务是orchestrator服务，它通常使用诸如补偿事务和状态存储库（脱水）之类的机制。

答案 3 :(得分：4)

所以你有两项服务：

发票微服务
货运微服务

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

了解所有服务并实施用例的简单GUI（“我已完成”调用货件服务）
业务流程引擎，等待“我已完成”事件。该引擎实现了用例和流程。
一个业务流程微服务，假设订单处理服务本身知道您域名的流量/用例
我还没有想到的任何其他事情

这一点的主要观点是控制是外在的。这是因为所有应用程序组件都是单独的构建块，松散耦合。如果您的用例发生更改，则必须在一个位置更改一个组件，即业务流程组件。如果添加不同的订单流，则可以轻松添加另一个不会干扰第一个订单流的协调器。微服务思维不仅涉及可扩展性和花哨的REST API，还涉及清晰的结构，减少组件之间的依赖关系以及重用整个企业共享的通用数据和功能。

HTH，马克

答案 4 :(得分：1)

如果需要管理州，那么使用CQRS的事件采购是理想的沟通方式。此外，异步消息系统（AMQP）可用于微服务间通信。

从您的问题来看，显然具有CQRS的ES应该是正确的组合。如果使用java，请看一下Axon框架。或者使用Kafka或RabbitMQ构建自定义解决方案。

答案 5 :(得分：0)

原始问题的答案是SAGA模式。

答案 6 :(得分：-1)

我写了几篇关于这个主题的帖子：

也许这些帖子也可以提供帮助：

API网关模式 - 课程粒度api与细粒度apis

https://www.linkedin.com/pulse/api-gateway-pattern-ronen-hamias/ https://www.linkedin.com/pulse/successfulapi-ronen-hamias/

粗粒度与细粒度服务API

根据定义，粗粒度服务操作的范围比细粒度服务更广，尽管这些术语是相对的。粗粒度增加了设计复杂性，但可以减少完成任务所需的调用次数。在微服务架构中，粗粒度可以驻留在API网关层，并协调若干微服务以完成特定的业务操作。粗粒度API需要经过精心设计，因为涉及多个微服务，管理不同的专业领域存在混合问题的风险，这些问题涉及单一API并违反上述规则。粗粒度API可能会为业务功能建议新的粒度级别，否则就不存在。例如，雇员可能涉及两个微服务调用HR系统来创建员工ID，另一个调用LDAP系统来创建用户帐户。或者客户端可能已经执行了两次细粒度的API调用来实现相同的任务。虽然粗粒度表示业务用例创建用户帐户，但细粒度API表示此类任务涉及的功能。更细粒度的API可能涉及不同的技术和通信协议，而粗粒度将它们抽象为统一流程。在设计系统时，再考虑两者都没有解决所有问题的黄金方法，并且每个方法都有一个传统。粗粒度特别适合作为其他业务环境中使用的服务，例如其他应用程序，业务线，甚至是跨越自身企业边界的其他组织（典型的B2B场景）。