（​）网关是什么？网关的基本功能解决方案

前言

最近，我一直在考虑重建一个新产品。 准备使用微服务技术方案来构建基础架构。 网关是必不可少的组件。 那么，网关到底是什么？

它具有哪些特征或特性使其成为微服务的重要组成部分？ 今天，我们就来讨论一下这个问题。 希望通过这篇文章，大家能够明白为什么要使用它。

进化

在传统的单体技术架构中，所有内容都被打包到一个包中。 为了保证系统的稳定性和安全性，需要开发一些过滤器和拦截器来过滤和拦截客户端请求，完成最终请求的转发。如下所示

​

在微服务技术方案下，还需要为每个服务开发过滤器和拦截器来进行请求管理。 但由于服务数量众多，客户端形态多样化，在每个服务上进行开发会造成大量的代码冗余和开发负担。 因此，期望将一些相同的功能提取到一个服务中并实现，成为一个组件，也就是现在的网关。

网关存在的原因：

网关的基本功能

​

微服务技术方案下，网关至少需要具备图中所示的基本功能。

网关作为单一入口点来完成统一的请求管理。

消除了客户端直接连接众多微服务的复杂性，采用单点入口实现路由转发，实现服务调用。

整个系统的服务不稳定，因此网关需要进行限流和熔断，以维持系统的稳定和分区容错。

对于服务调用链路，网关负责记录和日志监控，保证整个系统在监控下工作。

该系统不仅可以由其自己的客户端调用。 很多情况下，系统对外开放能力API，因此网关需要安全认证来保证安全。

多年来，API 网关经历了一些身份危机。

in the room（房间里的大象）：一个英语习语，指的是虽然显而易见但被故意忽视的事情，因为它可能会导致尴尬、争论、触及敏感或禁忌。

一些背景

随着技术的飞速发展，整个行业通过技术和架构模式快速洗牌，如果你说“这一切都让我头晕”也是可以理解的。 在这篇文章中，我希望总结一下“API网关”的不同身份，明确公司中的哪些群体可以使用API​​网关（他们试图解决的问题），并重新关注这些首要原则。 理想情况下，读完本文后，您将更好地了解 API 基础设施在不同层和不同团队中的作用，以及如何从每一层获得最大价值。

在深入探讨之前，我们先澄清一下 API 一词的含义。

我对API的定义：

一个定义明确且有目的的接口，通过网络调用，使软件开发人员能够以受控且方便的方式以编程方式访问组织内的数据和功能。

这些接口抽象了其实现的技术架构细节。 对于这些设计的网络端点，我们期望有一定水平的文档、使用指南、稳定性和向后兼容性。

相反，仅仅因为我们可以通过网络与另一个软件进行通信，并不一定意味着远程端点是满足此定义的 API。 许多系统相互通信，但通信的发生更加随意，并且是耦合和其他因素的权衡。

我们创建 API 来为业务的各个部分提供深思熟虑的抽象，以实现新的业务功能以及偶然的创新。

说到API网关，首先要提到的就是API管理。

API管理

许多人从 API 管理的角度来考虑 API 网关。 这还算公平。 但让我们快速了解一下此类网关的功能。

通过API，我们试图解决“何时公开现有的API供其他人使用”的问题，如何跟踪谁使用这些API，实施允许谁使用它们的策略，建立安全流程来验证和授权权限，同时创建服务目录（可以在设计时使用，以促进 API 使用并为有效治理提供基础）。

我们想要解决“我们拥有这些现有的、设计良好的 API，我们希望与其他人共享，但我们希望按照我们的条件共享它们。”

API 管理也做得很好，它允许用户（潜在的 API 消费者）进行自助服务，注册不同的 API 使用计划（想想：每个端点每个用户的调用次数）。 能够完成这些管理功能的基础设施就是网关（API流量经过的地方）。 在网关层，我们可以执行身份验证、速率限制、指标收集、其他策略执行等。

​

应用程序编程接口

基于API网关的API管理软件示例：

