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

落日映苍穹つ 2022-09-10 01:22 170阅读 0赞

**导读：**

之前提过要做一个 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 网关的技术已经几于成熟，**在合适的场景下合理的运用将会发挥极大的作用**。

[ESB]: https://mp.weixin.qq.com/s?__biz=MzIzNzA5NzM3Ng==&mid=2651865941&idx=1&sn=a7c57e0f87b7aea1c5b16d453a890b1b&chksm=f3293b9ac45eb28c99057ba825944f96b6929b9ff8c23f0c7c6439fe0cb0e73d0adee9023a6a&token=1323438406&lang=zh_CN&scene=21#wechat_redirect
[ServiceMesh]: https://mp.weixin.qq.com/s?__biz=MzIzNzA5NzM3Ng==&mid=2651865600&idx=1&sn=a74fa1b0d456225bf8ff6bf3634401e4&scene=21#wechat_redirect