服务编排是指把已经开发好的API接口(Restful、WebService、Dubbo、gRPC…)按照一定的业务逻辑和流程进行可视化编排复用的过程，服务编排平台会在内部构建一个流程调度引擎进行自动化的调度或者重新聚合为一个新的API能力进行发布。

通过服务编排可以把企业的业务能力API无需任何代码就可以进行业务逻辑的重组，可以提升API服务的复用率实现前台业务或业务系统的的敏捷交付，通过服务编排平台也能把业务系统、数据、业务逻辑进行解藕，业务逻辑的编排交由专门的服务编排平台完成，而API服务只需要专注完成自已内部的逻辑即可。

备注：服务编排不是与Docker容器的编排,Kubernetes编排的是Docker容器而Docker容器中不一定运行微服务API, Kubernetes不是针对(Retful,WebService)等接口的编排，而微服务编排平台是针对具体发布的每个API进行编排

试想一下在没有服务编排平台的情况下我们要完成一个这样的业务逻辑怎么样才能实现?

我们有一个查询商品价格变化的服务A，有一个VIP会员接收商品变化通知的服务B，有一个VIP会员执行中订单价格变更服务C，我们需要在商品价格发生变化时立即自动通知VIP会员服务B和订单变更服务C两个API服务，而且要保证送达(不能出现B成功C失败或者B失败C成功的情况)。

目前开源的服务编排平台主要有Netflix Conductor服务编排平台，但是存在没有中文界面、不支持可视化编排、UI不够友好等等问题，如果用作企业级的服务编排平台还存在相当大的差距。

RestCloud作为最早在国内做自主研发的微服务框架的团队，自然是看到了这种问题的存在，可以说在国内第一时间就开始研发这个服务编排平台了，目的是研发一个完全国产化的简单易用的服务编排平台，通过可视化的拖、拉、拽就可以完成一堆各种协议API的编排。

这个可以说是我们经常被问到的问题，因为现在像IBM和Oracle等的ESB产品也支持Restful API的调用与编排，也可以通过图形化的方式进行拖拽然后进行服务逻辑重组，但是仔细来看这两种平台有相似性也有很大的差异，我们体现在以下一些方面。

1. 首先服务编排平台本身一定要是基于微服务架构开发的且前后端分离的系统，可以分布式部署可以完全融入到企业已有的微服务架构中，编排的后的API服务可以立即部署到微服务架构中并与网关、注册中心、DevOps进行打通，而传统的ESB不行，传统的ESB都是基于SOA架构为基础的CS结构或B/S的单体系统基本上与微服务没有什么关系，其内部组件高度耦合，服务编排平台可以做到真正的敏捷集成和快速发布。

2. 服务编排平台本身的所有能力又可以作为API服务对外进行能力输出，而传统的ESB却很难做的到其能力只能有限对外发布。

3. 服务编排平台一般追求更高的流程执行和调度性能所以更注重轻量级，易用等特点，而传统的ESB由于架构复杂性能往往存在瓶颈，同时显得非常笨重使用起来普遍感觉很难入门。

4. 服务编排平台更注重API服务的编排特别是微服务的API如(Restful，WebService，Dubbo，gRPC等)，而传统ESB往往会引入一大堆与微服务没有关系的功能如：FTP、SMTP、MQTT、JDBC、EXCEL、数据库链接、大文件传送等，甚至把ETL的部分功能混杂进了ESB中。

5. 服务编排平台更注重编排后服务的事务性控制能力，往往会提供最终一致性事务控制能力，断点续跑能力、故障转移等功能，同时讲究数据在运行过程中的可恢复性，而ESB在这方面显然是比较弱的。

6. 服务编排平台一般作为企业所有开发人员、子公司、第三方开发商或者最终业务人员的统一服务编排平台，而传统ESB往往是给那些企业里面的专业集成人员所使用的，因为ESB使用复杂而且有些是基于C/S架构的没有提供一个集成门户给第三方开发商或子公司的开发人员去编排。

