导读
之前提过要做一个 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 网关的技术已经几于成熟，在合适的场景下合理的运用将会发挥极大的作用。
原文地址：http://dockone.io/article/2434561
声明： 猿站网有关资源均来自网络搜集与网友提供，任何涉及商业盈利目的的均不得使用，否则产生的一切后果将由您自己承担！ 本平台资源仅供个人学习交流、测试使用 所有内容请在下载后24小时内删除，制止非法恶意传播，不对任何下载或转载者造成的危害负任何法律责任！也请大家支持、购置正版！ 。本站一律禁止以任何方式发布或转载任何违法的相关信息访客发现请向站长举报，会员发帖仅代表会员个人观点，并不代表本站赞同其观点和对其真实性负责。本网站的资源部分来源于网络，如有侵权烦请发送邮件至：2697268773@qq.com进行处理。