首先，朱雪琳感谢你能坚持经常过来关注我！下面我就来说说api接口开放平台推荐(api网关设计原则)，以及关于网关,接口,总线这些的相关干货，其实这篇文章主要还是为新手朋友整理的，总的来说思路还是很重要！

今天准备谈下ESB服务总线和API网关产品的集成和融合分析。

先谈下背景，在前面我写过多篇企业传统IT架构微服务架构转型的文章，中间也分析过API网关产品和ESB服务总线产品的区别。而实际上可以看到企业进行微服务架构转型，往往都是一个逐步迁移和过渡的过程。

而对于企业遗留IT环境，由于涉及到的遗留系统消息，协议，数据复杂，往往已经使用了类似ESB服务总线产品进行业务系统之间的应用和数据集成。而实际在转型中往往一个遗留系统可能会完全重新采用微服务架构框架体系进行建设，而这个微服务应用中也涉及到API集成的问题，这种API集成往往会采用更加轻量高效的API网关来完成。

很多时候我们在谈到微服务的时候，都会说到ESB服务总线已经过时，但是实际上对于大的企业存在大量遗留IT系统建设和集成的场景下，一定会存在ESB服务总线和API网关两种集成产品共存和协同的一段周期来完成过渡。

因此今天准备从几个方面来讲解下ESB和API网关的集成和协同。

1.从产品规划层面，对ESB总线和API网关两种产品集成

2.从企业IT存在遗留和微服务两种应用场景下的集成

3.在准备迁移到完整微服务后，对API网关本身的适配能力提升

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

对ESB总线和API网关两类产品的整合

对于我们从10年开始进行自研ESB服务总线的研发，从最早的完全自研，到13年底我们重新启动基于开源的SercieMix和Camel规则引擎进行定制开发。在这几年中重点也是对SOA服务开发设计，服务全生命周期管理，SOA管控治理等能力进行完整。

整体的ESB总线的产品架构图如下：

而对于API网关，我们则是基于开源的Kong网关进行定制开发。

当前Kong网关也是大家采用比较多的一个开源API网关产品，底层基于Ngnix和OpenRestry，语言是Lua语言，最重要的是整个架构设计中的可插拔的插件机制，这种插件机制很方便我们自定义插件扩展。比如我们现在对于安全，日志，运行监控等功能都能够很方便的通过插件扩展来实现。

当然你也能够看到对于ESB总线本身也可以完全兼容API网关产品有的对Http Rest接口注册接入，安全，日志，流控等功能要求。但是ESB总线整体还是偏重，如果是一个完整的微服务架构应用环境，我们还是推荐直接采用API网关来实现。

基于上面分析，我们看到。

对于ESB总线和API网关都是底层的进行SOA服务和API接口集成的底层引擎。而对于SOA服务全生命周期管理，服务运行监控，能力开放等业务场景和功能需求是完全可以整合为一套的。这也是我们在进行产品规划和设计的时候重点考虑的内容，即将引擎能力和管控治理能力分离，将管控治理能力进行共性化整合设计。

基于以上思路我们对整个架构进行整合如下：

可以看到，在这种集成架构下，微服务整体应用系统中所有的需要和遗留系统交互的接口全部首先接入和注册到API网关，同时API网关暴露的服务进一步集成和注册到ESB服务总线，形成两级服务集成的方式。

在这种两级服务集成模式下好处包括

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

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

如果站在微服务应用角度来看，那么我们完全可以将外部遗留系统都作为对微服务通过API网关暴露的接口的消费方，不同点仅仅在于这些对API网关发起的消费都统一通过ESB服务总线进行了路由和中转。

通过ESB总线代理的作用一方面是实现对所有接口的管控治理，另外一个重点就是解决老接口协议调用方式和新接口之间的适配和转换问题，如下图：

基于这个思路，遗留系统逐步迁移和消亡，那么ESB总线也准备消亡被API网关或微服务治理平台代替。在整个过程中，我们可以逐步提升API网关的协议转换适配能力，以加快对ESB总线的替代操作。

对API网关接口适配能力提升

最后谈下API网关如何提升接口适配能力。

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

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

对于Http Rest API接口服务接入是API网关提供最常见的接口服务接入和适配能力，这里面一种是存代理方式接入或透传，一种是在接入过程中还需要进行适度的数据裁剪和数据丰富。不论是哪种接入，都可能存在在接入过程中增加API网关标准管控所需要的类似SysID，Token等信息。

DB数据库的适配接入

即当前一些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网关应该提供的一个API接口服务快速发布的能力，即将已有的消息中间件的消息接口快速发布为一个Http Rest接口服务。即调用API接口将数据写入到消息中间件而不是数据库，对于消息的订阅则仍然可以走传统的JMS消息订阅接口进行。

好了，今天我们就说到这里，希望能帮助到你们，看完了，觉得这篇api接口开放平台推荐(api网关设计原则)写的还不错的话，别忘了点个赞哈！