需求调研概述

最近在外调研，重点还是想谈下企业对业务系统间的集成需求和ESB平台本身的能力需要方面的一些思考和记录，传统我们谈最多的还是ESB服务总线覆盖了数据集成，业务集成和流程集成完整集成场景，同时提供了相应的适配，协议转换，文件传输等方面的能力。

对于多年实施ESB下来，最大的一个感受还是ESB服务总线首先要解决的仍然是业务系统间的集成问题，其次才是解决服务复用，共享和能力开放层面的问题。

这两者在技术实现上有一个最大的区别体现在，谈集成的时候往往数据落地，也不一定需要实时；而谈服务和能力开放的时候则往往是数据不落地，实时发起调用。因此谈集成的时候往往仍然无法很好地解决数据多点落地后在同一时点不一致的问题，而谈到数据不落地场景则会造成业务系统传统开发方法巨大变化，在前面PaaS平台的组件化开发架构中我已经多次提到，在这里就不再重复。

ESB服务总线提供统一的服务目录库，统一的服务接入，服务订购，服务鉴权和服务运行监控能力。其中一个核心就是服务运行监控，运行日志和异常分析，告警和预警等。这是ESB平台的一个关键需求，就是在接口服务运行出现问题的时候能够快速地定位和诊断，而不是由于接入了ESB总线导致问题分析定位更加困难。这是ESB平台服务治理管控中一个最基本的需求。

大家都知道，ESB服务总线最适合的仍然是处理大并发，小数据量的业务服务实时调用，而对于大数据量的类似数据集成和传输类服务调用往往性能就下降明显。对于大数据集成本身也不是ESB总线的强项，正是由于这个原因类似Oracle等产品推出了ODI解决方法，将WS和传统ETL进一步集成，实现大数据传输流和消息控制流的分离，很好的解决了这个问题。如果不使用这种方式，可以借鉴使用的只有类似分页，缓存，二进制流传输等方面来解决大数据传输的问题。当然对于BI类数据集成和数据采集，则完全没有必要走ESB服务总线来处理，单纯的ESB服务总线往往并不具备传统数据交换平台的能力。

微服务架构下涉及到微服务网关，当然对于重型的ESB产品你也可以当做微服务网关的来用，类似Oracle SOA套件也专门有一个API Gateway的模块来实现Rest接口的接入和发布。对于Rest接口比SOAP接口更加轻量化，但是当前最大的问题仍然还是在接口契约本身的严谨性和后续的管理上，实际上在企业信息化建设中，如果涉及到众多建设厂商间的沟通协同，采用Rest接口往往并不是一个好的选择。

对于整个ESB服务总线，要实现所有的集成场景，考虑下整体规划架构仍然和我多年前的思考仍然是一致的，即ESB服务总线要管理整个的服务目录，但是底层本身又包括了大数据传输组件，大文件传输组件，消息集成组件，而这些组件最终都又以服务集成的方式集成到了ESB服务总线上面。对于ESB服务总线本身则更多地承载实时业务服务的集成和服务暴露。

集成需求总结

下面对近期调研和访谈的企业对ESB总线和集成平台需求的一个初步整理。实际上对于ESB服务总线究竟解决了企业哪些问题，我在前面很多文章都有过系统性的专门描述，因此这篇为零散需求记录。

在跨系统交互和集成上，企业最大的问题是数据问题，即数据不一致和数据延迟导致的跨系统业务协同上出现问题。因此大部分企业会思考对基础数据进行统一管理并提供统一能力，即我们常说的主数据管理，主数据管理可以明确地解决业务系统和问题，也容易和业务部门和业务人员沟通为何要上MDM，而对于MDM实施本身涉及到集成，即还需要同时进行接口服务的统一管理。

当前还是大部分企业会思考对于MDM和ESB统一进行建设，如上图可以看到MDM+ESB作为整个应用集成架构规划的双核心。那么两者究竟是什么关系？

对于主数据平台来说，本身是可以独立建设的，即使没有集成平台也可以单独建主数据。而对于SOA集成平台，不仅仅是解决主数据相关接口集成问题，而是解决整个信息化应用系统间接口交互和集成

主数据平台的建设，难点不在于系统，而是在于主数据系统的实施，而实施本身的难点本身又在于历史数据的清理和初始化入库。这个本身需要业务部门，包括相关的业务系统高度配合才可能完成。

