使用API??网关替代传统ESB总线适配、协议转换、消息拦截等能力进行各种SOA治理和控制操作的可行性分析。那么，在传统企业IT架构改造过程中，如果ESB总线需要升级，或者整体IT架构本身存在旧架构与新微服务架构并存的融合场景。在这种情况下，用传统的方式升级ESB总线显然是不合适的。最好的办法是考虑ESB总线是否可以被API网关替代。API网关概述在微服务架构系统中，我们一般会使用微服务网关或者API网关。大家都知道微服务架构体系本身就是一个去中心化的架构，服务注册中心是用来实现服务注册发现和消费调用的，那为什么还要用API网关呢？在使用传统ESB总线进行服务集成时，我们经常会讲到一个位置透明的概念，即需要屏蔽底层业务模块提供API接口服务地址信息，实现多个微服务API接口的统一出口。即类似于设计模式中经常提到的门面模式。如何定义API网关？简单的说，API网关就是把微服务提供的所有API接口服务能力汇集起来，统一接入管理。也是通过统一拦截，通过网关实现API接口。安全、日志、限流和断路器等常见需求。简单来说，几个关键的能力都是通过网关来实现的。内部微服务的位置对外部访问是透明的。外部应用只需要与网关进行交互，统一拦截接口服务即可实现安全、日志、限流、熔断等需求。从这里，我们可以看到传统架构中的API网关和ESB。总线类似，这些关键能力也是ESB服务总线的能力。但是由于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快速开发平台或组件中，即在组件中完成数据库适配、协议转换等动作，最终形成一个Http的RestAPI接口然后被注册并连接到API网关。也就是说，API快速开发平台是API网关的关键插件。消息中间件的集成和适配在传统SOAPWS接口服务的实现中，我们做了一件很关键的事情。即JMS消息集成将其分解为两步。对于JMS消息的发送能力，通过JMS消息适配最终转化为SOAPWS接口服务。接口服务获取消息后，将消息写入消息中间件。但是对于消息订阅，我们还是保留了传统的JMS消息订阅机制，因为我们需要保留消息本身的消息持久化、一致性、注意力以及1对多的发布订阅能力。但是这种机制本身使用的是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总线能力，这其实还需要进一步论证实现的可行性。
