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网关本身的适配能力提升

【api接口开放平台推荐 api网关设计原则】下面将分别从这三个方面进行介绍。
对ESB总线和API网关两类产品的整合对于我们从10年开始进行自研ESB服务总线的研发，从最早的完全自研，到13年底我们重新启动基于开源的SercieMix和Camel规则引擎进行定制开发。在这几年中重点也是对SOA服务开发设计，服务全生命周期管理，SOA管控治理等能力进行完整。
整体的ESB总线的产品架构图如下：
在整个产品的研发和设计中，我们实际做了以下重要事情。
其一就是ESB底层引擎和ESB管控治理平台的完全分离。即引擎和管控平台可以单独卖，也可以单独进行部署，两者之间通过内部接口进行交互。这个分离不仅仅是方面后续的资源弹性扩展，更加重要的是实现了管控和引擎能力的进一步解耦。
其次就是重新进行ESB开发设计器的开发，在Web端提供简单的服务组装设计能力，包括我们常见的数据库适配，协议转换，数据映射等基本都可以通过服务设计器完成。
最后就是进一步扩展上层的OpenAPI能力开放平台，对于能力开放平台可以看我前面已经发布的文字，能力开放平台更多的是实现整个服务接入和消费的自服务能力，对服务本身的运营能力和运维监控能力。
而对于API网关，我们则是基于开源的Kong网关进行定制开发。
当前Kong网关也是大家采用比较多的一个开源API网关产品，底层基于Ngnix和OpenRestry，语言是Lua语言，最重要的是整个架构设计中的可插拔的插件机制，这种插件机制很方便我们自定义插件扩展。比如我们现在对于安全，日志，运行监控等功能都能够很方便的通过插件扩展来实现。