当前对于企业集成的需求，即使我们使用的是ESB服务总线，但是仍然可以看到集成的需求包括了服务集成和数据集成两个部分，或者把ESB总线当做数据总线来用，或者在集成平台项目中会包括类似ETL的数据集成能力。大部分的企业集成，在第一阶段仍然是解决数据集成问题，而不是服务集成和应用集成。

数据集成在前面很多文章讲过，数据集成表示数据会在多个业务系统多点落地，这样本身可以降低业务系统之间的耦合性，但是带来的问题是数据会存在不一致性和时延，那么这些问题就必须有很好的管控机制和补偿机制去处理，否则即使系统间集成了照样影响到业务协同。

• 数据集成：通过接口服务或ETL进行传输传输集成，数据会在多个业务系统落地
• 服务集成：在业务场景需要协同的情况下，实时调用服务接口进行数据获取，数据不落地

服务集成的实时性最高，当然对业务系统，集成平台本身的可靠性，性能要求也更高，本身接口服务的调用并发量也会指数级增长。因此并不是服务集成就一定比数据集成好，而是应该实际问题实际分析。

当我们采用数据集成的时候，仍然存在两种场景，即定时地进行数据同步，还有一种就是实时的调用接口服务进行数据导入，那么在我们实施的时候更加建议采用第二种折中方式。即既保证了数据同步的实时性，本身又降低了后续业务之间的耦合程度。

在交流的一些企业里面，我们经常也会听到说原来已经实施过ESB总线或类似的集成平台，但是实施效果并不好，而这个实施效果不好注意体现在以下几个方面。

1. 业务价值无法显性化：ESB属于技术平台，导致ESB总线的业务价值很难显性化，IT部门可能认可平台重要性，但是企业业务部门往往对平台并没有直观的认识。而没有业务驱动力的平台建设本身又是难事。

2. 管控治理没有跟上：对于ESB服务总线究竟是简单的买产品还是卖实施在我博客上也讨论过多次，从乙方角度肯定是希望卖产品最简单，但是单纯的卖产品，整个SOA实施方法论，SOA治理管控规范体系无法真正在企业落地。往往是乙方实施商一离场，甲方接口服务又恢复原样，导致仍然出现接口管理混乱的情况。这个原因不是在于ESB总线产品问题，更多的还是实施管控治理方面的问题。

3. 技术平台功能单一：前面已经讲过了企业的集成需求很多，有接口服务实时集成，也有数据集成，文件集成，ETL数据传输，还包括MDM主数据平台的建设。一涉及到集成需求企业往往就认为都是ESB总线能够解决的问题，但是实际上ESB总线很难解决上面所有问题，而是应该一个完整的整体解决方案才能够解决。因此对于这点我们在做SOA项目实施的时候也需要和企业提前沟通清楚。

ESB总线平台的建设，一个方面是选择产品，但是更加重要的还是服务实施，服务管控治理规范流程的建立，而对于这方面远行科技本身经过10多年的大平台和大项目现场实施，我们在这方面也是积累了丰富的现场实施和管控经验，而这些才是确保SOA实施项目能够成功的关键。

不同集成场景下的需求应对

今天谈下企业内应用系统间的集成需求，虽然我们前面谈了很多的企业中台建设，微服务架构，基于DevOps的面向云原生的持续集成和持续交付解决方案，但是我们还是要看到，对于任何一个企业这个转型过程都不可能一蹴而就，而是一个长期逐步演进的过程。那么对于这些已经存在的遗留系统和遗留架构，我们还是得支持各种场景的集成场景和集成需求。

首先看下对于企业内部系统间已经通过Web Service来实现的接口集成，不论是SOAP的WS服务接口，还是基于Http Rest Web Service服务接口，这些都是当前主流的服务集成和服务发布方法。

也是我们常说的采用ESB服务总线或API网关进行的服务集成和服务能力开放。要注意对于ESB服务总线往往会同时具备了对Http Rest接口服务的适配和集成能力，但是当前的API网关产品就很少再去兼容SOAP WS服务的。

对于才有ESB服务总线进行服务集成的时候，我们前面已经讲过很多次，服务总线的优点在于大并发，小报文，低时长的服务访问和调用，对于这种情况往往可以达到很高的TPS性能值和服务访问吞吐量。而ESB服务总线最怕的就是长耗时长连接，大报文大数据量的服务调用。

