共计 2136 个字符，预计需要花费 6 分钟才能阅读完成。
导读：
之前提过要做一个 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 网关的技术曾经几于成熟，在适合的场景下正当的使用将会施展极大的作用。
