对ESB服务总线和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总线的产品架构图如下：
　　在整个产品的研发和设计中，我们实际做了以下重要事情。
　　其一就是ESB底层引擎和ESB管控治理平台的完全分离。即引擎和管控平台可以单独卖，也可以单独进行部署，两者之间通过内部接口进行交互。这个分离不仅仅是方面后续的资源弹性扩展，更加重要的是实现了管控和引擎能力的进一步解耦。
　　其次就是重新进行ESB开发设计器的开发，在Web端提供简单的服务组装设计能力，包括我们常见的数据库适配，协议转换，数据映射等基本都可以通过服务设计器完成。
　　最后就是进一步扩展上层的OpenAPI能力开放平台，对于能力开放平台可以看我前面已经发布的文字，能力开放平台更多的是实现整个服务接入和消费的自服务能力，对服务本身的运营能力和运维监控能力。
　　而对于API网关，我们则是基于开源的Kong网关进行定制开发。
　　当前Kong网关也是大家采用比较多的一个开源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网关所有能力。
　　基于上面这个思路，我们需要做的主要包括安全能力增强：包括Basic安全，Auth2.0，Token动态令牌，Https支持等方面能力。限流熔断能力：包括完整的限流熔断能力提升，而且能够控制到细粒度的单个服务。对于Http Rest接口服务注册能力增强，同时增加简单的数据映射能力支持。对API标准规范，设计，服务契约，帮助，swagger集成等方面能力增强。API在线测试和自动化测试能力增强对于Http Rest API和传统的WS接口服务互转能力的增强
　　基于以上关键点进行进一步的优化和完善后，即能够为企业提供一套完整的SOA服务总线产品，同时支撑传统的ESB服务总线能力，又对Http Rest API接口的接入，注册和管控方面能力得到全面增强。ESB总线和API网关两级集成
　　在前面我就谈到，传统企业在进行微服务架构转型过程中，是一个逐步迁移和改造的过程，因此往往存在新微服务架构采用API网关，遗留系统集成仍然是ESB服务总线的业务集成场景。
　　那么在这种集成场景下，就存在ESB服务总线和API网关两级集成和协同的场景。
　　我们以一个集成场景来进行说明，即企业遗留系统集成采用ESB服务总线，而对于新建设的一个微服务应用采用API网关，那么就存在两者协同和集成的过程，整体集成架构如下：
　　可以看到，在这种集成架构下，微服务整体应用系统中所有的需要和遗留系统交互的接口全部首先接入和注册到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总线进行适配问题。
　　场景一：遗留系统访问微服务提供的接口微服务模块提供Http Rest接口并注册接入到API网关。ESB服务总线适配API网关的Http Rest接口并将其暴露为SOAP WS接口。对于遗留系统仍然消费和原来已有的SOAP接口，因此无须改造
　　场景二：微服务需要访问ESB总线提供的SOAP接口
　　注意在这种场景下，API网关往往并不具备对SOAP服务进行接入和适配的能力，因此在这种场景下，具体的协议转换和适配仍然需要ESB总线完成。ESB总线对遗留系统提供的SOAP接口进行适配，发布为Http Rest接口ESB总线实际对遗留系统SOAP同时发布SOAP和Http Rest两个服务API网关将ESB总线提供的Http Rest接口注册和接入微服务模块访问API网关提供的Http Rest接口服务
　　实际上我们看到，在微服务集成场景下，对ESB发布的Rest接口并不一定要接入API网关，对于微服务模块可以直接访问ESB总线提供的接口服务。但是在这种场景下，每个微服务对于ESB总线来说都是一个独立的接入系统，需要在ESB总线进行管理。
　　基于API网关构建微服务集成技术中台
　　在上面这个场景可以看到，一个传统的应用迁移到微服务架构，就形成一个微服务应用体系，在这个微服务应用里面就存在API网关，服务注册中心，配置中心等微服务治理管控组件。那么当多个传统遗留系统都逐步转移到微服务的时候，如果同时存在多个各自为政的API网关，配置中心，注册中心等显然是不合适的，这个也不方面后续进行微服务架构治理。
　　在这种场景下，我们希望是各个微服务模块尽量存粹，而将微服务治理能力平台化，即将网关，注册中心，配置中心，限流熔断能能力全部整合到技术中台中统一提供，而不是各个微服务体系单独一套。在这种整合后整个架构更加清晰，如下：
　　基于这个思路，遗留系统逐步迁移和消亡，那么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消息订阅接口进行。