编排微服务的标准模式是什么?
如果微服务只知道它自己的域,但是有一个数据流要求多个服务以某种方式交互,那么它的方法是什么?
假设我们有这样的事情:
-
开具发票
-
装运
为了论证,让我们说一旦订单发货,就应该创建发票 .
在某个地方,有人按下GUI中的按钮,“我已经完成了,让我们这样做!”在一个经典的整体服务架构中,我会说有一个ESB处理这个,或者Shipment服务知道发票服务并且只是调用它 .
但是,在这个勇敢的微服务新世界中,人们处理这个问题的方式是什么?
我确实认为这可以被认为是基于意见的 . 但是它有一个具体的方面,因为微服务不应该做上述事情 . 所以必须有一个“定义应该做什么而不是”,这不是基于意见的 .
射击 .
7 回答
书Building Microservices详细描述了@RogerAlsing在他的回答中提到的风格 .
在Orchestration vs Choreography下的第43页上,该书说:
然后,本书继续解释这两种风格 . 业务流程样式更多地与orchestration/task services的SOA思想相对应,而编排样式对应于Martin Fowler的文章中提到的dumb pipes and smart endpoints .
Orchestration Style
在这种风格下,上面的书提到:
注意:我想当作者提到工具时,他指的是像BPM(例如Activity,Apache ODE,Camunda) . 事实上,Workflow Patterns Website有一套很棒的模式来进行这种编排,它还提供了不同供应商工具的评估细节,有助于以这种方式实现它 . 我不认为作者暗示需要使用这些工具之一来实现这种集成方式,但是可以使用其他轻量级编排框架,例如, Spring Integration,Apache Camel或Mule ESB
但是,在网络中找到的other books似乎是业务流程的disfavor this approach,而是建议使用下一个 .
Choreography Style
在编舞风格下,作者说:
注意:到目前为止,我仍然不确定编排是否只是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 .
So, What About HATEOAS?
现在,如果我们想要遵循RESTful方法,我们不能忽视HATEOAS或Roy Fielding将非常高兴地在他的博客中说我们的解决方案不是真正的REST . 在REST API Must be Hypertext Driven上查看他的博文:
所以,正如你所看到的,Fielding认为如果没有HATEOAS,你就不会真正构建RESTful应用程序 . 对于守备HATEOAS是协调服务的方法 . 我只是在学习这一切,但对我来说,HATEOAS没有明确定义实际跟踪链接背后的驱动力是谁或是什么 . 在可能是用户的UI中,但在计算机到计算机的交互中,我认为需要由更高级别的服务来完成 .
根据HATEOAS,API消费者真正需要知道的唯一链接是启动与服务器通信的链接(例如POST /订单) . 从这一点开始,REST将进行流程,因为在此 endpoints 的响应中,返回的资源将包含指向下一个可能状态的链接 . 然后,API使用者决定要遵循的链接并将应用程序移动到下一个状态 .
尽管听起来有多酷,但客户端仍然需要知道链接是否必须是POST,PUTed,GETed,PATCHed等 . 客户端仍需要确定要传递的有效负载 . 如果失败,客户端仍然需要知道该怎么做(重试,补偿,取消等) .
我对这一切都很陌生,但对我来说,从HATEOAs的角度来看,这个客户端或API使用者是一个高级服务 . 如果我们从人的角度来思考它,你可以想象一个网页中的最终用户,决定要遵循的链接,但是网页的程序员还必须决定使用什么方法来调用链接,以及有效载荷通过 . 所以,就我而言,在计算机到计算机的交互中,计算机扮演最终用户的角色 . 再一次,这就是我们所谓的编排服务 .
我想我们可以将HATEOAS用于编排或编排 .
The API Gateway Pattern
Chris Richardson提出了另一种有趣的模式,他也提出了他所谓的API Gateway Pattern .
这听起来非常类似于上面提到的编排风格,只是略有不同的意图,在这种情况下,它似乎都是关于性能和简化交互 .
Further Reading
最近在_773868中发表了一系列很多文章,我建议深入研究所有这些概念:
Introduction to Microservices
Building Microservices: Using an API Gateway
Building Microservices: IPC in a Microservices Architecture
Service Discovery in a Microservices Architecture
Event-Driven Data Management for Microservices
Choosing a Microservices Deployment Strategy
Refactoring a Monolith into Microservices
试图在这里汇总不同的方法 .
域事件
对此的主要方法似乎是使用域事件,其中每个服务发布有关已发生事件的事件,其他服务可以订阅这些事件 . 这似乎与Martin Fowler在这里描述的 smart endpoints, dumb pipes 的概念齐头并进:http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes
代理
另一个看起来很常见的应用是将业务流程包装在自己的服务中 . 代理协调微服务之间的交互,如下图所示:
.
那么,微服务的编排与不是“微观”的旧SOA服务的编排有何不同?一点也不 .
微服务通常使用http(REST)或消息/事件进行通信 . 业务流程通常与业务流程平台相关联,这些业务流程允许您在服务之间创建脚本化交互以自动化工作流 . 在旧的SOA时代,这些平台使用了WS-BPEL . 今天的工具不使用BPEL . 现代编排产品的示例:Netflix Conductor,Camunda,Zeebe,Azure Logic Apps,Baker .
请记住,业务流程是一种复合模式,它提供了多种功能来创建复杂的服务组合 . 微服务通常被视为不应参与复杂组合而更自主的服务 .
我可以看到在协调工作流中调用微服务来进行一些简单的处理,但我没有看到微服务是协调器服务,它通常使用诸如补偿事务和状态存储库(脱水)之类的机制 .
所以你有两个服务:
发票微服务
装运微服务
在现实生活中,你会有一些你持有订单状态的东西 . 我们称之为订单服务 . 接下来,您有订单处理用例,它知道当订单从一种状态转换到另一种状态时该怎么做 . 所有这些服务都包含一组特定的数据,现在你需要其他的东西来完成所有的协调 . 这可能是:
了解所有服务并实现用例的简单GUI("I'm done"调用货件服务)
业务流程引擎,等待"I'm done"事件 . 该引擎实现了用例和流程 .
一个编排微服务,假设订单处理服务本身知道你域名的流量/用例
我还没有想到的任何其他事情
对此的要点是控制是外部的 . 这是因为所有应用程序组件都是单独的构建块,松散耦合 . 如果您的用例发生更改,则必须在一个位置更改一个组件,即业务流程组件 . 如果你添加不同的订单流,您可以轻松添加另一个不干扰第一个的协调器 . 微服务思维不仅涉及可扩展性和花哨的REST API,还涉及清晰的结构,减少组件之间的依赖关系以及重用整个企业共享的通用数据和功能 .
HTH,马克
如果需要管理 State ,那么使用CQRS的事件采购是理想的通信方式 . 此外,异步消息系统(AMQP)可用于微服务间通信 .
从您的问题来看,显然具有CQRS的ES应该是正确的组合 . 如果使用java,请查看Axon框架 . 或者使用Kafka或RabbitMQ构建自定义解决方案 .
原始问题的答案是SAGA模式 .
我在这个主题上写了几篇文章:
也许这些帖子也可以帮助:
API网关模式 - 课程粒度api与细粒度api
https://www.linkedin.com/pulse/api-gateway-pattern-ronen-hamias/ https://www.linkedin.com/pulse/successfulapi-ronen-hamias/
粗粒度与细粒度服务API