多年做SOA项目咨询和实施。可以看出，企业内部业务系统之间的集成主要分为三个阶段。在传统的EAI和ESB总线阶段，更多的解决方案更重要的是从点对点的蜘蛛网集成向总线集成过渡；而在微服务架构的现阶段，更多的是从总线集成到能力开放的过渡。谈到集成，往往会涉及到多个业务系统之间的数据交换和数据落地。这样虽然降低了业务系统之间的耦合度，但是也带来了数据多次落地带来的数据实时性和一致性问题。问题。在微服务阶段，更强调按需通过能力接口实时使用数据，而不是通过接口将数据同步到自己的系统。因此，集成的发展本身就是一个从接口集成到能力开放的发展过程。同时，集成的思路也逐渐从集中式总线集成向分散式集成转变。企业应用集成可以分为以下三个阶段，分别介绍如下。第一阶段：完整的点对点集成业务系统以点对点的方式进行集成，形成蜘蛛网状的集成架构。在这个阶段，有几个开发过程。初期，接口完全非标准，各种实现技术，各种规范定义存在。同时，安全、日志等管控也薄弱，问题最多。后续故障排除很麻烦。最好是定义接口标准，比如使用标准的WS服务接口进行集成，或者根据不同的场景定义2到3种可选的集成方式。在这种情况下，接口本身是标准化和规范化的，但主要问题是接口本身的控制和治理，即没有一个统一的控制和治理中心可以实现对企业所有接口的统一访问，以及打开、授权、日志监控、故障排除等统一监控。点对点集成下，接口难以复用。如果有接口需求，就做一个接口，造成大量的重复开发和联调工作量。同时，点对点集成商自身的技术也使其难以复用。例如，一个JMS消息集成、一个大文件传输集成等，往往需要各个业务系统准备实现相同的技术组件。这块本身也是无谓的增加工作量和技术投入。第二阶段：类似于接口平台或集成平台发展到第二阶段，目前比较多的是接口平台或集成平台。这一阶段最大的变化之一就是由原来的点对点集成模式转变为基于接口平台的总线-枢纽集成模式。业务系统之间的所有接口不直接交互，而是直接注册连接到集成平台，然后集成平台发布统一的接口服务地址，供外部业务系统调用。一个集成平台基本都会支持传统消息、数据、文件、WS服务等多种模式的集成能力。一体化平台的建设和实施一般会进一步约定接口技术标准和规范、接口开发标准、接口服务的接入标准和消费标准，同时在安全、日志、异常监控、在路由、消息发布、订阅等诸多方面提供了更强的能力支持。这些都在一个统一的集成平台上完成，真正提高了SOA的治理和控制能力。在集成平台阶段，往往有两种场景。一种是传统的数据交换平台，以数据交换为主，所有数据全部落地；另一种是服务共享平台，提倡服务接口的实时消费和使用，数据要尽可能小。降落。目前更多的是服务共享平台模式，但同时存在接口服务数据落地和非落地两种消费场景。第三阶段：能力开放和OpenAPI平台能力开放和OpenAPI平台在网上讲的比较多，但这也将是企业内部融合发展的必然趋势，不仅企业内部业务系统能力更多对外开放，如电子商务、B2B等。二是内部业务系统之间能力的开放。第二阶段，A代替B提交接口需求，系统B考虑实现一个接口服务。到了能力开放阶段，更多的是B系统考虑哪些能力需要开放和发布。这是一个关键的顺序更改。在集成平台阶段，可以看到服务注册接入和服务消费这两个过程往往是高度耦合在一起的。只有当有接口需求时，B系统才会提供接口服务，A系统会立即消费。在OpenAPI平台阶段，服务访问和服务消费两个过程是松耦合的，即即使没有消费者也可以访问能力并发布到能力库，各业务系统可以随时查看服务目录time图书馆和服务市场发起服务订购请求和消费。在OpenAPI平台阶段，更加强调基于业务系统的能力开放。同时也强调了基于OpenAPI平台的各业务系统的自服务流程，即整个流程不需要太多的集成商参与工作，所有需要的标准和规范也都在固化为类似的服务接入、服务订购、服务激活等自助服务流程。在传统的集成平台中，SOAPWS、Rest、JMS消息以多种方式共存，而在OpenAPI平台上，由于侧重于能力的暴露和发布，所以基本上可以统一成一个轻量级的Rest服务接口服务模型。
