用API网关来替换传统的ESB总线可行性分析

　　大家都清楚传统的IT架构和集成一般都采用ESB服务总线进行集成，这是一种典型的中心化架构，但是可以充分的利用ESB总线的适配，协议转换，消息拦截等能力进行各种SOA治理和管控操作。
　　那么在传统企业IT架构转型过程中，如果需要对ESB总线进行升级改造，或者说整体IT架构本身就存在老架构和新微服务架构共存的一个集成场景。那么在这种情况下还按传统方式去升级ESB总线显然不合适，最佳的方法应该是去考虑是否能够用API网关替代ESB总线。API网关概述
　　在微服务架构体系里面，我们一般会使用到微服务网关或叫API网关。
　　大家都比较清楚，在微服务架构体系下本身是去中心化的架构，通过服务注册中心来实现服务注册发现和消费调用，那么为何又需要使用API网关？
　　在传统的ESB总线进行服务集成的时候我们就经常谈到一个概念就是位置透明，即需要屏蔽底层业务模块提供API接口服务地址信息，并实现多个微服务API接口的统一出口。即类似设计模式里面经常谈到的门面模式。
　　如何给API网关一个定义？
　　简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。内部的微服务对外部访问来说位置透明，外部应用只需和网关交互统一拦截接口服务，实现安全，日志，限流熔断等需求
　　从这里，我们就可以看到API网关和传统架构里面的ESB总线是类似的，这些关键能力本身也是ESB服务总线的能力，但是ESB服务总线由于要考虑遗留系统的接入，因此增加了：大量适配器实现对遗留系统的遗留接口适配，多协议转换能力进行数据的复制映射，路由等能力
　　对于两者，我原来做过一个简单的对比，大家可以参考。
　　API网关相比ESB欠缺能力分析
　　基于上面的对比基本可以看到API网关类似一个轻量的只支持HttpRestAPI接口的总线，其它类似ESB总线比较重的协议转换，数据映射，轻量服务编排等能力都不再具备或提供。当考虑用API网关对ESB进行替代的时候，欠缺的能力包括。
　　1。SOAPWS的支持和集成能力
　　注意API网关是不支持对传统的SOAPWS接口是进行适配和接入的。如果要接入，那么只能是纯粹的Http服务代理模式进行接入，而对于消息报文等XML格式无法进行处理和解析。当无法对消息报文进行解析的时候，对这类WS服务要进行相应的管控也很难做到。
　　2。消息中间件能力
　　对于API网关底层一般并没有一个消息中间件，那么对于消息集成，类似JMS消息的适配能力自然也没有。API网关接口服务更多都是同步服务调用模式，类似原有的异步消息集成，消息一对多分发等场景在API网关本身无法实现。
　　3。各种适配和协议转换能力
　　这个本身也不是API网关的强项，一般的API网关产品也不会去做这块内容。类似DB数据库的适配，文件适配，消息适配，TCP，SOAP和RestAPI接口间的协议转换等都无法提供。对于数据映射部分API网关产品会通过数据映射插件进行简单的数据映射能力。
　　4。路由能力
　　对于路由能力来说，API网关一般会提供简单的路由能力，比如通过Url里面传递的关键参数进行路由，但是无法支撑基于消息报文里面的内容进行路由。API网关替代ESB的可行性分析
　　API网关替代ESB，简单来说就是需要在API网关上扩展欠缺的能力，这样原有注册在ESB总线上的接口服务才能够做到平滑迁移。
　　对于API网关对ESB的替换个人核心观点如下：
　　即不对API网关引擎本身进行大量的代码定制，而是应该将欠缺的能力作为代理组件或插件方式实现并最终和API网关融合为一个整体。
　　基于这个思路进行分析如下。
　　数据库适配和协议转换能力
　　对于这部分能力，最佳做法即是将其移出到API快速开发平台或组件里面，即在该组件里面完成对数据库的适配，协议转换等动作，最终形成一个HttpRestAPI接口再注册和接入到API网关。也就是说API快速开发平台即是API网关的一个关键外挂。
　　消息中间件集成和适配
　　在传统的SOAPWS接口服务实施里面，我们做了一个关键的事情。
　　即JMS消息集成将其分解为两部，对于JMS消息的发送能力，通过JMS消息适配最终转换为一个SOAPWS接口服务。该接口服务在获取到消息后再将消息写入到消息中间件。
　　但是对于消息的订阅，由于要保留消息中间本身的消息持久化，一致性，重视，消息1对多发布订阅能力，我们仍然保留了传统的JMS消息订阅机制。但是这种机制本身会走TCP协议接口，在订阅端也存在要安装相应的消息中间件代理SDK包。整体来说还是存在一定的耦合性，特别是消息中间件一些能力要进行变更的时候，往往涉及到订阅端也需要修改。
　　在API网关集成下，引入一个开源的消息中间件来弥补异步消息集成是必须的。对应消息中间件介绍可以参考我以前发布过的相关文章。
　　在消息中间件引入后，可以将消息发布能力封装适配后形成一个HttpRestAPI接口暴露。但是对于订阅能力，个人希望是不再通过消息中间件本身的订阅机制。
　　而是在各个订阅端提供HttpRestAPI的导入数据接口服务，由代理组件来完成消息的发布和定义工作。也就是说不再是订阅端去监听消息的变化，而是代理组件在获取到数据后根据消息订阅情况主动分发。
　　对于SOAPWS接口服务的支持
　　由于当前API网关基本都是基于HttpRestAPI接口注册接入进行设计，因此对传统的SOAPWS接口服务的支持能力很弱。
　　个人想法是实现一个单独的代理和转换组件来进行SOAPWS的处理，在这个组件里面可以将SOAPWS接口转换为HttpRestAPI接口服务。也可以对SOAPWS进行新的数据拦截和报文解析，并进行相应的安全访问控制，路由格式转换等操作。
　　当然对于SOAPWS接口服务本身也不是必须转换为HttpRest接口再注册到API网关。这类遗留服务可以直接接入到API网关，但是本质是一种代理透传的模式。在这种模式下，所有管控能力，转换能力，路由能力等都需要外挂插件来解决。
　　那么外挂插件基本实现了一个小型的ESB总线该有的能力，如何保证外挂插件本身的可靠性和性能本身又成为一个关键问题。
　　基于内容动态路由支持
　　API网关可以根据Url地址参数信息进行简单路由，但是基于内容的动态路由实际支撑得并不好。在传统ESB总线实施中，我们可以根据消息头，根据输入消息报文内容中关键字段信息进行动态路由，包括在路由处理前还进行相关的安全访问和权限判断。
　　实际这些在API网关当前并不支持。
　　前面已经提到一种做法即在接口服务消费前进行代理组件拦截，还有一种做法则是单独在开发一个路由服务，在该服务里面来实现动态基于内容的路由能力。
　　初步思考总结
　　如果仅仅是SOAP和Rest接口转换，数据库适配，代理路由等替换，采用API网关插件方式完全可以实现。但是如果对于SOAPWS服务注册接入，安全管控完整能力的实现，要在API网关上面进行定制和调整，其工作量不小于单独实现一个小的SOAPWS服务集成的ESB总线能力，这个实际还需要进一步论证实现的可行性。