一个大型集团企业，如果存在集团和省级两级组织架构，包括还存在大量的子公司的情况下，那么一般会存在多套SOA集成平台或ESB服务总线。
那么在这种情况下多套ESB总线之间如何集成和整合。
今天分享一个整合规划方案供大家参考。
企业集成场景和需求分析
大型企业内部随着多年的IT规划和信息化系统建设，集成场景相对来说比较复杂。一般可以根据业务场景和业务交互类型来对集成场景和需求进行分类。
不同的业务交互类型往往需要不同的集成技术来解决。
从上图也可以看到，传统狭义的ESB服务总线往往也仅仅是解决高并发，小数据量访问的流程和业务类集成需求。而不是能够解决所有的集成需求。对于大数据集成，大文件集成等往往还需要根据实时性要求采用不同的集成方法。
包括当前在微服务架构推广实施下，大量接口已经采用标准的Http Rest API接口，接口不再需要复杂的数据映射和协议转换，取而代之的是轻量的API网关进行集成和能力开放。
在服务化大趋势下，整体集成思路仍然是服务+模式，即：
WS服务+ETL实现大数据集成WS服务+MFT实现大文件集成WS服务+JMS实现消息集成
通过服务来发起的大数据和大文件集成，方便解决传统大数据集成只能够通过定时任务调度发起的模式，服务驱动可以按需实时调用，同时对于数据获取范围也可以根据WS服务的输入参数灵活定义。
已有服务总线交互支撑情况分析
既然企业集成场景复杂，存在不同的服务集成场景。那么就需要分析当前已经存在的多套服务总线对各类服务集成场景的支撑情况。
这种支撑情况包括了强支撑还是弱支撑。
同时也包括了支撑范围分析，既服务总线是只支撑集团层面或子公司层面，还是说服务总线本身已经实现集团-省两级的支撑架构。
通过上面分析实际可以看到对于技术类服务，流程类服务很多子业务域的服务总线并不能提供支撑能力。同时还有些服务总线往往也局限在集团或某个子公司范围里面。
类似技术服务，当前只有PaaS-ESB总线提供支撑能力，那么这个支撑能力就可以进一步开放共享给其它业务域使用。但是对于业务服务集成，多套服务总线都具备这个能力，更好的方式就是需要对这部分重复能力进行整合。
多套ESB总线集成交互情况分析
多套ESB总线之间本身也存在集成和交互情况。
对于ERP和PaaS总线，当前根据规划后续都需要整合到PaaS-ESB一套服务总线上面。而对于第2点ERP和营销域ESB集成。如上图：
A到B系统的服务消费调用，需要经过两次服务总线接入和传递，同时需要进行服务规范标准转换。而对于PaaS平台ESB和营销域ESB总线之间，当前也是存在两套服务规范标准，对于新识别服务要求是完全按PaaS规范实施。
多套总线存在的问题分析
对于多套总线存在的问题，在分析的时候主要从管控治理，实施方法，架构体系三个方面进行展开描述。
01 在管控治理层面：
没有形成集团全局统一的服务目录库和服务资产管控和治理方法不统一，各总线的管控侧重点有差异，也存在重复建设更多的是根据管理域进行分工，而非根据服务能力进行分工
02 在实施方法层面
当前服务规范有多套标准，导致跨总线服务集成存在多次转换当前服务识别分析和服务实施方法存在差异，对应用厂商造成重复熟悉的影响
03 在架构体系层面
当前主要有两套，一套是Oracle SOA套件，一套是开源ESB产品，开源产品的业务交易没有一个集团级统一的服务总线架构体系，原来基本根据业务需求分域建设在总体架构规划设计上，服务总线本身基础架构需要云化和纳入PaaS管理平台
企业服务总线-服务架构
SOA解决两个层面问题，一个是数据和应用集成，一个是能力开放和共享。因此SOA服务本身存在多个层面，需要有不同的能力进行支撑(数据，业务，流程）。
如上图基于不同的集成场景和服务集成类型，可以得到上面的服务架构。服务架构本身也是分层，最底层技术服务，中间是业务服务，上层是组合和流程服务。
技术服务：数据服务，文件服务，技术服务业务服务：业务服务，消息服务流程服务：流程服务，组合服务
SOA管理平台实现统一服务目录库，统一服务咨询实施标准，包括系统和业务两个层面。 服务总线后续整理内部分工和技术组件划分后续对外透明，对外部应用应该是统一的一个总线
企业服务总线-应用架构
在应用架构中，底层是总线基础管理平台，中间为支撑业务集成，消息集成，文件集成，技术集成的各类服务集成能力。同时还增加了元数据管理和规则引擎的能力。
右边为SOA服务治理和管控平台。
最上层未统一暴露的服务目录库，即虽然下层可能存在各种集成组件和引擎，但是最终的服务目录库仍然需要考虑统一开放和共享。如果查询服务目录列表还需要访问多个ESB总线才能够完成，那么显然没有达到整合的目的。
企业服务总线-集成架构
该图给出了各类服务总线的集成和调用关系。
从图上也可以看到整体的调用顺序还是从上朝下调用，流程服务可以进一步调用业务服务和技术服务，而业务服务也可以向下调用各类技术服务能力。
统一服务提供和集群化
在这里给出的关键思路就是对于服务总线的整合，应该是基于不同的服务集成场景和服务支撑类型进行整合。
即业务服务支撑需要整合多套ESB总线能力，提供最终一套能力支撑即可。而对于数据服务，技术服务也是同样的道理。同类服务能力支撑全部整合和归并为一套大集群。
统一服务总线管控和治理
在进行服务总线整合的时候，如果老的服务总线能够全部下线服务迁移到新的总线是最佳方案。如果老的服务总线仍然需要存在一段时间，逐步平滑迁移和过渡，那么也需要提供一个统一的服务管控和治理能力。
也就是底层ESB总线引擎可以有多套，但是上层的服务治理管控，服务目录库必须整合为一套统一对外开放和提供。
两级架构模式说明
ESB总线在整合中一个平滑过渡期。
在过渡期间，省公司仅部署轻量服务代理，不再部署重型的企业服务总线。省和省间的相互协调需要通过集团总线进行统一调度，省省间协同是否考虑待进一步分析。 在集团侧总线没有整合前，暂保留服务调用走两级服务总线交换的模式。
