企业集成场景需求和发展演进
需求调研概述
最近在外调研，重点还是想谈下企业对业务系统间的集成需求和ESB平台本身的能力需要方面的一些思考和记录，传统我们谈最多的还是ESB服务总线覆盖了数据集成，业务集成和流程集成完整集成场景，同时提供了相应的适配，协议转换，文件传输等方面的能力。
对于多年实施ESB下来，最大的一个感受还是ESB服务总线首先要解决的仍然是业务系统间的集成问题，其次才是解决服务复用，共享和能力开放层面的问题。
这两者在技术实现上有一个最大的区别体现在，谈集成的时候往往数据落地，也不一定需要实时；而谈服务和能力开放的时候则往往是数据不落地，实时发起调用。因此谈集成的时候往往仍然无法很好地解决数据多点落地后在同一时点不一致的问题，而谈到数据不落地场景则会造成业务系统传统开发方法巨大变化，在前面PaaS平台的组件化开发架构中我已经多次提到，在这里就不再重复。
ESB服务总线提供统一的服务目录库，统一的服务接入，服务订购，服务鉴权和服务运行监控能力。其中一个核心就是服务运行监控，运行日志和异常分析，告警和预警等。这是ESB平台的一个关键需求，就是在接口服务运行出现问题的时候能够快速地定位和诊断，而不是由于接入了ESB总线导致问题分析定位更加困难。这是ESB平台服务治理管控中一个最基本的需求。
大家都知道，ESB服务总线最适合的仍然是处理大并发，小数据量的业务服务实时调用，而对于大数据量的类似数据集成和传输类服务调用往往性能就下降明显。对于大数据集成本身也不是ESB总线的强项，正是由于这个原因类似Oracle等产品推出了ODI解决方法，将WS和传统ETL进一步集成，实现大数据传输流和消息控制流的分离大数据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总线产品问题，更多的还是实施管控治理方面的问题。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。