Why service collaboration needs choreography AND orchestration
转自:https://blog.bernd-ruecker.com/why-service-collaboration-needs-choreography-and-orchestration-239c4f9700fa
Let’s assume you want to build a simple order system covering the whole order fulfillment process with the following three microservices involved (you might name it services, components or aggregates if you prefer):
- Payment
- Inventory
- Shipping
The overall order fulfillment definitely requires these three services to collaborate. Currently there is a big fight going on as to which collaboration style to use — orchestration or choreography (for an introduction on the basic styles see Orchestration or Choreography). But is this an either or decision?
I strongly believe that in most real-life scenarios you need a clever mix of both collaboration styles so let’s go over that.
Choreography
Assume that we want to use event-based choreography as much as possible. This is in sync with the typical recommendation among microservice publications, e.g. “Building Microservices” from Sam Newman:
In general, I have found that systems that tend more toward the choreographed approach are more loosely coupled, and are more flexible and amenable to change […].
[…], asynchronous event collaboration helps us adopt a choreographed approach which can yield significantly more decoupled services — something we want to strive for to ensure our services are independently releasable.
And I agree that this make sense on a large scale. Doing so results in the following event flow for our order application:
So far so good, no component is talking directly to each other and only events are used to communicate. Very de-coupled — isn’t it?
No.
Event command transformation
The problem is that the payment service has to react to the order placed event. It has to know its consumer! As soon as other services need payment, it has to be adjusted. This is exactly what we don’t want, at least in the case of the payment.
Another example: You want to implement the new business requirement that VIP customers can pay later by invoice. Now you have to change multiple components: The paymentneeds to know only to execute payments for non VIP customers. The inventory has to know that it reacts also on order placed but only for VIP customers. So you already had to tell two services about your VIP customer even though they should never know about it.
That’s why an additional component that decides that you have to do payment whenever an order was created improves de-coupling of the payment service from its concrete consumer. My friend Martin Schimak an I call that event command transformation:
Event command transformation pattern
In our example this might be done by an order service.
Orchestration
As soon as you issue commands, you’ve taken the first step towards orchestration as the transformer automatically is some kind of conductor commanding another component. However, the command is still a message and can be sent over the normal bus. So I see good reasons to still summarize that as choreography without remorse. As wording is very important in the current discussions I think this helps to remove misconceptions that orchestration has to be avoided at any price; as you can see that the event command transformation is actually essential to build a nicely de-coupled event-based system!
State Handling
We have a second challenge. The payment might take quite long to complete. Assume we want a call center to call the customer to clear problems during payment. That might take days to weeks. So now you get a long running flowin your order service and you have to track the state. And you might face timing requirements, for example the pricing in the order might only be fixed for 7 days so you want to take action if the order is delayed too long.
I have described basic implementation approaches in How to implement long running flows, sagas, business processes or similar. A typical approach is to use a state machine to do this. This finally means you are using an orchestrated style of collaboration within your order service. It is important to notice the small word within here.
“Overall choregraphy and local orchestration”
This yields the following approach:
- Orchestration takes place locally in the order service. It is an implementation decision of that service to use a (local) brain to coordinate the flow it has to implement. There is no central conductor steering different services, no central spider in a giant spiderweb. That’s the typical misconception with orchestration engines. But there is a proper event command transformation so that the order service can command the payment service in order to improve de-coupling.
- The end-to-end business process of ordering goods can be implemented as overall choreography. Only messages (events and commands) are sent over the wire, there is no central conductor controlling everything.
This brings the best of both worlds: Handling state and mastering control over the flow happens in a context you can easily control — one service. Choreography is used on the larger scale of collaboration of various services to improve flexibility.
Conclusion
For real-life use cases services need to collaborate. You need both: A choreographed event-based style as well as an orchestrated command-based style depending on the situation at hand. With a clever mix you reach the level of de-coupling you aim for especially when using microservices.
If you are interested in concrete code examples for the concepts discussed, there is the flowing retail sample application showing all these aspects in action.
Why service collaboration needs choreography AND orchestration的更多相关文章
- RocketMQ 4.3正式发布,支持分布式事务
冯嘉 作者 | 冯嘉 近日,Apache RocketMQ 4.3 版本宣布发布,此次发布不仅包括提升性能,减少内存使用等原有特性增强,还修复了部分社区提出的若干问题,更重要的是该版本开源了社 ...
- Apache RocketMQ 正式开源分布式事务消息
近日,Apache RocketMQ 社区正式发布4.3版本.此次发布不仅包括提升性能,减少内存使用等原有特性增强,还修复了部分社区提出的若干问题,更重要的是该版本开源了社区最为关心的分布式事务消息, ...
- BizTalk开发系列(三十)单向端口实现请求-响应
BizTalk本质上是异步的消息处理引擎.BizTalk的请求与响应模式是基于异步之上的同步消息交换.消息引擎通过消息的扩展架构链接许 多异步消息,消息的相关集关联请求与响应消息.例如,客户端发送一个 ...
- Docker Resources
Menu Main Resources Books Websites Documents Archives Community Blogs Personal Blogs Videos Related ...
- OpenStack及其构成简介
新的一年新的开始,突然想学习下Openstack,之前了解过很多,但是想系统的学习一下,第一次写博客,只想把学到的东西记录下来加深印象,如有写的不好的地方请多多见谅.下面开门见山. 1.What is ...
- centos7部署openstack-ocata
1.前言 本文旨在记录本人的一个实验过程,因为其中有一些坑,方便以后回顾查询. 其中限于篇幅(大部分是配置部分)有些内容省略掉了,官网都有,各位如果是安装部署的话可以参考官网,不建议使用本文. 以下是 ...
- The Microservices Workflow Automation Cheat Sheet
Written by Bernd Rücker on Dec 12 2018 in the Best Practices category. Editor’s Note: This post orig ...
- CentOS7.4安装部署openstack [Liberty版] (二)
继上一篇博客CentOS7.4安装部署openstack [Liberty版] (一),本篇继续讲述后续部分的内容 一.添加块设备存储服务 1.服务简述: OpenStack块存储服务为实例提供块存储 ...
- OpenStack的基本概念与架构图
https://blog.csdn.net/zjluobing/article/details/51489325 OpenStack项目是一个开源的云计算平台,旨在实现很简单,大规模可伸缩,功能丰富. ...
随机推荐
- xshell无法在小键盘输入数字
自从很久之前用小键盘输入数字后出现奇怪的字母并换行后就不用小键盘,今天脑抽又用小键盘写数字,并决定解决问题. 原因分析: 当xshell终端类型不是"VT220"或者"A ...
- SQL-28 查找描述信息中包括robot的电影对应的分类名称以及电影数目,而且还需要该分类对应电影数量>=5部
题目描述 film表 字段 说明 film_id 电影id title 电影名称 description 电影描述信息 CREATE TABLE IF NOT EXISTS film ( film_i ...
- 参数优化-API
网格搜索 对给定参数进行组合,用某标准进行评价,只适合小数据集 class sklearn.model_selection.GridSearchCV(estimator, param_grid, sc ...
- Linux文件系统命令 ls
名称:ls 功能:查看文件列表 renjg@renjg-HP-Compaq-Pro--MT:~$ ls add-on.yaml Desktop examples.desktop meta-gnome3 ...
- 代码改变世界 | 如何封装一个简单的 Koa
下面给大家带来:封装一个简单的 Koa Koa 是基于 Node.js 平台的下一代 web 开发框架 Koa 是一个新的 web 框架,可以快速而愉快地编写服务端应用程序,本文将跟大家一起学习:封装 ...
- shell脚本实例-case 删除用户判断的小案例
#!/usr/bin/bash read -p "Please input a username:" user id $user &>/dev/null if [ $ ...
- ES脑裂问题
脑裂:一个集群中的不同节点对于集群的状态有了不一样的理解 ES集群的总体状态是red,本来9个节点的集群在结果中只显示4个节点在线: 正常情况下,集群中的所有节点应该对集群中的master的选择是一致 ...
- webgl,threejs教程、笔记
发现一个不错的博客,学学. webgl和threejs教程
- [LeetCode&Python] Problem 21. Merge Two Sorted Lists
Merge two sorted linked lists and return it as a new list. The new list should be made by splicing t ...
- Unity射线检测的用法总结
RayCast 射线检测 本文提供全流程,中文翻译. Chinar 坚持将简单的生活方式,带给世人!(拥有更好的阅读体验 -- 高分辨率用户请根据需求调整网页缩放比例) Chinar -- 心分享.心 ...