1. 松散耦合服务互联系统

企业随着前后端分离架构、微服务架构、中台战略、产业互联互通的实施必将产生大量的各种协议的API服务，API将成为企业的数字化资产且API会越来越多， API服务之间的相互调用和依赖情况也随之越来越多和复杂。

业务系统与业务系统之间、关联企业之间的API都相应存在大量的API相互调用和逻辑重组需求、使用传统的编码方式已完全不能满足业务敏捷化交付的特性，可视化服务编排平台通过无代码化来统一编排和调度API服务，通过可视化的拖、拉、拽对API进行编排并实现分布式事务控制、故障自动转移、断点续跑等功能可大幅提升API服务的敏捷化交付能力。

1.1. 单体

todo

1.2. EAI-企业信息集成

一开始软件都是独立应用，不同软件之间没有联系（大约80年代），后来企业应用需要资源整合和共享，出现EAI。一般有两种模式：总线型和辐射型。后来总线型模式发展成ESB。

1.3. ESB-企业服务总线

ESB(Enterprise Service Bus，企业服务总线)指的是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。他的核心功能就是兼容各种协议接口，可以将数据在各种协议之间进行流转，并且可以针对数据格式进行编排转换。

（格式转换、协议转换、代理、编排、安全控制、监控、不支持高并发，类似于路由器维护着一张路由表进行路由转发）

开源的ESB

Apache Camel
Apache Synapse
ServiceMix
JBoss ESB
Mule
Sun OpenESB

ESB一般采用集中式转发请求，适合大量异构系统集成，并且适合压力不大的情况。但集中式转发也是有优势的，比如调用方用http协议，提供方用rmi协议，转发就可以转换协议，对双方都透明。另外，在总线上还可以执行流程引擎，做服务编排，比如A和B两个服务经常一起调，就可以编排成服务C，而不用再单独启一个服务去做。还有，安全，流控，做起来也更方便。

支持groovy类型的脚本语言，在总线上可以给数据格式做转换

esb最常见的场景是，把系统里的集成逻辑，单拉出来，放到esb容器里来部署，并跟应用系统适配。这样让应用系统变得只有自己的业务逻辑，简单、轻薄。

劣势：在所有的服务上增加了一个总线作为沟通的渠道。对于较大的并发量会将瓶颈推到ESB总线上。很多时候ESB总线都采用MQ类的消息服务器来异步处理缓解压力

ESB侧重任务的编排，性能问题可通过异构的方式来进行规避。无法支持特别大的并发

单体架构是面向对象的编程，所有功能是在一个单体服务中

体应用中有一个典型的MVC分层技术，把系统分为数据层、展示层和业务逻辑层，在这种模式下我们比较关注应用自身。而到微服务时期，每个微服务除了数据和业务逻辑之外，往往要依赖下游服务的API，同时自身也会提供API给上游服务，微服务之间相互协作提供整体的系统能力。

面向服务架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

EAI IBM MQ

对于ESB典型的代表就是微软的Biztalk。

适用业务场景 1.作为业务中台、数据中台的API能力复用及融合层支撑前端业务创新 2.作为原子服务与前台应用的中间服务聚合层 3.与API网关一起替换原有企业中比较笨重的单体ESB产品 4.通过API的编排实现多个异构业务系统数据的分发与汇聚 5.通过API的编排打通云上SaaS与私有端业务系统 6.作为企业大量的API服务与服务之间的逻辑重组平台 7.解决系统服务之间相互藕合的问题，服务的逻辑统一到编排层

1.4. 什么是API服务编排？

服务编排是指把已经开发好的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成功的情况)。

多种协议混排能力 RestCloud API服务编排平台支持Restful API、WebService、Dubbo、MQ、Python、Shell等多种类型的服务进行混排并能在多个协议之间自动转换数据格式，Json数据格式可以自动转换到下一API节点的XML格式数据，同时通过Java代码的混排模式可以支持任意业务逻辑与API进行重组和融合，可以解决企业任意复杂的业务流程编排逻辑。

分布式部署架构 RestCloud API服务编排平台是新一代的基于微服务架构的可视化服务编排平台，区别于传统的ESB产品能够实现流程引擎的分布式部署与调度，可以通过Docker容器化编排实现节点的动态加载以应对大并发的流程执行情况。平台本身可以分为流程调度机与流程执行机，通过调度机智能调度流程执行机的流程运行并能在多台服务器之间实现故障的自动转移，通过分布式架构部署方案平台可以应对任何大流量的请求以及数以十万并发流程的同时调度与执行。

而服务编排平台就是专门集中化解决这种服务与服务之间集成，数据格式转换、服务聚合、协议转换、分布式事务控制的平台，通过服务编排平台可以进行可视化的API的编排来降低这些重复没有技术含量的工作、提升服务调用逻辑的可视化、提供数据传输过程的监控和回朔能力、事后进行数据审计的能力，并进一步实现不合规业务数据的自动预警能力(例如：价格突然被调到0元，此时在服务编排平台中可以拦截价格数据并立即发送预警消息，避免企业受到损失)

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

适用大型企业集团多租户支持多租户集中式开发企业各团队、子公司、第三方开发商集中在平台中进行服务编排和管控分布式运行企业各团队、子公司、第三方开发商编排的流程可分布式运行在各自的节点或容器中，出现故障时相互不影响其他节点集中式管控管理员可以集中式监控企业各团队、子公司、第三方开发商编排的流程运行状态，随时洞查可能出现的故障和异常资源可视化调控管理员可以对编排的服务在多个执行引擎中根据资源利用情况随时调配运行节点,在部分节点故障时可立即转移到其他节点

服务编排平台与ESB有什么区别? 这个可以说是我们经常被问到的问题，因为现在像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架构中不要进行过度的架构设计，只有能解决业务问题才是核心。

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

2. 参考

面对的痛点

服务间直接调用，依赖混乱
调用记录无迹可寻
环境与接口规范缺失，维护困难
安全靠白名单各自为战
调用统计与分析无从谈起
无服务治理能力，或各自造轮子 ……

业务互联