在此级别，我们考虑如何最好地管理 API（如上定义）并允许对其进行访问。 我们没有考虑服务器、主机、端口、容器甚至服务（另一个定义不明确的词）。

API 管理（及其相应的网关）通常被视为“平台团队”、“集成团队”或其他 API 基础设施团队拥有的严格控制的共享基础设施。

需要注意的一点是：我们需要小心，不要让任何业务逻辑进入这一层。 正如上一段所述，API 管理是一个共享基础设施，但由于我们的 API 流量经过它，它往往会重新创建“大包罗万象”（想想企业服务总线）网关，这将导致我们的服务发生变化必须配合。 从理论上讲，这听起来很棒。 事实上，这最终可能成为组织的瓶颈。 有关更多信息，请参阅本文：ESB 的应用程序网络功能、API 管理和现在……网格？

集群入口

为了构建和实现 API，我们专注于代码、数据、生产力框架等。 然而，要使这些东西变得有价值，就必须对其进行测试、部署到生产中并进行监控。 当我们开始部署到云原生平台时，我们开始考虑部署、容器、服务、主机、端口等，并构建可以在该环境中运行的应用程序。 我们可能正在设计工作流程 (CI) 和管道 (CD)，以利用云平台快速迁移、更改、将其呈现在客户面前等。

在这个环境中，我们可能会构建和维护多个集群来托管我们的应用程序，并且需要某种方式来访问这些集群中的应用程序和服务。 将其视为一个例子。 我们可以通过以下方式访问集群（集群中的其他所有内容都无法从外部访问）。 这样我们就可以通过明确定义的入口点（例如域/虚拟主机、端口、协议等）严格控制哪些流量可以进入（甚至离开）我们的集群。

在这个级别，我们可能希望某种“网关”作为流量哨兵，允许请求和消息进入集群。 在这个级别上，您更多地思考“我的集群中有此服务，我需要集群外的人能够调用它”。 这可以是服务（公共 API）、现有的整体组件、gRPC 服务、缓存、消息队列、数据库等。有些人选择将其称为 API 网关，它实际上可能不仅仅是流量的入口/出口，但是要点是，这个级别的问题属于集群操作级别。

​

这些类型的实现示例包括： Envoy Proxy 以及基于它的项目包括：

构建在其他反向代理/负载均衡器之上的其他组件：

此级别的集群入口控制器由平台团队运营，但是，基础设施的这一部分通常与更加分散的自助服务工作流程相关联（正如您对云原生平台的期望）。 请参阅好人的“”

API网关模式

“API 网关”一词的另一个扩展是我听到该术语时通常想到的，它是与 API 网关模式最相似的一个。 Chris 在他的书《微服务模式》的第 8 章中很好地介绍了这种用法。 我强烈推荐这本书作为本课程和其他微服务模式学习材料。 在他的 .io 网站 API 上可以进行快速浏览。 简而言之，API网关模式针对不同类别的消费者优化了API的使用。 此优化涉及 API 间接。 您可能听到的代表 API 网关模式的另一个术语是“前端的后端”，其中“前端”可以是字符终端 (UI)、移动客户端、物联网客户端甚至其他服务/应用程序开发人员。

在 API 网关模式中，我们显着简化了对一组 API 的调用，以模拟针对特定用户、客户端或消费者的“应用程序”内聚 API。 回想一下，当我们使用微服务构建系统时，“应用程序”的概念就消失了。 API 网关模式有助于复兴这一概念。 这里的关键是API网关，它一旦实现，就成为客户端和应用程序的API，并负责与任何后端API和其他应用程序网络端点（不满足上述API定义的端点）进行通信。

与上一节中的控制器不同，此 API 网关更接近开发人员的视角，不太关心暴露哪些端口或服务以供集群外部使用。 这个“API网关”也和我们管理现有API的API管理角度不同。 此 API 网关聚合对后端的调用，这可能会公开 API，但也可能比 API 缺乏描述性，例如对旧系统的 RPC 调用、使用不符合“REST”的协议的调用（例如通过 HTTP 但不兼容） JSON）、gRPC、SOAP 和消息队列。 这种类型的网关还可用于消息级转换、复杂路由、网络弹性/回退和响应聚合。

