api网关有什么优势（工作几年了API网关还不懂）

API网关就是接口的通道或接口的大门。即便拥有再完善的服务注册与发现机制，客户端也需要对后端服务的各个职责划分，才能知道哪个API应该调用哪个服务。API网关的职责主要有3个：请求路由、请求过滤和服务治理。通过将API网关集成注册中心，我们可以动态地进行服务发现，从而更优雅地完成路由、负载均衡等操作，如图5

◎ API网关的意义

◎ API网关的职责

◎ API网关的缺点

◎ 使用API网关认证身份

◎ API网关技术实战

网关的英文是Gateway，翻译为门、方法、通道、途径。API网关就是接口的通道或接口的大门。要想访问API，就必须通过API网关，为什么要有API网关，这样做有什么作用？带着这些问题，我们来学习本章的内容。

API网关并没有引申含义，通俗来讲，它就是应用系统所有接口的唯一关卡，就像一道门，想要调用到接口，就必须从这扇门进入。为什么要有这样一道门？

在微服务中，服务端被拆分成一组职责单一的微小服务，这样做的好处不再赘述。但我们的服务由少变多，必然会增加系统的复杂度。原先客户端只需关心与一个单体的服务交互即可，现在需要去了解每个服务的具体信息，包括认证规则、主机地址、集群方式等。即便拥有再完善的服务注册与发现机制，客户端也需要对后端服务的各个职责划分，才能知道哪个API应该调用哪个服务。在大型项目中，客户端往往需要花费巨大的工作量来集成这些后端。

设想一下，在一个没有API网关的系统中，前后端调用关系如图5.1所示。

复杂的调用关系让客户端难以维护，光看就觉得很乱。假设我们要开发移动端的代码，调用后端的服务，就需要维护与各个服务的调用关系。服务的个数一旦增加，如系统中有几十个，甚至上百个服务，关系维护起来将花费相当多的时间。最主要的是，前端根本不想关心这些问题，对于前端开发来讲，只想调用可用的接口，这本身是后端服务的架构逻辑，前端会因为这种架构模式变得异常复杂，而且这个复杂度会在每个客户端中重复出现。

同时，认证规则无法复用，图5.1所示为一个商场系统，一般情况下，系统会根据不同的终端设计不同的用户认证规则，如PC端可以通过用户名密码的方式进行用户认证，移动端可以使用手机号加短信验证码的方式进行用户认证，第三方可以通过证书密钥等方式进行用户认证，那么这些认证方式通常都由后端服务来实现。

如果客户端直接调用用户敏感的接口，这些接口所在的服务必须拥有认证的能力才行。换句话说，这些后端服务都需要实现多套用户认证的逻辑，并且还需要根据不同终端的请求使用不同的认证方式。

为了使微服务更加通用，后端服务的代码中就必然会被耦合上一些客户端的判断逻辑，因而显得不够单纯，再者每个服务都存在着大量重复的认证逻辑，一旦有些客户端的认证方式发生变化，就需要去维护每个服务中的认证代码，如图5.2所示。

前端受到后端架构的“污染”，职责增加，开发难度增大。当然，可能有不少系统都与图5.1所示的系统类似或更加简单，服务也就几个甚至更少，系统本身就只有一个客户端，或者根本没有做前后端分离，这样的系统调用链就很简单，客户端维护服务信息也很容易。

即使这样仍然需要API网关，首先在生产环境中，服务都是多实例部署，以增加系统的可用度，一旦服务部署了多个实例，就需要有负载均衡的策略。

在微服务架构中，一般都采用客户端负载均衡的方式。也就是说，需要前端来负责负载均衡，有了负载均衡，还需要考虑服务熔断、降级、恢复等情况，这些服务治理职责都将交由前端来承担，如图5.3所示。

虽然如今前端的能力越来越强，一些框架也能够处理复杂的服务治理逻辑，但前端更应该关注用户的交互、数据的渲染等表现层的逻辑，而不应被后端的架构所影响，从而做很多不擅长或不应该负责的工作。

API网关的出现就很好地解决了这些问题。首先，前端不再面对复杂的调用关系，只需请求API网关即可；其次，系统本身不需要重复地关心客户端的认证方式，可以将认证逻辑放到API网关来做；最后，服务管理的职责也和前端解耦，可以在API网关集成Spring CloudNetflix Hystrix等组件，就能轻松拥有相关的服务治理能力，API网关架构图如图5.4所示。

API网关起到了很好的前后端隔离作用，既保护后端服务不会掺杂前端的判断逻辑，也隔离前端与微服务治理相关的职责，通过统一的网关，对所有的请求进行转发、过滤和治理，早期我们在单体式架构中常用的Nginx也是一种API网关模式的实现。

