可视化微服务(API)编排平台，全面替换ESB时代到来

发布时间: 2020-10-23

1.什么是微服务(API)编排？

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

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

       注意：这里说的微服务编排不要与Docker容器的编排搞混淆了,Kubernetes编排的是Docker容器而Docker容器中不一定运行微服务API, Kubernetes不是针对(Retful,WebService)等接口的编排，而微服务编排平台是针对具体发布的每个API进行编排。

(多个微服务API进行流程编排)

(编排过程中可对API的数据及格式进行转换)

2.为什么需要微服务编排平台？

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

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

（通过API进行消息推送）

       作为开发工程师第一时间肯定是编写Java代码，先定时不断的轮询A服务，当有数据变化时编写代码调用B，C两个服务，看起来其实非常简单也就百十来行代码就可以搞定，其实不然。

       细思其实很复杂：

       (1)开发工程师必须要考虑B,C服务的最终一致性事务问题

       (2)要考虑每次调用A服务需要时传入上一次查询的时间戳问题

       (3)要考虑有一天客服的人说接收到的价格数据有误需要你进行反向追查，需要你还原整个数据传送过程

       (4)要考虑B,C服务的幂等性问题

       (5)要考虑B,C服务可能是旧系统发布的WebService接口或者是RPC接口

       (6)要考虑有一天用户说我还有几个服务D,E…也要接收通知，一会儿又说不要了

       工程师会面临频繁修改这个业务逻辑的问题，要不断的发包测试联调等，可想一旦这种需求和逻辑多起来后，错综复杂的API之间的关系将很难追查一个API出现问题时到底会影响多少业务系统或其他API服务。

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

(不断发生变化的服务逻辑重组)

3.目前有那些专门的微服务编排平台？

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

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

4.微服务编排平台与ESB有什么区别?

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

       (1)首先微服务编排平台本身一定要是基于微服务架构开发的且前后端分离的系统，可以分布式部署可以完全融入到企业已有的微服务架构中，编排后的微服务可以立即发布到网关或注册中心或基于Docker容器进行部署，而传统的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产品的情况下可以采取共存的方案。

5.微服务架构中讲究的是点对点的去中心化架构，这种中心化的总线编排平台是不是与微服务架构背道而驰了？

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

(通过中心化的编排平台可以把各种中台的API接口进行统一编排)

6.RestClud在研发微服务编排时实践了那些功能？

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

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

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

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

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

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

(分布式的编排流程调用引擎和执行引擎)

7.通过服务编排平台企业可以做什么？

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

(混合云架构下的服务编排场景)

       传统ESB已经很难胜任这种混合云架构的集成与快速打通，而微服务编排平台将随着微服务架构以及中台和混合云架构的流行将成为企业不可缺少的企业中间件产品。

本文内容转载自：blog.csdn.net

原文作者：苛子

原文地址：https://blog.csdn.net/kezi/article/details/107861681?utm_medium=distribute.pc_relevant_download.none-task-blog-searchfrombaidu-8.nonecase&depth_1-utm_source=distribute.pc_relevant_download.none-task-blog-searchfrombaidu-8.nonecas

作者: 苛子