如果您熟悉 REST API 模型，您会注意到实现 API 网关模式的 API 网关集成了比 1-3 级更多的 0 级请求（以及介于两者之间的所有内容）。

​

//del.html

这些类型的网关实现仍然需要解决速率限制、身份验证/授权、熔断、指标收集、流量路由等问题。这些类型的网关可以用作集群边缘的集群入口控制器，也可以用作集群内部的应用程序网关集群。

​

应用程序编程接口

此类 API 网关的示例包括：

还可以使用更通用的编程或集成语言/框架（例如：

由于此类 API 网关与应用程序和服务的开发密切相关，因此我们希望开发人员参与帮助指定 API 网关公开的 API，了解所涉及的任何聚合逻辑，并有能力快速测试和更改此 API 网关。 API 基础设施。 我们也希望运营人员或SRE能够对API网关的安全性、弹性和可观察性配置提供一些意见。 这一层基础设施还必须适应不断发展的、按需的、自助服务的开发人员工作流程。 您可以通过查看模型获得更多信息。

进入服务网格（Mesh）

在云基础设施上运行服务架构的部分困难在于在网络中构建适当级别的可观察性和控制性。 在之前解决此问题的迭代中，我们使用应用程序库并希望开发人员治理来实现这一目标。 然而，服务网格技术的出现在大规模、多种开发语言环境下提供了更好的解决方案。 服务网格通过透明实施为平台及其组成服务带来以下功能：

精明的读者会意识到 API 网关和服务网格在功能上似乎有重叠。 服务网格的目的是在 L7 透明地解决所有服务/应用程序的这些问题。 换句话说，服务网格希望集成到服务中（其代码实际上并未嵌入到服务中）。 另一方面，API 网关位于服务网格和应用程序之上（L8？）。 服务网格为服务、主机、端口、协议等之间的请求流（东西向流量）带来价值。 它们还可以提供基本的集群入口功能，以将其中一些功能带入南北方向。 但是，这不应与 API 网关带来北/南流量的能力相混淆。 （集群中一个南北向，一组应用程序中一个南北向）

Mesh 和 API 网关在功能上在某些方面存在重叠，但它们在不同层面上相互补充，并负责解决不同的问题。 理想的解决方案是将每个组件（API 管理、API 网关、服务网格）适当地放置到您的解决方案中，并根据需要在组件之间建立良好的边界（或在不需要时排除它们）。 找到适合分散式开发人员和操作工作流程的这些工具的实现也很重要。 即使这些不同组件的术语和标识存在混淆，我们也应该依靠基本原理并理解这些组件为我们的架构带来的价值，以确定它们如何独立存在并相互补充。

微服务不能没有网关，就像 Java 程序员不能没有 IDEA 一样。 为什么？

网关对于微服务如此重要的主要原因如下：

1.解决API放在哪里的问题

要知道采用微服务架构的系统本身是由很多独立的服务单元组成的。 客户端如果想要调用系统，必须通过系统提供的各种开放API来进行。

问题是，这些API应该放在哪里呢？ 可以直接放在组成系统的服务单元上吗？

例如，在电商系统中，与订单相关的API放在组成订单服务的服务单元上； 风控服务的API放置在构成风控服务的服务单元上。

​

好吧，我们假设有一个场景，用户想要在这个电子商务系统上查看产品详细信息。 那么，该查看商品详情的操作可以：

​

可以看到，光是这样一个商品查看操作就可能会调用很多服务的API。

如果这些API都分散到各个服务单元供客户端调用，那么像查看产品这样简单的操作，客户端可能需要远程访问服务器几次甚至十几次。

微服务本身也注重将API的粒度划分得很细。 换句话说，可以从产品服务中调用产品信息。 不仅仅调用一次产品服务就够了，很可能需要多次调用产品服务的不同API。 ，以获得足够的数据。

