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

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

大家都清楚传统的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网关类似一个轻量的只支持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总线能力,这个实际还需要进一步论证实现的可行性。

责任编辑:武晓燕 来源: 人月聊IT
相关推荐

2012-04-12 17:41:02

2009-12-25 14:26:40

无线接入技术集成

2011-04-28 11:04:22

DataReader分页

2009-09-21 16:40:42

Hibernate可行

2009-06-15 09:57:46

HibernateIBatis

2012-04-09 09:39:59

虚拟化桌面虚拟化VDI终端

2011-08-17 13:07:19

无线局域网

2011-06-24 11:35:01

内链

2011-07-05 14:12:06

关键任务虚拟化服务器

2011-07-05 10:37:03

虚拟化VMware

2009-02-17 15:59:55

2011-12-13 20:36:26

Android

2013-08-27 11:15:20

2009-06-12 10:09:17

2014-03-24 15:00:59

2012-10-26 13:48:54

2011-11-14 09:10:08

虚拟化

2020-09-16 09:19:49

数据中心

2011-12-02 09:25:46

2019-10-21 17:17:48

Windows操作系统微软
点赞
收藏

51CTO技术栈公众号