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

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。