这样，客户端需要访问服务器的次数就会增多。 也许十几次还不够，而是几十次。

这种多次访问服务器的行为会大大延迟客户端的接口响应时间，这是非常不现实的。

因此，将API放到各个业务相关的服务单元上似乎是一个大问题。

那么为什么引入网关就能解决这个问题呢？

因为网关的引入相当于在客户端和微服务之间增加了一层隔离。 通常，网关本身将与每个服务单元位于同一机房。 这样客户端在进行业务操作时只需访问网关一次。 那么剩下的工作就是由网关访问同一个机房​​的不同服务，然后将获取到的数据封装在网关中返回给客户端。

​

2.解决边缘功能集成问题

在一个由微服务组成的系统中，除了必要的业务功能外，为了系统本身的健壮性和安全性，以及微服务本身的管理，还必须引入一些非业务功能。 对于这些非业务但非常重要的功能，我们统称为边缘功能。

我们以电子商务系统为例。 让我们看一些重要的边缘函数。

假设因为我们举办了一个非常大的促销活动，流量太大，系统无法承受。 这时，为了保证系统本身的稳定性，我们就需要通过各种手段来消化掉一些无法承载的流量。 一般有以下三种方法：

可见，限流、降级、熔断等系统保护策略最合适的地方就是有一个集中的请求入口点，就像古代人们进城必须经过城门一样。

当系统出现问题时，直接在此入口点执行相应的操作即可。

在电商系统中，有很多特殊场景的接口需要严格限制。

例如，支付接口需要进行身份验证和权限控制才能访问。 再比如，对于系统访问，有时外国人是不允许访问国内网站的，这就需要限制客户端的访问IP，所以系统还需要认证和授权功能。

那么这种认证授权最适合放在请求的一个集中入口点，统一实现。

还记得我们上面所说的网关API统一存储吗？ 我们只需要为这些API设置相应的权限即可。 当请求访问特殊场景接口时，必须通过API访问。 因此，限制接口的访问本质上是对特定API的限制，所以放在网关上是最合适的。

现实中，我们有时需要镜像在线流量并将其转发到灰度环境。 镜像流量可用于小规模测试，更好地评估系统所能承载的最大吞吐量。 因此，系统需要有一个统一的入口进行导流。

可见，无论是保障策略、认证授权，还是系统所需的引流等功能，都应该放在统一的请求入口，才能达到最佳的实现。 网关恰好起到了统一请求入口的作用。

因此，对于微服务来说，各种边缘功能往往以插件的形式集成到API网关中。

3. 解耦客户端和后端微服务

对于一组项目来说，在使用微服务模型的早期阶段，后端的变更往往非常频繁。

频繁变更的原因有很多，比如业务领域划分不当、某个业务模块快速扩展等，都可能导致后端微服务发生剧烈变化。

这种情况下，如果没有网关，很可能客户端需要随着后端的变化而被迫改变。

比如在电商系统中，我们前期很可能把风控服务做得很小。 随着业务的发展，风控服务规模越来越大。 这时，风控服务可能会细分为决策引擎、分析中心等更细化的服务。

在电商中，风险控制往往是下单、支付等操作的必要前提。 如果没有网关将客户端和微服务分开，客户端直接与风控服务交互，那么风控服务就会被割裂，API必然会不稳定。 API的改变自然会导致调用API的客户端代码发生改变。

有了网关，情况就好多了。 当风控服务本身频繁变化时，我们只需要更改网关代码即可。 升级服务器代码比升级客户端代码容易得多。

参考链接：/post/

为什么微服务必须有 API 网关？

/p/

​​

​

微信公众号作者【程序员黄小邪】是前蚂蚁金服Java工程师，专注分享Java技术技巧和求职成长经验，不限于BAT面试、算法、计算机基础、数据库、分布式、全家桶、微服务、高并发、JVM、容器、ELK、大数据等

​