在解释了为什么要使用API网关之后，其职责也体现出来了。API网关的职责主要有3个：请求路由、请求过滤和服务治理。

请求路由

API网关本身并不具有服务的能力，一旦接收到客户端的请求，API网关会根据一定的规则（我们称它为路由规则）将这些请求转发给后端的微服务。

客户端不需要关心后端有几个微服务，也不需要关心这些服务的主机地址，只需维护一个API网关的地址。通过API网关，将请求路由到对应的服务端，通常我们会采用URL的路由规则，例如，将请求路径/users/ **转发给用户服务，将请求地址/goods/ **转发给商品服务，API网关URL路由示意图如图5.5所示。

除了请求路径的路由规则，我们还可以通过Reqest Header、Cookie等方式来设置路由的规则。例如，在Request Header或Cookie中可以设置Service-ID的键值，然后API网关就可以通过RequestHeader或Cookie来转发这些请求。总而言之，客户端只需将请求发送到API网关即可，不需要关心不同的服务地址或端口。当然，服务端通常会与前端定义好契约，其中包括URL或其他路由规则的定义，这样客户端不需要任何成本就可以使用服务端的接口。

请求过滤

我们已经知道API网关的一个重要职责就是用户认证，即通过一定的方式将不符合条件或不安全的请求拦截，而大部分API网关都是通过过滤器的方式来实现请求的拦截。当客户端首次请求需要用户认证权限的接口时，会先到达API网关的过滤器，然后API网关通过自己实现的认证逻辑判断当前请求的用户是否为已经认证过的合法用户，若校验失败，则请求被拦截，若校验通过，则过滤器不拦截该请求，请求正常向后执行逻辑，API网关请求认证流程如图5.6所示。

API网关也可以调用独立的认证服务来支撑自己的认证逻辑，如通过查询用户信息来校验用户名密码、验证密钥等操作，或者有时系统本身就没有自己的用户体系，需要集成第三方系统的单点登录服务或用户、权限等基础服务，那么我们完全可以将API网关和认证逻辑解耦，API网关依然负责拦截请求，但具体认证规则的判断可以调用后端的认证服务来完成，API网关与认证服务交互过程如图5.7所示。

当然，用户的登录认证也可以由API网关来负责，关于认证的详细实现将在5.3节介绍，这里不再赘述。

其实，一旦系统的所有请求都采用统一的入口，除了安全认证，我们还可以做很多事情，例如，可以通过过滤器的方式再过滤一下敏感的信息，如请求头中的Cookie、Authorization等，还可以修改请求或响应的信息，如限制请求大小、失败重试等操作，也可以设置过滤器的顺序，将不同的规则写在过滤器中，以组合不同的功能需求，API网关过滤器组合使用示意图如图5.8所示。

服务治理

请求路由和请求过滤可以说是API网关的两个重要功能，除了它们，还可以使用与后端微服务架构更加切合的技术来使API网关拥有服务治理的能力。API网关同样可以作为一个服务消费者，通过集成负载均衡器、断路器、注册中心和健康监控等组件完成服务的治理工作。通过将API网关集成注册中心，我们可以动态地进行服务发现，从而更优雅地完成路由、负载均衡等操作，如图5.9所示。

在API网关也作为注册中心的一个客户端注册到注册中心后，就能够动态地发现与监控各个服务的信息。例如，服务A和服务B也注册到注册中心，根据注册中心提供的服务信息，API网关就能很方便地进行远程调用、负载均衡等操作。

API网关作为服务的统一调用者，还可以方便地集成断路器，做到统一的服务熔断和降级，如图5.10所示。

如果没有API网关，服务熔断就只能在服务间使用，或者需要前端浏览器等终端来负责，并且每个终端可能都要实现相同的功能；如果有API网关，就可以像图5.10所示的那样对所有的后端服务进行统一的熔断处理，包括服务降级、自动恢复等问题就不用每个终端去实现，而且让前端来做服务治理显然是很奇葩的做法。

当然，对于不同的客户端，它的用户认证方式、服务治理策略及接口的规范可能都不一样，这时我们可以针对不同的终端配置不同的API网关，多终端API网关示意图如图5.11所示。

关于多个API网关的架构模式还有一个名称：BFF（Backend For Frontend，用于前端的后端），关于BFF的实践将在第6章中详细介绍。

前面介绍了使用API网关的目的和职责，那么API网关有没有缺点？任何架构模式都不是万能的，包括微服务架构本身都存在着不足，API网关总体来说有两个缺点：一是增加了开发的复杂度，二是有一定额外的性能消耗，如图5.12所示。

首先，显而易见地增加了项目的复杂度。在项目中使用过API网关的开发者不难发现，API网关需要进行额外开发和维护，在开发一个接口时，以往只需和前端进行调试，现在还需要和API网关调试，而且还涉及新的服务配置、部署和管理等工作。

