摘要：基于以上思考，我们在传统ESB总线产品规划基础上就开始考虑增加API网关子产品，API网关产品不是简单的基于已有的自研ESB产品进行改造升级，而是基于当前主流的开源API网关产品，类似Kong网关进行定制开发和扩展，从当前趋势也可以看到在微服务架构推广实施下，Kong网关很可能成为一个主流的API网关产品。引擎和管理平台要拆分开：这个在很早一起进行的SOA和ESB产品规划的时候，我们就做到这一点，即ESB引擎要和ESB的管控治理平台拆分开，ESB可以多多种方式，类似Oracle OSB，Kong API网关，我们自研的ESB都属于ESB引擎的范畴。

今天再次对整个产品规划体系进行了重新思考，也明确了整体的产品架构和后续关键产品研发路线。在我博客上面原来重心也一直围绕ESB服务总线再谈，虽然有不少文章也谈到了API网关，OpenAPI能力开放平台，微服务架构，但是都没太详细展开，今天对这些内容再做一次梳理。

ESB服务总线和API网关：注意只两个实际上是一个层面的东西，如果SOA和微服务架构是一个层面，那么ESB总线和API网关就是另外一个对等层面，只是ESB总线更加重，支持传统异构系统协议转换，适配，数据映射等复杂能力。而API网关更加轻量，重点就是通过代理实现内外网隔离，其次就是各种安全，日志，流控拦截。

引擎和管理平台要拆分开：这个在很早一起进行的SOA和ESB产品规划的时候，我们就做到这一点，即ESB引擎要和ESB的管控治理平台拆分开，ESB可以多多种方式，类似Oracle OSB，Kong API网关，我们自研的ESB都属于ESB引擎的范畴。而基于引擎我们会建上层的管理平台，这个管理平台要做到能够兼容下面各种不同的引擎，前期我们规划也按该思路展开进行。

管理平台再进行二次拆分：对于管理平台需要再进行二次拆分，即涉及到本身接口管理的内容，包括接口服务注册，接入，安全配置等内容，这些内容和引擎绑定的很紧密，管理平台有时候并不容易做到多引擎适配。另外一部分就是完全的服务统计，监控运行分析内容，这部分内容我们完全是基于服务运行实例日志表展开，那么只要服务实例表是一套，我们的运行统计分析平台就可以做到完全复用一套。

基于以上思考，我们在传统ESB总线产品规划基础上就开始考虑增加API网关子产品，API网关产品不是简单的基于已有的自研ESB产品进行改造升级，而是基于当前主流的开源API网关产品，类似Kong网关进行定制开发和扩展，从当前趋势也可以看到在微服务架构推广实施下，Kong网关很可能成为一个主流的API网关产品。因此需要考虑基于当前新架构重新扩展一套API网关产品，API网关本身和已有ESB产品是一种平级的引擎，只是一个轻一个重而已。关键的功能实现实际上都一样。

基于API网关产品，我们进行上下左右扩展，这些扩展围绕API网关进行。

在底层，我们扩展和当前我们已有的DevOps支撑平台的集成，即任何一个微服务模块的开发不仅仅涉及到微服务组件模块，也涉及到微服务组件暴露的API接口服务，引擎API接口服务的全生命周期也可以用DevOps支撑平台完全管理起来。

在左边，也就是API运行的前生命周期，扩展API接口服务开发接入平台，方便API接口服务的快速开发和接入，类似传统PaaS平台规划的时候我们做的开发框架和环境，开发平台提供。整个开发接入平台，实现API接口服务的快速注册接入，接口服务的入库过程。

服务接入后运行在API网关引擎，在右边即管理后生命周期，包括了API接口服务的后期治理管控，运行统计分析，运行监控，监控预警，服务链监控，服务SLA等，都属于后生命周期内容。

在上层我们扩展Open API能力开放平台，实现API接口服务的能力开放，OpenAPI能力开放平台跟当前主流的京东，天猫的电商能力开放平台很类似，即需要提供面向API接口服务的运营能力，实际上我们完全可以理解Open API能力开放平台需要包括自服务流程，服务订购，服务计量计费等能力，即一个基本电商平台的变形。