前言
近来，在想着重构一个新的产品。准备采用微服务的技术解决方案，来搭建基础设施框架。网关，是一个必不可少的组件。那么，网关到底是什么？
其又有什么特点或者特性，成为微服务必不可少的组件呢？今天，我们就来探讨下这个问题。希望通过本文，大家能够明白，为何用。
演变过程
传统的单体技术架构，所有的内容，被打包进一个包内。为了保证，系统的稳定、安全，需要开发一些过滤器、拦截器，来实现对客户端请求的过滤与拦截，以及完成最终请求的转发。如下图所示
微服务技术解决方案下，同样需要为每个服务开发过滤器、拦截器来进行请求管理。但由于服务数量众多，同时，客户端形式多样化，如果在每个服务身上开发，将会造成很大的代码冗余与开发负担。因此，期待，将相同的一些功能，抽取到一个服务内实现，这便成为了一个组件，就是现在的网关。
网关存在的原因：
- 解决微服务技术架构下，请求管理功能
- 解决微服务技术架构下，多客户端的适配，采用单一入口，完成协议适配
网关的基本功能
微服务技术解决方案下的，网关，至少需要具备图示基本功能。
- 网关作为单点入口，完成统一的请求管理
- 免去客户端直接对接众多微服务的复杂性，采用单点入口，实现路由转发，从而实现服务调用
- 服务对于整个系统来讲，是不稳定的，那么网关，需要进行限流熔断，保持系统的稳定与分区容错性
- 对于服务调用的链路，网关有职责进行记录，日志监控，保证整个系统，在监控下工作
- 系统可能不仅仅是由自有客户端调用，很多时候，系统开放能力API给外部，因此网关需要安全认证，来保证安全
这些年来，API网关正在经历一些身份危机。
- 它们是否是集中的、共享的资源，从而促进了API对外部实体的暴露与治理？
- 它们是集群入口（ingress）哨兵，从而可以严格控制哪些用户流量进入或离开集群吗？
- 或者它们根据自己拥有的客户端类型，使用某种API结合胶水来更简洁地表达API？
- 当然，房间里的大象和我经常听到的一个问题：“服务网格会使API网关过时吗？
房间里的大象：英语习语，指的是一些虽然显而易见，但却由于可能造成尴尬、争执、触及敏感或禁忌等原因被人刻意忽视的事情。
一些背景
随着技术发展日新月异，整个行业通过技术和架构模式进行快速洗牌，如果你说“所有这些都使我头大”，也可以理解。在本文中，我希望总结出“ API网关”的不同身份，阐明公司中的哪些群体可以使用API网关（他们正在尝试解决的问题），并重新关注这些首要原则。理想情况下，在本文结束时，您将更好地了解API基础架构在不同层级、对不同团队的作用，同时明白如何从每个层级获得最大价值。
在深入探讨之前，让我们先明确API一词的含义。
我对API的定义：
一个明确定义和目的型接口，通过网络调用，使软件开发人员能够以受控且方便的方式，对组织内的数据和功能进行编程访问。
这些接口抽象了实现它们的技术架构细节。对于这些设计的网络端点，我们希望获得一定程度的文档、使用指南、稳定性和向后兼容性。
相反，仅仅因为我们可以通过网络与另一软件进行通信，并不一定意味着远程端点就是符合此定义的API。许多系统相互通信，但是通信发生更加随意，并在与耦合和其他因素之间进行权衡。
我们创建API来为业务的各个部分提供周全的抽象，以实现新的业务功能以及偶然的创新。
在谈论API网关时，首先要提到的是API管理。
API管理
许多人从API管理的角度考虑API网关。这是公平的。但是，让我们快速看一下此类网关的功能。
通过API Management，我们试图解决“何时公开现有的API供他人使用”的问题，如何跟踪谁使用这些API，实施关于允许谁使用它们的政策，建立安全流程来进行身份验证和授权许可，同时创建一个服务目录（该目录可在设计时使用以促进API使用，并为有效治理奠定基础）。
我们想解决“我们拥有要与他人共享，但要按我们的条款共享这些现有的、经过精心设计的API ”的问题。
API管理也做得很好，它允许用户（潜在的API使用者）进行自助服务，签署不同的API使用计划（请考虑：在给定时间范围内，在指定价格点上，每个端点每个用户的调用次数）。有能力完成这些管理功能的基础架构就是网关（API流量所经过的）。在网关层，我们可以执行身份验证，速率限制，指标收集，其它策略执行等操作。
API Management Gateway
基于API网关的API管理软件示例：
- Google Cloud Apigee
- Red Hat 3Scale
- Mulesoft
- Kong
在这个级别上，我们考虑的是API（如上定义）是如何最好地管理和允许对其进行访问。我们不是在考虑服务器，主机、端口、容器甚至服务（另一个定义不明确的词）。
API管理（以及它们相应的网关）通常被作为由“平台团队”、“集成团队”或其它API基础架构团队所拥有的、严格控制的共享基础架构。
需要注意的一件事：我们要小心，别让任何业务逻辑进入这一层。如前一段所述，API管理是共享的基础结构，但是由于我们的API流量经过了它，因此它倾向于重新创建“大包大揽的全能型”（认为是企业服务总线）网关，这会导致我们必须与之协调来更改我们的服务。从理论上讲，这听起来不错。实际上，这最终可能成为组织的瓶颈。有关更多信息，请参见这篇文章：具有ESB，API管理和Now…Service Mesh的应用程序网络功能？
集群入口
为了构建和实现API，我们将重点放在代码、数据、生产力框架等方面。但是，要想使这些事情中的任何一个产生价值，就必须对其进行测试，部署到生产中并进行监控。当我们开始部署到云原生平台时，我们开始考虑部署、容器、服务、主机、端口等，并构建可在此环境中运行的应用程序。我们可能正在设计工作流（CI）和管道（CD），以利用云平台快速迁移、更改、将其展示在客户面前等等。
在这种环境中，我们可能会构建和维护多个集群来承载我们的应用程序，并且需要某种方式来访问这些群集中的应用程序和服务。以Kubernetes为例思考。我们可能会通过Kubernetes Ingress来访问Kubernetes集群（集群中的其它所有内容都无法从外部访问）。这样，我们就可以通过定义明确的入口点（例如域/虚拟主机、端口、协议等），严格控制哪些流量可以进入（甚至离开）我们的集群。
在这个级别上，我们可能希望某种“ingress网关”成为允许请求和消息进入群集的流量哨兵。在这个级别上，您的思考更多是“我的集群中有此服务，我需要集群外的人能够调用它”。这可能是服务（公开API）、现有的整体组件、gRPC服务，缓存、消息队列、数据库等。有些人选择将其称为API网关，而且实际上可能会做比流量的入口/出口更多的事情，但重点是这个层级的问题是属于集群操作级别的。
Cluster Ingress Gateway
这些类型的ingress实现的示例包括：Envoy Proxy 及其基础上的项目包括：
- Datawire Ambassador
- Solo.io Gloo
- Heptio Contour
基于其他反向代理/负载均衡器构建的其它组件：
- HAProxy
- OpenShift’s Router (based on HAProxy)
- NGINX
- Traefik
- Kong
此层级的集群入口控制器由平台团队操作，但是，这部分基础架构通常与更加去中心化的、自助服务工作流相关联（正如您对云原生平台所期望的那样）。参见The “GitOps” workflow as described by the good folks at Weaveworks
API网关模式
关于“ API网关”一词的另一种扩展是我在听到该术语时通常想到的，它是与API网关模式最相似的。Chris Richardson在其“微服务模式”一书第8章很好地介绍了这种用法。我强烈建议您将此书用于此模式和其他微服务模式学习资料。可在他的microservices.io网站API Gatway Pattern可以进行快速浏览。简而言之，API网关模式是针对不同类别的消费者来优化API的使用。这个优化涉及一个API间接访问。您可能会听到另一个代表API网关模式的术语是“前端的后端”，其中“前端”可以是字符终端（UI）、移动客户端、IoT客户端甚至其它服务/应用程序开发人员。
在API网关模式中，我们明显简化了一组API的调用，以模拟针对特定用户、客户端或使用者的“应用程序”内聚API。回想一下，当我们使用微服务构建系统时，“应用程序”的概念就消失了。API网关模式有助于恢复此概念。这里的关键是API网关，一旦实现，它将成为客户端和应用程序的API，并负责与任何后端API和其他应用程序网络端点（不满足上述API定义的端点）进行通信。
与上一节中的Ingress控制器不同，此API网关更接近开发人员的视角，而较少关注哪些端口或服务暴露以供集群外使用的方面。此“ API网关”也不同于我们管理现有API的API管理视角。此API网关将对后端的调用聚合在一起，这可能会公开API，但也可能是与API描述较少的东西，例如对旧系统的RPC调用，使用不符合“ REST”的协议的调用（如通过HTTP但不使用JSON），gRPC，SOAP，GraphQL、websockets和消息队列。这种类型的网关也可用来进行消息级转换、复杂的路由、网络弹性/回退以及响应的聚合。
如果您熟悉REST API的Richardson Maturity模型，就会发现相比Level 1–3，实现了API网关模式的API网关来集成了更多的Level 0请求（及其之间的所有内容）。
https://martinfowler.com/articles/richardsonMaturityModel.html
这些类型的网关实现仍需要解决速率限制、身份验证/授权、断路、度量收集、流量路由等问题。这些类型的网关可以在集群边缘用作集群入口控制器，也可以在集群内部用作应用程序网关。
API Gateway Pattern
此类API网关的示例包括：
- Spring Cloud Gateway
- Solo.io Gloo
- Netflix Zuul
- IBM-Strongloop Loopback/Microgateway
也可以使用更通用的编程或集成语言/框架（例如：
- Apache Camel
- Spring Integration
- Ballerina.io
- Eclipse Vert.x
- NodeJS
由于这种类型的API网关与应用和服务的开发紧密相关，因此我们希望开发人员能够参与帮助指定API网关公开的API，了解所涉及的任何聚合逻辑以及快速测试和更改此API基础架构的能力。我们还希望运维人员或SRE对API网关的安全性、弹性和可观察性配置有一些意见。这种层级的基础架构还必须适应不断发展的、按需的、自助服务开发人员工作流。可以通过查看GitOps模型获取更多这方面信息。
进入服务网格(Service Mesh)
在云基础架构上运行服务架构的一部分难点是，如何在网络中构建正确级别的可观察性和控制。在解决此问题的先前迭代中，我们使用了应用程序库和希望的开发人员治理来实现此目的。但是，在大规模和多种开发语言环境下，服务网格技术的出现提供了更好的解决方案。服务网格通过透明地实现为平台及其组成服务带来以下功能：
- 服务到服务（即东西向流量）的弹性
- 安全性包括最终用户身份验证、相互TLS、服务到服务RBAC / ABAC
- 黑盒服务的可观察性（专注于网络通信），例如请求/秒、请求延迟、请求失败、熔断事件、分布式跟踪等
- 服务到服务速率限制，配额执行等
精明的读者会认识到，API网关和服务网格在功能上似乎有所重叠。服务网格的目的是通过在L7透明地解决所有服务/应用程序的这些问题。换句话说，服务网格希望融合到服务中（实际上它的代码并没有嵌入到服务中）。另一方面，API网关位于服务网格以及应用程序之上（L8？）。服务网格为服务、主机、端口、协议等（东西向流量）之间的请求流带来了价值。它们还可以提供基本的集群入口功能，以将某些此功能引入南北向。但是，这不应与API网关可以带来北/南流量的功能相混淆。（一个在集群的南北向和一个是在一组应用程序的南北向）
Service Mesh和API网关在某些方面在功能上重叠，但是在它们在不同层面互补，分别负责解决不同的问题。理想的解决方案是将每个组件（API管理、API网关、服务网格）合适的安置到您的解决方案中，并根据需要在各组件间建立良好的边界（或在不需要时排除它们）。同样重要的是找到适合去中心化开发人员和运营工作流程的这些工具实现。即使这些不同组件的术语和标识存在混淆，我们也应该依靠基本原理，并了解这些组件在我们的体系结构中带来的价值，从而来确定它们如何独立存在和互补并存。
微服务不能没有网关，就如同 Java 程序员不能没有IDEA、Eclipse。为什么呢？
之所以网关对微服务这么重要，主要有以下几点原因：
1. 解决 API 放哪里的问题
要知道，采用微服务架构的系统本身是由很多的独立服务单元组合起来的。而客户端要调用系统，则必须通过系统提供的各种对外开放的 API 来实现。
问题来了，这些 API 要放在哪里呢？直接放在组成系统的服务单元上行不行？
比如，在一套电商系统上，关于订单相关的 API ，放在组成订单服务的服务单元上；风控服务的 API ，放在组成风控服务的服务单元上。
好，咱们假设有这么一个场景，有一位用户想在这套电商系统上查看下商品详情。那么，这个查看商品详情的操作，就可能：
- 调用商品服务的 API 获取商品描述
- 调用评价服务的 API 获取相关评价
- 调用商家服务的 API 获取商家信息
- 调用礼券服务的 API 获取相关礼券
- ……
可以看到，就这么一个商品查看操作，就可能会调用许多服务的 API。
那这些 API 如果全部分散到各个服务单元上，供客户端调用，像查看商品这么简单的一次操作，客户端就可能需要远程访问好几次甚至十几次服务器。
微服务自己又讲究把 API 的粒度划分的很细，也就是说，可能从商品服务上调用商品信息，不止是调用一次商品服务就够了，很可能需要多次对商品服务的不同 API 进行调用，才能获取到足够的数据。
这样一来，客户端需要访问服务器的次数就更多了，可能十几次都不够，得几十次。
这种多次访问服务器的行为，会极大延迟客户端的界面响应时间，很不现实。
所以，把 API 放到各个业务相关的服务单元上，看上去问题很大。
那为什么引入网关就能解决这个问题呢？
因为引入网关，就相当于在客户端和微服务之间加了一层隔离。通常，网关本身会和各个服务单元处于同一个机房，这样，客户端做业务操作的时候，只需要访问一次网关。然后剩下的事情，再由网关分别访问同在一个机房的不同的服务，再把拿到的数据统一在网关封装好，返回给客户端就好。
2. 解决边缘功能集成的问题
在一套微服务组成的系统里，除了必须的业务功能以外，还有为了系统自身的健壮与安全，以及微服务本身的管理，而必须引入的一些非业务功能。对于这些非业务又很重要的功能，我们统称为边缘功能。
还是拿电商系统为例，我们来看一些重要的边缘功能。
假设因为我们做了一次非常大的促销活动，导致流量过大，系统承载不了了。此时，为了保证系统本身的稳定，我们就需要把一些承载不了的流量给通过各种手段消化掉，一般的做法有三种：
- 限流：通过令牌桶等算法，把一些额外的流量挡在系统外面，不让其访问。
- 降级：由于系统可能已经过载了，此时，我们就放弃处理一些服务和页面的请求或者仅简单处理，比如直接返回一个报错。
- 熔断：有些时候，系统过载过度或者上线出了 bug，降级都解决不了问题。比如，缓存失效了，导致大量请求频繁访问了数据库，而这种频繁访问数据库可能造成了大量的 IO 操作，结果又去影响了数据库所在的操作系统，同时，这个操作系统上又有着别的重要服务，直接也被影响了。对于这种连锁反应，我们称之为雪崩。而为了防止雪崩，我们就会坚决把缓存失效导致数据库被频繁访问的服务给停掉，这就是熔断。
可以看到，像限流、降级、熔断这些系统保障策略，最合适的地方应该是有一个集中的请求入口点，就像古时候，老百姓进城需要过城门那样。
当系统出现问题的时候，直接就在这个入口点做相应的操作即可。
- 限流，就直接在这个入口点限制后续请求。
- 降级，就直接在这个入口点判断请求想要访问的服务或者页面，直接报错返回。
- 熔断，就直接在这个入口点，断开所有访问特定服务的请求连接，然后再把后继对特定服务的访问，也统统拦在门外。
在电商系统里，有很多特殊场景的接口，需要受到严格的限制。
比如，支付接口，访问它就需要认证和权限控制。又比如，对于系统的访问，有时候不能让国外的去访问国内的网站，这就需要限制客户端的访问 IP，所以系统还需要认证和授权功能。
那这种认证和授权也最合适放在请求的一个集中入口点，统一实现。
还记得上面咱们说过的网关的 API 统一存放吗？我们只需要对这些 API 做对应的权限设置，当请求访问特殊场景接口的时候，必定会通过 API 访问。所以，限制接口的访问，本质上就是对特定 API 的限制，那么，放在网关再合适不过了。
现实里，我们有时候需要把线上的流量镜像出来，转发到灰度环境，利用这些镜像出来的流量既可以用于小范围测试，又可以更好的评估系统所能承载的最大吞吐量，也因此，系统需要有一个统一入口做分流。
可以看到，无论是系统需要的保障策略，认证授权，还是流量分流等功能，都应该放到一个统一的请求入口处才能得到最好的实现。网关恰好就承担了这么个统一请求入口的角色。
所以，对于微服务中，林林总总的边缘功能，往往会通过插件的形式，集成在 API 网关中。
3. 解耦了客户端和后端微服务
一套项目，在使用微服务模式的初期，往往后端变化是十分频繁的。
频繁变化的原因有很多，像业务领域划分不合适啊，像某个业务模块急速膨胀啊，都可能导致后端微服务的剧烈变化。
在这种情况下，如果没有网关，很可能就会出现客户端需要被迫随着后端的变化而变化的情况。
比如，在电商系统里，初期我们很可能会把风控服务做的非常小。随着业务的发展，风控服务越来越庞大，此时，风控服务就可能被分解为决策引擎和分析中心等更多更细的服务。
在电商里，风控往往是下单、支付等操作的必要前置操作。如果没有网关去分隔开客户端和微服务，客户端直接和风控服务打交道，那么风控服务拆分，API 必然不会稳定，API 的变化，自然会引发调用 API 客户端代码的变化。
有了网关之后，情况就好了很多了。当风控服务本身频繁变化的时候，我们只需要改动网关的代码就好。而服务器代码的升级可是远远要比客户端代码的升级容易太多了。
参考链接：https://juejin.cn/post/6918211351257022471
jianshu.com/p/9fab0982c6bb