其次，在前后端之间增加了一层调用链，哪怕只是简单的转发，也必然增加了一定的性能消耗，而且通常我们使用HTTP进行服务调用，HTTP的交互性能并不是很好，所以在一些对性能有极致要求的项目中，可能需要一些额外的优化工作，如缓存、请求合并等操作。

提到API网关，就不得不提及身份认证，因为安全保证才是一个网关最原始和最核心的功能，5.2.2节中已经介绍了API网关请求过滤的架构设计，那么在与前端的交互中，API网关如何对请求进行安全保障呢？

分清认证与授权

通常我们说到软件的安全管理，一般包括两个概念：一是认证，二是授权。这两个概念也经常被大家混淆，而且它们的英文单词很像，认证的英文是Authentication，授权的英文是Authorization，很多人在代码中会使用简写的Auth来替代这两个单词。笔者在每次遇到含有Auth简写的代码时都会感到异常焦躁，必须要深入解读代码才能知道这段代码到底是在处理认证还是在处理授权。

那么，什么是认证，什么是授权？

认证又称身份认证，是指通过一定的方式完成对用户身份的确认。在软件系统中，不是所有的服务都是开放式的，大部分情况下需要识别当前请求人是否为系统中的合法用户，这个识别的过程就是认证。

授权是指对资源的访问进行权限的定义，并通过授予用户不同的权限做到资源的访问控制。例如，公司的在职员工都能登录公司的财务系统，但只有财务人员才能查看公司的财务报表，其他员工只能查看自己的工资条。在软件系统中，授权在认证之后，只有识别了用户的身份，才能知道用户的权限，并对用户的访问进行控制，认证与授权的职责示意图如图5.13所示。

图5.13 认证与授权的职责示意图

在图5.13中，HTTP的状态码帮我们定义了不同的数值来区别认证和授权的异常，通常使用401表示认证失败，使用403表示没有访问权限。

认证在一开始就已经明确了是API网关的核心职责，因为认证逻辑一般与不同的客户端类型有关，有足够的通用性，不需要基础服务各自实现，而且在图5.11中，API网关通常是和客户端类型一对一的设计，是所有接口的唯一入口，所以认证十分适合放在API网关来实现。

那么授权是否也可以交给API网关来实现呢？

首先，我们要明白授权需要做哪些事情。授权是对资源访问权限的控制，大致上可以分为资源路径授权和资源授权两种类型，又称URL授权和数据授权。

例如，一款游戏软件只有VIP会员才能修改头像，假设现在有修改头像的接口A，只允许角色是VIP会员的用户才能访问，这就是URL级别的授权，资源路径的授权把权限放在接口层面，控制请求能访问的具体接口。所谓资源授权，其实就是比资源的接口更深层次的权限控制，如VIP会员虽然能访问修改用户头像的接口，但每个用户只能修改自己的头像，如果VIP会员在请求中传入的是其他用户的ID，这显然不允许。我们判断当前修改的数据是否符合业务规则，只能修改自己的头像就是当前的业务规则，这就是资源授权，即数据授权。

从架构层面来看，API网关是所有接口的统一入口，适合做一些全局限制，所以有一些项目会把授权放在API网关来实现，事实证明，它确实可以做到访问的权限控制。在架构设计中，并不是一味地封装或分离就是好的，要具体场景具体分析，比较通用的判断方法就是如果设计导致代码逻辑需要重复维护多个地方，就不是很好的设计。例如，之前我们分析的授权主要与业务规则相关，与是否为移动端或PC端没有关系，系统不会因为是手机用户就允许修改其他人的头像。如果把授权放在API网关层实现，那么实现授权如图5.14所示。

由于授权是针对业务规则进行控制的，无论是接口级的资源路径授权还是数据级的资源授权都需要对代码有一定的侵入性，因此一般授权没有很好的方式分离成单独服务。首先，即使是相同的授权规则，也需要在不同的API网关中集成相同的授权实现；其次，授权与业务规则强相关，各个微服务更加了解自己的业务规则及数据规则，如果API网关由不同的团队开发，要做好授权显然比较困难，综合这些原因，授权其实更适合放到业务层，即微服务各自去控制和管理，如图5.15所示。

图5.15 服务的业务逻辑层负责授权示意图

这样做的好处是首先授权逻辑可以更加通用，调用者不需要重复实现和维护授权的规则，其次服务端实现授权更加方便，而且业务逻辑层也更了解数据规则。

1. 下篇文章给大家讲解的是传统的Cookie和Session认证；
2. 觉得文章不错的朋友可以转发此文关注小编，有需要的可以私信小编获取；
3. 感谢大家的支持！