可视化微服务编排平台，全面替换ESB时代到来|亚洲bet356体育在线官网

什么是微服务编排？微服务编排是指把已经开发好的微服务API接口(Restful、WebService、Dubbo、gRPC…)根据一定的业务逻辑和流程举行可视化编排的历程，微服务编排平台会在内部构建一个流程调理引擎举行自动化的调理或者重新聚合为一个新的微服务API举行公布。通过微服务编排可以把已经开发好的API服务无需任何代码就可以举行业务逻辑的重组与重构，可以提升API服务的复用效率实现前台业务或业务系统集成的的敏捷交付，通过微服务编排平台也能把业务系统、数据、业务逻辑举行解藕，业务逻辑的编排交由专门的微服务编排平台完成，而API服务只需要专注完成自已内部的逻辑即可。注意：这里说的微服务编排不要与Docker容器的编排搞混淆了,Kubernetes编排的是Docker容器而Docker容器中纷歧定运行微服务API, Kubernetes不是针对(Retful,WebService)等接口的编排，而微服务编排平台是针对详细公布的每个API举行编排。

(多个微服务API举行流程编排)(编排历程中可对API的数据及花样举行转换)为什么需要微服务编排平台？试想一下在没有微服务编排平台的情况下我们要完成一个这样的业务逻辑怎么样才气实现?，我们有一个查询商品价钱变化的服务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元，此时在服务编排平台中可以拦截价钱数据并立刻发送预警消息，制止企业受到损失)。

(不停发生变化的服务逻辑重组)现在有那些专门的微服务编排平台？现在开源的微服务编排平台主要有Netflix Conductor微服务编排平台，可是存在没有中文界面、不支持可视化编排、UI不够友好等等问题，如果用作企业级的服务编排平台还存在相当大的差距。RestCloud作为最早在海内做自主研发的微服务框架的团队，自然是看到了这种问题的存在，可以说在海内第一时间就开始研发这个微服务编排平台了，目的是研发一个完全国产化的简朴易用的微服务编排平台，通过可视化的拖、拉、拽就可以完成一堆种种协议API的编排,固然我们作为商业化公司是不开源的。微服务编排平台与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产物的情况下可以接纳共存的方案。

微服务架构中讲求的是点对点的去中心化架构，这种中心化的总线编排平台是不是与微服务架构南辕北辙了？其实否则在企业内里这种中心化架构是一定存在的，互联网企业大部门会认为微服务架构要去中心化，而其实互联网企业也只是在局部业务领域为了追求性能而实现了去中心化的架构(因为解决性能问题是互联网架构的焦点诉求)，而在企业内里面临的主要问题是有许多遗留业务系统、业务逻辑很是庞大、业务逻辑多变(在企业内里解决庞大业务问题是焦点诉求)，所以不是我们上了微服务架构就不能有中心化平台泛起了，像Netflix也是互联网公司可是发现没有Conductor微服务编排平台发现许多业务问题解决起来超出可控规模，所以不得以研发了Conductor编排平台，企业不能为了微服务而微服务，在企业IT架构中不要举行过分的架构设计，只有能解决业务问题才是焦点。(通过中心化的编排平台可以把种种中台的API接口举行统一编排)RestClud在研发微服务编排时实践了那些功效？我们在做架构设计时就思量到平台必须自己必须是一个基于微服务架构的平台，例如可以自动接入服务注册与发现中心，接纳无状态架构设计水平扩展，支持Docker容器化部署，前后端分散B/S架构等基础原则。思量到编排平台可能会有大量的编排流程在同时运行(可能同时凌驾几千个)，而且被编排的API服务可能存在不稳定性等情况泛起，所以作为流程调理器我们重点实现了故障自动转移、继点续跑等重要能力，。在API挪用失败时用户有时是需要全流程重跑一次，有时又希望只跑某几个重要节点，这就需要编排平台能够很好的举行灵活界说并在合适的节点举行数据的恢复，而且重跑时也有可能再次失败，失败后还要引入手工干与流程运行的能力。

在编排节点上我们支持常用的API节点举行编排现在主要支持：Restful、WebService、Dubbo、kafka、剧本、Rabbitmq、微信、钉钉等节点的编排，现在主要思量的是在微服务的协议的上的节点，后继扩展节点则凭据用户的诉求举行扩充即可。在流程设计上我们遵循BPMN2.0规范，这样有利于原来就熟悉事情流的人员可以快速的举行API服务的编排与设计。

在编排流程的监控上我们实现了完全可视化的流程回放能力，可视化的数据追朔能力，API挪用实时监控能力，同时可以统计编排流程的平均性能、运行次数、失败次数等等功效。(漫衍式的编排流程挪用引擎和执行引擎)通过服务编排平台企业可以做什么？其实通过服务编排平台可以实现很是庞大的业务需求，根据企业中台架构的的实施进度，如果企业的业务能力全部以API的形式对外开放时，服务编排平台将具有实现企业业务能力快速重组的功效，即通过拖、拉、拽就可以实现一个新的业务创新点然后对外提供服务，编排平台将处于所有中台(数据中台、业务中台、技术中台)之上的一种高级的能力重组中心，同时通过编排平台还可以实现企业私有化业务系统与云端SaaS系统、数据中心举行买通，可以说在API的世界里编排平台就是上帝之手，他可以通过编排组合新的API基因缔造新的物种。

(混淆云架构下的服务编排场景)传统ESB已经很难胜任这种混淆云架构的集成与快速买通，而微服务编排平台将随着微服务架构以及中台和混淆云架构的盛行将成为企业不行缺少的企业中间件产物。

本文来源：亚洲bet356体育在线官网-www.ckdsm.com