长耗时+大报文都会导致我们在服务请求和解析报文，进行序列化和反序列化的时候大量内存消耗。为了应对这个问题，可以看到我们有时候会采用一些分页，数据报文压缩等方式来提升性能，但是如果涉及到很大数据量的底层数据库表间数据同步，即使我们做了上述处理仍然会造成很大的消耗。

因此对于这些大数据量集成还需要引入其它集成方式或工具。

大数据集成工具

即对于ESB服务总线来说本身就不太适用于应用系统间底层数据库表间的大数据集成操作。这个更多的还是得通过ETL工具来解决，但是ETL工具如何和我们的WS服务做集成和协同，类似Oralce就给给出了ODI的解决方案来解决这个问题。

即ODI = Web Serice + ELT数据集成

这个方案的特点就是数据请求和数据调度任务的发起不再是传统ETL的定时方式，而是通过调用Web Service服务发起，而且在发起的时候这个服务本身还能够输入具体的参数信息，更加方便灵活。但是具体数据的传递仍然是走传统的ETL方式进行，减少了对这部分报文在ESB管道上传输带来的性能压力。

大文件集成工具

还有一个场景就是企业内的文件传输和文件集成，这个也需要分场景，具体来说如果仅仅是一个业务服务比如合同信息上传服务涉及到的文件附件传输，而且这个文件传输我们希望做到实时触发传输，那么我们可以使用类似ESB服务总线的FTP文件适配器来解决这个问题。

但是如果我们面对的是大量文件的批处理和端到端传输，那么通过ESB总线就很难去解决这个问题，特别是对于文件传输过程的端到端管理和监控能力，ESB总线更加难以达到。

而面对这个场景，对于当前的Oracle SOA套件体系给出的解决方案是MFT文件传输平台，通过这个平台来实现文件的端到端传输和管理，而且支持文件传输安全，加密，文件压缩，断点续传等能力。

消息中间件能力

对于任何ESB总线，我们可以看到天生就自带了强大的消息中间件能力，类似IBM的MB总线自带MQ能力，Oracle的OSB总线自带Weblogic JMS能力，Tibico的ESB总线自带EMS消息中间件能力等。其核心原因就在于对于ESB服务总线本身既需要支持服务的同步集成和实时调用，也需要支持类似消息模式的异步集成能力。

我们可以看下对于当前的API网关产品，实际上已经没有这部分的能力。所以API网关产品往往并不能解决消息集成和消费发布订阅。那么你在搭建新的技术平台的时候，如果你选择了API网关，往往还需要选择另外一个开源的消息中间件来解决消息集成场景。

对于消息集成一方面是异步集成能力，更加重要的就是我们常说的消息1对多，消息的发布订阅场景。这个功能大大的简化了我们集成的复杂性，原来的多点集成转变为了基于消息中间件的多点分发，而对于源端系统来说只需要将数据分发到消息中间件即可，具体的朝目标端的分发和重试机制完全由消息中间件自己来完成。

面向云端和云环境的服务集成能力

这个即是我们经常谈到能力开放平台或OpenAPI开放平台，或需要和公有云的对接平台。实际上你可以看到当前和各个公有云，外部的相关SaaS应用对接基本都是类似OpenAPI平台和基于Http接口的对接方式。因此你的集成平台只需要支持这种方式的对接，支持对基于Http Rest集成方式下的安全管理和监控能力即可。

同时在和外部对接的时候需要考虑在企业的DMZ区单独部署一套ESB总线，如果外部对接的场景足够简单，比如全部都是Http Rest服务接口，那么我们也完全可以在DMZ区部署一套API网关产品即可。如果对于API网关你都觉得复杂，最简单的方式还可以部署一套Nginx服务来做代理路由。

因此对于云端的集成大家不要觉得复杂，基本能力仍然是我们常说的ESB总线或API网关的能力，只是在我们进行云端集成的时候，需要在安全性设计和实现上花更多的功夫。

远行的CSB云服务总线解决方案

前面谈了企业内的各种集成需求和集成场景，可以看到包括了服务集成，大数据集成，大文件集成，消息集成等多种场景，而这些在远行当前CSB服务总线产品中可以全部提供，也就是一个产品可以提供上面所有的能力，而且大数据传输，大文件传输本身又和服务做了集成和协同，全面覆盖了企业内的集成场景和需求。同时还有一个关键点就是远行的CSB服务总线产品完全覆盖当前主流的API网关产品提供的全部功能和能力，可以对HttpRest服务接口的服务注册接入，设计，安全，流控，运行监控的全生命周期管理。

