在传统单体项目微服务改造后，原完整的业务流程的功能会根据领域划分在各个微服务中，如商户管理服务、商品管理服务、支付服务、额度服务等。这样如果要对外提供下单能力，会涉及协调各个微服务的能力，组合一个标准的业务流程。协调会涉及编排和编制。
编排和编制
- 编制：由一个协同服务串联各个微服务。如MVC框架的Controller层，DDD经典四层架构的应用层，都属于编制。ESB、API网关一般也有部分编排能力，做服务组合。
- 编排：每个微服务完成自己服务部分的业务逻辑，没有统一的协调层。
所以我们讲的服务编排一般指服务编制。
图形化编排
在大公司里，业务场景多，流程复杂度高，在项目后期，如果人员流动高，文档也未做到及时更新。随着业务发展，用代码方式做编制大部分开发 人员不了解整体的业务流程，了解真正的业务知识需要扒代码，或者去问某几个“开发大佬”。
基于这样的问题，有些公司会选择图形化编排。新的开发人员、产品经理可以很清晰的看到某业务的完整流程。
低代码
提到图形化编排，其实就是低代码开发平台，但对于复杂的业务流程目前基本没有零代码开发。
工作流引擎
关于图形化编排，传统基于BPMN2.0的工作流引擎，个人认为是很适合做服务编排的。 但传统的工作流完全基于数据库，存在性能瓶颈。一些基于消息驱动的编排框架如zeebe入门门槛较高。具体选择还要看具体的业务场景。
