数据中台的API网关替换传统的ESB总线可行性分析

大家都清楚传统的IT架构和集成一般都采用ESB服务总线进行集成，这是一种典型的中心化架构，但是可以充分的利用ESB总线的适配，协议转换，消息拦截等能力进行各种SOA治理和管控操作。

那么在传统企业IT架构转型过程中，如果需要对ESB总线进行升级改造，或者说整体IT架构本身就存在老架构和新微服务架构共存的一个集成场景。那么在这种情况下还按传统方式去升级ESB总线显然不合适，最佳的方法应该是去考虑是否能够用API网关替代ESB总线。

目前公司准备上线奇点云数据中台DataSimba

数据中台已经包含API网关集成，企业总线是否还要上线？

API网关概述

在微服务架构体系里面，我们一般会使用到微服务网关或叫API网关。

大家都比较清楚，在微服务架构体系下本身是去中心化的架构，通过服务注册中心来实现服务注册发现和消费调用，那么为何又需要使用API网关?

在传统的ESB总线进行服务集成的时候我们就经常谈到一个概念就是位置透明，即需要屏蔽底层业务模块提供API接口服务地址信息，并实现多个微服务API接口的统一出口。即类似设计模式里面经常谈到的门面模式。

如何给API网关一个定义?

简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。

内部的微服务对外部访问来说位置透明，外部应用只需和网关交互
统一拦截接口服务，实现安全，日志，限流熔断等需求

从这里，我们就可以看到API网关和传统架构里面的ESB总线是类似的，这些关键能力本身也是ESB服务总线的能力，但是ESB服务总线由于要考虑遗留系统的接入，因此增加了：

大量适配器实现对遗留系统的遗留接口适配，多协议转换能力
进行数据的复制映射，路由等能力

对于两者，我原来做过一个简单的对比，大家可以参考。

API网关相比ESB欠缺能力分析

基于上面的对比基本可以看到API网关类似一个轻量的只支持Http Rest API接口的总线，其它类似ESB总线比较重的协议转换，数据映射，轻量服务编排等能力都不再具备或提供。当考虑用API网关对ESB进行替代的时候，欠缺的能力包括。

1.SOAP WS的支持和集成能力

注意API网关是不支持对传统的SOAP WS接口是进行适配和接入的。如果要接入，那么只能是纯粹的Http服务代理模式进行接入，而对于消息报文等XML格式无法进行处理和解析。当无法对消息报文进行解析的时候，对这类WS服务要进行相应的管控也很难做到。

2.消息中间件能力

对于API网关底层一般并没有一个消息中间件，那么对于消息集成，类似JMS消息的适配能力自然也没有。API网关接口服务更多都是同步服务调用模式，类似原有的异步消息集成，消息一对多分发等场景在API网关本身无法实现。

3.各种适配和协议转换能力

这个本身也不是API网关的强项，一般的API网关产品也不会去做这块内容。类似DB数据库的适配，文件适配，消息适配，TCP，SOAP和Rest API接口间的协议转换等都无法提供。对于数据映射部分API网关产品会通过数据映射插件进行简单的数据映射能力。

4.路由能力

对于路由能力来说，API网关一般会提供简单的路由能力，比如通过Url里面传递的关键参数进行路由，但是无法支撑基于消息报文里面的内容进行路由。

API网关替代ESB的可行性分析

API网关替代ESB，简单来说就是需要在API网关上扩展欠缺的能力，这样原有注册在ESB总线上的接口服务才能够做到平滑迁移。

对于API网关对ESB的替换个人核心观点如下：

即不对API网关引擎本身进行大量的代码定制，而是应该将欠缺的能力作为代理组件或插件方式实现并最终和API网关融合为一个整体。

基于这个思路进行分析如下。

数据库适配和协议转换能力

对于这部分能力，最佳做法即是将其移出到API快速开发平台或组件里面，即在该组件里面完成对数据库的适配，协议转换等动作，最终形成一个Http Rest API接口再注册和接入到API网关。也就是说API快速开发平台即是API网关的一个关键外挂。

消息中间件集成和适配

在传统的SOAP WS接口服务实施里面，我们做了一个关键的事情。

即JMS消息集成将其分解为两步，对于JMS消息的发送能力，通过JMS消息适配最终转换为一个SOAP WS接口服务。该接口服务在获取到消息后再将消息写入到消息中间件。

但是对于消息的订阅，由于要保留消息中间本身的消息持久化，一致性，重视，消息1对多发布订阅能力，我们仍然保留了传统的JMS消息订阅机制。但是这种机制本身会走TCP协议接口，在订阅端也存在要安装相应的消息中间件代理SDK包。整体来说还是存在一定的耦合性，特别是消息中间件一些能力要进行变更的时候，往往涉及到订阅端也需要修改。

在API网关集成下，引入一个开源的消息中间件来弥补异步消息集成是必须的。对应消息中间件介绍可以参考我以前发布过的相关文章。

在消息中间件引入后，可以将消息发布能力封装适配后形成一个Http Rest API接口暴露。但是对于订阅能力，个人希望是不再通过消息中间件本身的订阅机制。

而是在各个订阅端提供Http Rest API的导入数据接口服务，由代理组件来完成消息的发布和定义工作。也就是说不再是订阅端去监听消息的变化，而是代理组件在获取到数据后根据消息订阅情况主动分发。

对于SOAP WS接口服务的支持

由于当前API网关基本都是基于Http Rest API接口注册接入进行设计，因此对传统的SOAP WS接口服务的支持能力很弱。

个人想法是实现一个单独的代理和转换组件来进行SOAP WS的处理，在这个组件里面可以将SOAP WS接口转换为Http Rest API接口服务。也可以对SOAP WS进行新的数据拦截和报文解析，并进行相应的安全访问控制，路由格式转换等操作。

当然对于SOAP WS接口服务本身也不是必须转换为Http Rest 接口再注册到API网关。这类遗留服务可以直接接入到API网关，但是本质是一种代理透传的模式。在这种模式下，所有管控能力，转换能力，路由能力等都需要外挂插件来解决。

那么外挂插件基本实现了一个小型的ESB总线该有的能力，如何保证外挂插件本身的可靠性和性能本身又成为一个关键问题。

基于内容动态路由支持

API网关可以根据Url地址参数信息进行简单路由，但是基于内容的动态路由实际支撑得并不好。在传统ESB总线实施中，我们可以根据消息头，根据输入消息报文内容中关键字段信息进行动态路由，包括在路由处理前还进行相关的安全访问和权限判断。

实际这些在API网关当前并不支持。

前面已经提到一种做法即在接口服务消费前进行代理组件拦截，还有一种做法则是单独在开发一个路由服务，在该服务里面来实现动态基于内容的路由能力。

初步思考总结

如果仅仅是SOAP和Rest接口转换，数据库适配，代理路由等替换，采用API网关+插件方式完全可以实现。但是如果对于SOAP WS服务注册接入，安全管控完整能力的实现，要在API网关上面进行定制和调整，其工作量不小于单独实现一个小的SOAP WS服务集成的ESB总线能力，这个实际还需要进一步论证实现的可行性。

初步结论：在新的技术框架不断迭代下，JSON已经成为平台对外主流传输方式,RESTful API在软件行业不断攻城略地，API网关拓展边界集成消息中间件功能，API网关可以成为轻量级企业总线代替方案。