今天我要讲的是ESB服务总线和API***产品的集成与融合分析。

先说背景。我写过很多关于企业传统IT架构微服务架构转型的文章，分析过API***产品和ESB服务总线产品的区别。其实可以看出，企业微服务架构的变革，往往是一个逐步迁移和过渡的过程。

对于企业遗留IT环境，由于遗留系统消息、协议和数据的复杂性，类似ESB的服务总线产品通常用于业务系统之间的应用程序和数据集成。事实上，在改造中，一个遗留系统可能会通过使用微服务架构框架体系而被完全重新构建，而这个微服务应用也涉及到API集成的问题，这往往是通过使用更轻量级、更高效的API***来完成的。

很多时候，当我们谈论微服务时，我们总是说ESB服务总线已经过时了，但事实上，当大型企业中有大量遗留的IT系统构建和集成时，ESB服务总线和API***之间会有一段时间的共存和协作来完成过渡。

所以今天我们要从几个方面来阐述ESB和API gateway的集成和协作。

1.从产品规划层面，整合ESB总线和API***。

2.从企业IT遗留和微服务的整合。

3.准备迁移完成微服务后，API***本身的适应性就提高了。

下面将从这三个方面进行介绍。

ESB总线和API***产品的集成

我们从10年开始自研ESB服务总线的研发，从最早的完全自研，到13年底重启基于开源的SercieMix和Camel rule引擎进行定制开发。近年来，重点也放在SOA服务开发和设计的完整性、服务生命周期管理、SOA控制和治理等方面。

整个ESB总线的产品架构图如下:

在R&D和整个产品的设计中，我们实际上做了以下重要的事情。

一个是ESB底层引擎和ESB控制和治理平台的完全分离。也就是说，引擎和管理控制平台可以单独销售或部署，它们通过内部接口进行交互。这种分离不仅仅是后续的资源弹性扩展，更重要的是实现了管控和引擎能力的进一步解耦。

其次，就是对ESB开发设计器进行二次开发，在Web端提供简单的服务组装设计能力，包括我们常见的数据库适配、协议转换、数据映射等等，基本都可以由服务设计器完成。

最后，是在上层进一步扩展OpenAPI平台。对于开放平台，可以看我之前发表的文字。开放平台更多的是实现整个服务接入和消费的自助服务能力，对服务本身的运营和运行进行监控。

对于API***，我们基于开源的Kong***进行定制开发。

目前，Kong Gateway也是一款被人们广泛使用的开源API***产品。底层基于Ngnix和OpenRestry，语言为Lua语言。最重要的是整个架构设计中的可插拔插件机制，方便我们定制插件扩展。比如现在我们可以通过插件扩展轻松实现安全、日志、操作监控等功能。

当然，你也可以看到ESB总线本身可以完全兼容API***产品，以及Http Rest接口的一些功能需求如注册、访问、安全、日志、流量控制等。但是ESB总线整体还是偏的。如果是完整的微服务架构应用环境，我们还是建议直接采用API***来实现。

基于以上分析，我们可以看出。

ESB总线和API***是集成SOA服务和API接口的底层引擎。对于SOA服务生命周期管理，服务运行监控、能力开放等业务场景和功能需求可以完全集成到一个***中。这也是我们在规划设计产品时重点考虑的，即把引擎能力和管控能力分开，把管控能力整合到一个通用的设计中。

基于上述想法，我们将整个架构整合如下:

即总体思路是有两套底层引擎，即一套是ESB总线引擎，一套是API***引擎，但是SOA治理控制和操作开放集成在一套。一个是SOA运维监控平台统一，一个是能力开放平台统一。

但是我们可以看到，ESB总线虽然是一个重型引擎，但是在我们不启用它的协议转换、数据映射、服务安排等复杂功能的情况下，它仍然可以作为一个轻量级的SOA总线。

而且我们可以看到另外一种场景，就是企业往往不会很快完成微服务架构的转型，总有传统的遗留系统，所以集成问题和场景本身就很复杂。即使整个集成趋势主要是Http Rest接口集成和API***集成，但你仍然必须兼容传统的WS服务集成和简单的协议转换能力。