对于存在大量遗留系统需要集成，逐步进行IT架构转型的企业，远行服务总线能够提供的这种一揽子的解决方案往往更加具备优势和价值。

企业集成的发展的三个阶段

做了多年的SOA项目咨询和实施，可以看到企业内部业务系统间的集成主要还是三个阶段，具体描述如下：

第一阶段：完全的点对点集成

业务系统之间完成通过点到点的方式进行集成，形成蜘蛛网式的集成架构。在这个阶段本身又存在几个发展过程，最初级的时候就是接口完全不标准，各种实现技术，各种规格定义都存在，同时对于安全，日志等管控也很弱，导致最多的问题就是后续问题排查很麻烦。

再好点就是定义了接口标准，比如全部走标准的WS服务接口进行集成，或者根据不同的场景定义了2到3种可选的集成方式。在这种情况下接口本身做到标准化和规范化，但是存在的主要问题还是接口本身的管控和治理，即没有一个统一的管控和治理中心，能够实现对企业内部所有的接口统一的接入，开通，授权，日志监控，问题排查等统一的监控和管控。

点对点集成下，接口很难复用，完全是有一个接口需求就做一个接口，造成大量重复开发和联调工作量。 同时点对点集成商，本身技术也导致难以复用，比如一个JMS消息集成，一个大文件传输集成等，往往都需要各个业务系统去准备实现相同的技术组件。这块本身也是无谓的工作量增加和技术投入。

第二阶段：类似接口平台或集成平台

发展到第二阶段，当前说的比较多的就是接口平台或集成平台。在这个阶段一个最大的转变就是原来的点对点集成模式转变为了基于接口平台的总线Hub式集成模式。所有的业务系统间接口都不直接交互，而是都直接注册和接入到集成平台，然后再有集成平台发布一个统一的接口服务地址供外部业务系统调用。

一个集成平台基本会支撑传统消息，数据，文件，WS服务等各种模式的集成能力。

集成平台的建设和实施一般就会进一步地约定接口技术标准和规范，约定接口开发标准，接口服务的接入标准和消费标准，同时对于注册接入的接口在安全，日志，异常监控，路由，消息发布订阅等多方面给予更强的能力支撑。这些都在统一的集成平台完成，真正提升了SOA治理和管控能力。

在集成平台阶段往往又分两种场景，一种是传统的数据交换平台，重点是数据交换，所有数据全部落地；一种是服务共享平台，提倡的是服务接口实时消费和使用，数据尽量不落地。当前更多的是服务共享平台模式，但是同时存在接口服务数据落地和不落地两种消费场景。

第三阶段：能力开放和OpenAPI平台

能力开放和OpenAPI平台在互联网谈的比较多，但是这也将是企业内部集成发展的一个必然趋势，不仅仅是企业内部业务系统能力超对外的开放，比如电商，B2B等。其次也是企业内部业务系统间的能力开放。

第二阶段往往是A超B提交接口需求，B系统考虑实现一个接口服务。而真正到了能力开放阶段，更多的是以B系统为主去考虑究竟需要暴露和开放哪些能力出去。这是一个关键顺序的变化。

集成平台阶段可以看到服务的注册接入和服务的消费两个过程往往是高度耦合在一起的，有接口需求B系统才会做接口服务，A系统马上就去消费。而到了OpenAPI平台阶段服务接入和服务消费两个过程是松耦合的，即能力即使在没有消费方的情况下也可以先接入并发布到能力库，而各业务系统随时也可查看服务目录库和服务市场发起服务订购请求和消费。

在OpenAPI平台阶段更加强调了以业务系统为主的能力开放。同时也更加强调了各个业务系统基于OpenAPI平台的自服务流程，即整个过程里面并不需要太多的集成商工作参与，所有需要的标准和规约也都全部固化到了类似服务接入，服务订购，服务开通等自服务流程中。

传统集成平台更多的是SOAP WS，Rest，JMS消息各种方式并存，而到了OpenAPI平台由于是以能力开放和发布为主，基本可以全部统一为轻量的Rest服务接口服务模式。因此在OpenAPI平台的能力开放模式下，底层的集成引擎往往会采用更加轻量的API网关来实现，而不再需要偏重的ESB总线引擎。