API与ESB 、ServiceMesh、微服务究竟关系如何?

导读:

之前提过要做一个 API 网关的介绍,事实上,无论是微服务、服务网格,还是云原生、数字化的建设,API 网关都是绕不开的话题。介于网上对于 API 网关的介绍参差不齐,所以今天我们不再简单的做 API 网关基础知识与功能介绍,而是直切要点,聊聊 ESB、ServiceMesh、 微服务与 API 网关的关系。

01

API 网关的核心

随着微服务场景的普遍运用,API 网关也逐渐被大家所重视,聚合接口、聚合服务以提供前端调用、业务封装,这是 API 网关的主要场景。

API 网关处于业务内外通信或系统前后端的桥梁,功能上除了建立通信、路由转发以外,也承担了许多非业务的功能,比如安全、流控、过滤、缓存、监控等;在服务化模式下,也会增加一些运营的功能,比如 API 管理、计量计费、服务订阅等等。

可见,在 API 网关上我们可以做很多文章,只因它对流量做了承接和转发,这也是 API 网关的核心。

这样的角色并不陌生,在我之前的两篇文章中提到的 ESB、ServiceMesh 都有借助流量的承接转发功能,然后形成的解决方案。同一件工具,被置于不同的位置,就有其不同的形态,API 网关就是这样的工具。

 

02

API与ESB 、ServiceMesh、微服务的关系

替代ESB的场景

ESB 没必要再做深入的介绍了,其核心也是路由、转发、转换、流控。在当下ESB 逐步退出数字化的舞台的同时,多数企业也在思考如何通过一个替代品逐步替换 ESB,我们博云就在多个项目中分别通过微服务框架、服务网格框架做出过多种平滑接替 ESB 的方案和功能。同时覆盖其原有的路由转发、协议转换、限流控制的功能,最直接的方案就是通过 API 网关实现。

ESB 的架构,同时承担了东西向服务间的访问控制,和南北向流量的控制。而使用了 API 网关的方案就显得更加灵活了,其可大可小的体量、动态配置的灵活特性、自服务的消费模式,都更能符合多变多样化的新型数字架构。如果规划得当,API 网关在替代 ESB 的同时,也可以作为整个网络域内,甚至整个企业级的网关,这也就是服务中台化的第一步。

服务网格中的应用

ServiceMesh 的理念其实很容易理解,通过一个代理服务,将所有的流量接管,同时将非业务的治理、监控等功能,都通过代理服务实现。那么这个代理服务(proxy),就是 API 网关的另一个运用场景。劫持流量,然后加入所需的定制化功能。

与其他场景相比,这里的网关功能上没有太大的变动,但是使用位置却有很大差别。在 ServiceMesh 场景中,网关是一个很小很轻量的代理单元,而每个业务运行单元都会搭载该代理单元共同启动,所以在 ServiceMesh 场景中,通常叫做边车(Sidecar)。也就是说 ServiceMesh 中的 Sidecar 就是一个 API 网关的应用,比如 Istio 框架下,数据面 Sidecar 就是 Envoy(基于C++语言的 API 网关)。

 

微服务网关

值得一提的是微服务场景下的 API 网关,这种场景难道不是最基本的运用吗?其实不然,微服务网关也是对 API 网关的场景化改造后的结果,比如SpringcloudGateway、Zuul 这两种是基于 netty 框架的 Java 语言开发的微服务网关,主要在 Springcloud 微服务的场景下使用。

微服务场景下,服务间通信的寻址都需要依赖于注册中心,微服务网关做路由转发的时候,上游地址也需要从注册中心获取,同时微服务访问网关的时候也可以直接通过注册中心寻址,因此微服务网关需要符合微服务框架的注册与发现机制。

 

03

总结

三种网关核心都是通信的代理和转发,替代 ESB 的时候带上协议转换的特性,对接微服务的时候增加注册中心同步的功能,做为 Sidecar 的时候需要做流量劫持以及控制面的通信。另外还有没提到 API 市场的场景,这种场景就需要补充计量计费等功能了。

 

所以根据不同的使用场景、不同的运用方式,依赖于 API 网关都可以自由调整。在我们博云内部,就至少涉及了三种网关和多种场景的使用。

第一种:企业级的 API 网关,主要注重服务能力的提供,承接全企业的流量,因此对于网关的性能有极高的要求。我们采用的组件是基于openresty+lua 的 kong 来解决,性能上保证全企业的交互压力。

第二种:微服务的网关,主要是微服务的封装,但是不是重点和难点,通过很多个项目的交付发现,微服务的需求容易满足,而过渡方案比较难。所谓过渡方案是指非微服务的应用,在需要与微服务应用统一治理时,通过 API 网关做的 Sidecar 方案。我们博云内部采用的是 SpringcloudGateway,并在其上做协议转换、服务检测等功能,实现对单体应用、传统架构系统的统一纳管和治理。

第三种:服务网格,主要是数据面 Sidecar 部分,与之上的区别是,之上的微服务框架基本已经确定是 Springcloud,而服务网格本在我们博云内部采用的是 Istio 框架,Istio 框架下 Sidecar 采用的是 Envoy 。我们在 Envoy 上拓展 ESB 的场景、传统架构兼容的场景,并增加协议支持、协议转换、数据收集、链路收集等功能,以实现复杂的微服务转型需求。

阵而后战,兵法之常,运用之妙,存乎一心。API 网关的技术已经几于成熟,在合适的场景下合理的运用将会发挥极大的作用。

你可能感兴趣的