实际上，ESB总线本身支持Http Rest接口服务的注册和访问。因此，ESB服务总线和API***引擎有两种选择。

其一两套独立的引擎，然后在管控治理和服务运营开放层面整合为一套，即上图。其二对已有的ESB服务总线产品进一步升级，加强对Http API接口的支撑和管控。

第二种方法相对不复杂，容易实现，即升级ESB服务总线，全面支持ESB总线和+API***的能力。你可以说你卖的是ESB服务总线，但它完全兼容API gateway的所有功能。

基于以上想法，我们需要做的主要包括

安全能力增强：包括Basic安全，Auth2.0，Token动态令牌，Https支持等方面能力。限流熔断能力：包括完整的限流熔断能力提升，而且能够控制到细粒度的单个服务。对于Http Rest接口服务注册能力增强，同时增加简单的数据映射能力支持。对API标准规范，设计，服务契约，帮助，swagger集成等方面能力增强。API在线测试和自动化测试能力增强对于Http Rest API和传统的WS接口服务互转能力的增强

基于上述要点进一步优化和改进后，可以为企业提供一套完整的SOA服务总线产品，同时支持传统的ESB服务总线能力，访问、注册和控制Http Rest API接口的能力得到了全面增强。

ESB和API***的两级集成

我前面提到，传统企业的微服务架构转型是一个逐步迁移和转型的过程。因此，新的微服务架构中经常使用API gateway，遗留系统集成仍然是ESB服务总线的业务集成场景。

然后，在这个集成场景中，有一个ESB服务总线和API***之间的集成和协作的场景。

我们以一个集成场景为例，即ESB服务总线用于企业遗留系统集成，API gateway用于一个新建的微服务应用，所以两者之间有一个协作和集成的过程。整体集成架构如下:

可以看出，在这种集成架构下，微服务集成应用系统中所有需要与遗留系统交互的接口都是先接入并注册到API***，API***暴露的服务进一步集成并注册到ESB服务总线，形成两级服务集成模式。

这种两级服务集成模式的优势包括

微服务应用体系里面的各个微服务仅仅需要暴露特定的API接口到***和ESB内部微服务间的Rest API交互仍然可以走注册中心，而且对外透明可以进一步使用ESB总线协议转换和适配能力，完成SOAP和Rest接口转换和适配

两级集成模式虽然增加了一定的性能损失，但也拉长了整个服务调用链路。但是，在新旧架构共存的过程中，这种两级集成仍然是推荐的方式。既满足了微服务应用中的微服务治理要求，又实现了与外围系统的集成。

从微服务应用的角度，我们完全可以把外部遗留系统看成是通过API***暴露给微服务的接口的消费者。唯一不同的是，这些由API***发起的消费者都是通过ESB服务总线路由和传输的。

ESB总线代理的作用一方面是实现对所有接口的管理和控制，另一方面是解决旧接口协议调用方式与新接口的适配和转换问题，如下图所示:

我们可以举例进一步说明。

在传统的遗留集成架构中，所有服务都由SOAP WS集成，所有接口都注册并连接到ESB总线。对于遗留系统A，我们进行微服务改造，微服务。那么，原遗留系统A公开的SOAP WS接口，经过微服务改造后，将全部采用带标记的Http Rest API接口。

而原有的遗留系统B或C不希望A的微服务改造导致SOAP WS接口服务的消费端原有的改造，增加工作量。然后就是这个时候通过ESB总线适配的问题。

场景1:遗留系统访问微服务提供的接口

微服务模块提供Http Rest接口并注册接入到API***。ESB服务总线适配API***的Http Rest接口并将其暴露为SOAP WS接口。对于遗留系统仍然消费和原来已有的SOAP接口，因此无须改造

场景2:微服务需要访问ESB总线提供的SOAP接口

注意，在这种场景下，API***往往不具备访问和适配SOAP服务的能力，所以在这种场景下，具体的协议转换和适配仍然需要ESB总线来完成。

