用户您好!请先登录!

微服务是否需要ESB总线

微服务是否需要ESB总线

这是一个很好的问题,也是很容易混淆的一个问题。

首先总结下结论,即微服务架构下有用全部是标准化轻量Http Rest接口,因此不需要比较重的ESB总线产品来集成。但是在需要统一对外暴露能力的时候仍然需要API网关完成(可以将API网关产品理解为ESB总线个一个轻量实现)。

API网关和ESB总线的对比

首先来解释下API网关。

如何给API网关一个定义?

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

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

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

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

下图是一个简单的对比,大家可以参考。

 

微服务架构不再需要ESB,并且一定是去中心化的?

首先看下微服务架构里面确实不需要传统ESB,但是需要一个ESB的轻量实现,即我们说的API网关。因为微服务架构里面都是标准的Http Rest接口,不再存在复杂的遗留接口适配,复杂协议转换等问题。但是我们常说的接口服务代理,统一的安全,日志,流控功能仍然需要。

同时微服务架构内部各个微服务模块间本身是去中心化的。

如果一个微服务架构体系里面的各个模块不需要对外暴露接口服务能力,那么直接走去中心化的服务注册中心进行接口地址注册,发现和点对点调用即可。

但是当我们需要暴露接口服务时,比如统一提供接口API给外部APP使用,那么我们仍然需要使用API网关,也就是前面谈到的ESB总线轻量实现。

因此在传统架构里面系统集成和对外能力暴露都采用ESB。但是到了微服务架构系统内部集成可以走注册中心,对外接口服务暴露才走轻量ESB(API网关)。

即:传统ESB能力 = 新微服务架构下 注册中心能力 + API网关能力。

对于API网关来说,核心就是实现两类能力,一个是对API全生命周期管理能力,包括了API接口的注册,接入,发布,测试,变更和版本管理,下线等。另外一个关键能力就是我们常说的安全,日志,流控方面的能力。

而这些能力最常见的实现方式就是通过插件进行拦截处理,API网关里面的关键对象注意包括了接入系统(微服务),消费系统,注册接入的API接口,发布的Proxy API接口,在代理和原始服务间有一个路由对象。只要有这些最基本的对象就可以实现最简单场景下的服务接入。

而其它所有的扩展可以看到都应该基于插件式方式的扩展,这些插件包括了安全认证类插件,流量控制类插件,日志监控类插件,转换类插件。

因此也可以看到网关已经不再做复杂的适配和协议转换工作。

行走的code
行走的code

要发表评论,您必须先登录