7. 传统ESB软件往往功能做的非常复杂会把一些算法、逻辑进行混排，所以使用难度不少，而服务编排平台会把大部分逻辑放入到API中。

8. 同时传统ESB还把微服务架构中的API网关、API接口管理的能力也进行了混入，所以看看ESB是不是什么都想做（API网关，服务编排、ETL数据交换、API文档管理、文件传送），而在微服务架构中一般API网关是独立的模块， API网关就是一个独立的模块只负责数据的路由和透传追求的是性能，而服务编排平台则专门负责服务的编排追求的是快速的编排，而ETL则专门负责数据的清洗、转换和加载追求的是大批量的数据传送和清洗能力。

9. 我们有时也认为服务编排平台是一个轻量级只注重服务编排的ESB中间件产品，因为服务编排平台也与ESB产品一样具有中心化节点的架构，构建的同样是企业的服务总线。

10.传统ESB产品和服务编排平台侧重点不一样，如果企业对于文件传送、其他协议的转换没有什么特别要求可以直接使用微服务编排平台+API网关来构建企业服务总线，只需要把相关协议统一到Restful接口规范即可(把FTP功能发布为API，邮件发送发布为API等)，如果企业已经购买了ESB产品的情况下可以采取共存的方案。

其实不然在企业里面这种中心化架构是必然存在的，微服务架构中的去中心化主要是在微服务模块之间的相互调用时进行点对点的调用，而业务系统或各业务域之间的相互调用一定要走中心化架构，而在企业里面面临的主要问题是有很多遗留业务系统、业务逻辑非常复杂、业务逻辑多变(在企业里面解决复杂业务问题是核心诉求)，所以不是我们上了微服务架构就不能有中心化平台出现了，像Netflix也是互联网公司但是发现没有Conductor微服务编排平台发现很多业务问题解决起来超出可控范围，所以不得以研发了Conductor编排平台，企业不能为了微服务而微服务，在企业IT架构中不要进行过度的架构设计，只有能解决业务问题才是核心。

我们在做架构设计时就考虑到平台必须本身必须是一个基于微服务架构的平台，例如可以自动接入服务注册与发现中心，采用无状态架构设计水平扩展，支持Docker容器化部署，前后端分离B/S架构等基础原则。

考虑到编排平台可能会有大量的编排流程在同时运行(可能同时超过几千个)，而且被编排的API服务可能存在不稳定性等情况出现，所以作为流程调度器我们重点实现了故障自动转移、继点续跑等重要能力。

在API调用失败时用户有时是需要全流程重跑一次，有时又希望只跑某几个重要节点，这就需要编排平台能够很好的进行灵活定义并在合适的节点进行数据的恢复，而且重跑时也有可能再次失败，失败后还要引入手工干与流程运行的能力。

在编排节点上我们支持常用的API节点进行编排目前主要支持：Restful、WebService、Dubbo、kafka、、MQ、脚本、微信、钉钉等节点的编排，目前主要考虑的是在微服务的协议的上的节点，后继扩展节点则根据用户的诉求进行扩充即可。

在流程设计上我们遵循BPMN2.0规范，这样有利于原来就熟悉工作流的人员可以快速的进行API服务的编排与设计

在编排流程的监控上我们实现了完全可视化的流程回放能力，可视化的数据追朔能力，API调用实时监控能力，同时可以统计编排流程的平均性能、运行次数、失败次数等等功能。

其实通过服务编排平台可以实现非常复杂的业务需求，按照企业中台架构的的实施进度，如果企业的业务能力全部以API的形式对外开放时，服务编排平台将具有实现企业业务能力快速重组的功能，即通过拖、拉、拽就可以实现一个新的业务创新点然后对外提供服务，编排平台将处于所有中台(数据中台、业务中台、技术中台)之上的一种高级的能力重组中心，同时通过编排平台还可以实现企业私有化业务系统与云端SaaS系统、数据中心进行打通，可以说在API的世界里编排平台就是上帝之手，他可以通过编排组合新的API基因创造新的物种。