ESB总线对遗留系统提供的SOAP接口进行适配，发布为Http Rest接口ESB总线实际对遗留系统SOAP同时发布SOAP和Http Rest两个服务API***将ESB总线提供的Http Rest接口注册和接入微服务模块访问API***提供的Http Rest接口服务

其实我们可以看到，在微服务集成的场景下，发布到ESB的Rest接口不一定要连接API gateway，微服务模块可以直接访问ESB总线提供的接口服务。但是在这个场景中，每个微服务都是一个独立的ESB总线的访问系统，需要在ESB总线上进行管理。

构建基于API gateway的微服务集成技术平台

从上面的场景可以看出，当传统应用迁移到微服务架构时，就会形成微服务应用系统。在这个微服务应用中，有API***、服务注册中心、配置中心等微服务管理和控制组件。那么，当很多传统遗留系统逐渐转移到微服务时，拥有多个API***、配置中心、注册中心等显然是不合适的。它们同时相互独立，这并不意味着将来会管理微服务架构。

在这种场景下，我们希望每个微服务模块都尽可能精粹，微服务治理能力平台化，即***、注册中心、配置中心、限流、熔断能力都集成到技术平台中统一提供，而不是单一的一套微服务系统。集成之后，整个架构更加清晰，如下所示:

基于这种思想，遗留系统逐渐迁移消亡，于是ESB总线准备消亡，被API***或微服务治理平台取代。在整个过程中，我们可以逐步提高API***的协议转换适应性，以加快ESB总线的替换操作。

提高API***接口适应性

最后讨论了如何提高API***的接口适配能力。

虽然API提供的接口适配不会像ESB服务总线一样提供各种复杂的适配器，但还是需要提供一些常用的适配能力，以方便API接口的快速开发和访问能力。

最常见的代理访问能力-Http Rest API接口服务

对于Http Rest API接口服务访问，API gateway提供了最常见的接口服务访问和适配能力。其一是代理访问或透明传输，其二是在访问过程中需要适当的数据切割和数据丰富。无论哪种访问，都可能存在SysID、Token等信息。需要在访问过程中添加API***标准控件。

对数据库的自适应访问

也就是目前一些API***会提供，可以快速发布DB数据库表为Rest接口服务，一般包括数据库表对象的CRUD主流操作。同时可以实现一个通用的Http Rest接口服务，可以实现对所有数据库表类似的操作能力，但是也存在安全控制的风险。

二是提供一种类似于Sql模糊查询的联查接口的服务访问能力，即模糊动态查询条件。查询结果可以是后台多个表的关联查询。对于特定的查询，Sql由用户自己定义。

第三是复杂的业务对象被直接发布为Rest接口服务。一个复杂的业务对象实际上是由后端数据库中的几个数据库表组成的，可以是层次结构，也可以是关联结构。对于这种方式，目前通用的API***实际上并不支持，但实际上是一种经常遇到的DB数据库快速访问和适配的场景。

遗留SOAP-WS接口被自动转换成Http Rest接口

对于遗留的SOAP WS服务接口，应提供快速的服务适配和访问能力，即SOAP接口应自动转换为Rest API接口服务访问，消息结构应由XML转换为XML或Json数据结构。

服务编排和组合服务访问

这是主流API***也会通过的服务注册接入能力，即将现有的API服务接口进行组合组装，然后发布一个组合服务。在这个过程中，完成了多个服务的集成和数据映射。这是之前很多文章中服务布局的重点。

对于服务编排和组合访问，通常需要提供一个可视化的服务编排设计器来完成服务编排访问。服务安排的场景有服务串联、服务组合、服务合并和拆分。

消息中间件的消息接口发布为Http Rest接口

这也是API gateway快速发布API接口服务的能力，即将消息中间件已有的消息接口快速发布为Http Rest接口服务。即调用API接口将数据写入消息中间件而不是数据库，仍然可以通过传统的JMS消息订阅接口进行消息订阅。