4 API网关技术

上一篇介绍了服务治理框架Spring Cloud框架，本篇主要介绍服务治理框架的核心—API网关，后续服务治理也将围绕API网关进行深入展开研究。

4.1 API网关总体架构

微服务架构系统中，客户端的请求经过负载均衡器后，再被转发到后端各个不同的可用的服务实例上，但这也暴露了更多的服务，不利于集群的安全性。而当这些服务实例列表发生变动时，需要手工同步修改负载均衡器配置以确保与实例信息的一致性，使其能够正确路由和分发请求。随着系统规模的增长，服务实例不断的增多，手工维护这些服务实例列表的工作将变得越来越困难。另一方面，为了保证对外服务的安全性，各个服务端对于客户端的请求，都需要实现对用户身份验证及会话控制、安全校验、话术转换、风控等非业务逻辑的功能，而这些功能本身与业务无关，也使微服务架构系统产生了冗余功能，这将给开发和测试人员带来沉重的工作负担。因此，需要一套机制来解决对外提供服务，以及对客户端请求进行拦截过滤和调度转发的问题。

API网关旨在对外提供针对所有API调用的统一入口，实现对微服务接口的统一接入、请求转发。API网关建立与各微服务的路由访问关系映射，并将客户端的请求转发至对应的后端服务实例。

API网关作为微服务架构系统中的门面，除了实现路由转发、负载均衡、请求过滤、安全防护等功能外，还能够很方便的实现对客户端访问后端服务接口的管控，比如请求响应加解密、身份认证、接口鉴权、数据脱敏、流量控制、访问计量等，以及提供服务调用的熔断机制、服务治理、服务聚合等能力。

图4-1 API网关架构

如图4-1所示，API网关优点如下：

（1）快速接入

随着互联网及业务自身的发展，终端设备越来越多样化，需要业务系统能够支持更多的终端设备，同时也增加了系统的复杂性。API网关作为外部访问的统一入口，是对外进行数据交互的桥梁。通过对API的定义，实现多端统一，一套服务多端输出，便能够快速的支持APP端、终端设备、WEB端等多种终端接入。

（2）安全保障

所有客户端的请求统一经过API网关才能够访问内部服务，对客户端的请求校验，包括参数类型、参数值的校验，并过滤风险请求、非法请求和无效请求，减少对后端服务的资源消耗，降低后端的处理成本。网关支持对API灵活的权限控制，只有获得API网关授权的应用才能访问内部服务提供的接口。在安全防护方面，API网关支持多种认证鉴权方式，提供防攻击、防重放、请求响应链路加解密、防篡改等多重手段保障系统内部的安全性。

（3）数据转换

面对多端接入时，不同的客户端可能传输不一样的数据。API网关对请求响应数据的处理，支持数据转换的功能，将客户端请求的数据解析转换后再转发至内部服务，对内部服务响应的结果进行数据转换后再返回客户端。这样既严格控制了数据的输入输出，又兼容了多端请求的多样性，也提升了后端服务的灵活性。

（4）封装隔离

API网关封装了系统内部架构，将外部的客户端与内部系统之间进行了隔离，汇聚了对外提供服务的API，使客户端可直接和网关通信。API网关对请求进行超时管控，当下游服务不可用时进行故障隔离。

（5）边界解耦

微服务架构中的API网关作为边缘服务存在于应用程序之上，为其它服务提供抽象功能，解决API中的边界问题。应用服务无须处理非业务性质的功能，让应用服务能够更专注于实际的业务逻辑开发，这从一定程度上降低了构建微服务的复杂性，简化了微服务开发工作。

4.2 网关服务治理关键问题研究

4.2.1 服务统一接入

通常大型平台中既有系统内部请求也有外部请求，我从请求方式、渠道来源、交互方式三个方面分析，请求方式可能包括来自移动客户端、PC客户端和浏览器端的请求，渠道来源上包括服务内部之间请求、第三方应用的请求，交互方式包括用户与服务、服务与服务之间的交互。服务网关在面对众多不同的接入方、不同的请求来源及交互方式方面，主要存在的问题如下：

（1）接入方式多样化、请求标准不统一。

（2）请求来源不同，服务交互场景不一样，选择合理、安全高效的接入方式。

（3）内、外接入方各自的身份特征不同，怎样验证接入方的合法身份及访问权限。

（4）如何对接入方所访问的服务资源进行限制与管控。

（5）对接入方的会话状态如何有效进行管理和维持。

服务网关作为内、外部访问各业务中心的统一入口，要求从服务网关层面对所有请求进行统一拦截，统一管控接入方会话，服务认证与鉴权，提供统一接入规范与标准，这对于保证业务系统的安全性具有至关重要的作用。

4.2.2 数据链路安全

网关作为服务入口，其本身关系着系统自身及用户身份信息的安全性。同时，也存在不法分子、黑产通过非法手段攻击系统行为，给系统带来了极大的安全风险，主要存在的问题如下：

（1）移动端APP被破解，明文请求参数暴漏。

（2）涉及用户敏感数据泄露问题。

（3）固定密钥泄露，固定密钥为移动端与后端服务协商的数据加解密密钥。

（4）请求参数伪造，携带攻击性、注入类等危险性的请求参数访问系统。

（5）使用同一请求参数对系统进行重放攻击。

 根据上述安全问题要求，在网络数据传输过程中，必须对请求参数、响应数据进行双向加解密，不能使用对称固定密钥传输密文，并对请求参数进行相应的安全过滤处理。系统应用数据被妥善的安全保护是X平台最重要的安全需求，也是系统安全防护框架体系的重要组成部分。

4.2.3 服务治理

随着公司业务不断的发展，后端业务微服务也随着业务的增长越来越多，而对于服务运维和API资源访问控制管理也越来越困难，具体问题主要表现在以下几个方面：

（1）如何动态的对微服务进行上线下线管理操作。

（2）未统一管控API接口，存在API接口越权调用风险。

（3）根据API接口访问规则配置进行动态调整设置。

（4）当调用服务故障时，不能针对指定服务进行服务熔断及容错处理。

（5）加载配置时通过定时器同步处理，无法及时动态感知配置规则的变化。

通过对以上问题的描述，结合服务运维效率的要求，需要服务网关能够实现对微服务的动态管理，可以通过配置实时调整微服务的上线下线操作；统一管理注册API接口，未经注册的API接口禁止访问；当服务出现故障或服务超时的问题时，能够及时自行熔断及容错处理；对所依赖的配置能够及时通知服务网关进行配置更新。

利用API管理的来实现服务治理，解决服务之间的依赖性，降低耦合性，隔离内部和外部服务，统一对外提供接口，禁止直接访问内部数据，增加系统安全性。服务治理所需要实现的功能主要包括路由管理、路由转换、访问控制、黑白名单、API管理、流量限额、服务埋点、服务熔断等功能，通过服务治理为整个业务系统的统一入口提供可靠保护，利用服务熔断机制优化系统，提升系统性能。另外，提供对业务微服务返回的数据进行处理与转换，简化客户端处理的复杂度，便于开发和维护，提升敏捷性，降低开发和运维成本。

4.3 网关服务治理解决方案

4.2.1 统一认证鉴权与访问控制

从服务网关接入的角度，无论是内部应用还是第三方应用，都能够以应用的方式接入，并统一对应用进行访问控制和认证鉴权管理。从微服务架构的角度，可以将服务网关拆分为内部网关和对外开放网关各自部署，实现对业务隔离，服务解耦，增强服务网关的可扩展性。

统一认证鉴权是服务网关所要实现的关键功能，面对众多的应用接入方，复杂度较高，可以选择采用JWT Token身份认证机制和OAuth2.0授权框架来统一实现对应用接入方的访问控制和认证鉴权过程。其中JWT Token具有无状态、自包含、支持跨域请求、易扩展、自动过期机制、安全性高等特性，能够适用于不同的应用身份认证场景，更适合开放。OAuth2.0作为一个授权框架，用于授予应用接入方获取有限的访问资源权限，应用接入方能够获取访问令牌和使用访问令牌请求服务资源，其在授权许可模式上，提供了良好的灵活性，能够面对客户关或应用接入各种各样的变化。统一认证鉴权为对外提供开放接入的能力，与外部接入方可管可控的共享服务、能力和数据，构建新的应用生态打好坚实的基础，为资源服务提供更加安全的保障。关于统一认证鉴权与访问控制，如图4-2所示。

图4-2 应用认证鉴权与访问控制流程

4.2.2 全链路数据安全

在分布式系统中，从客户端请求开始到服务端响应结束的所有中间调用环节被称为调用链。全链路是指从数据传输、数据处理到数据存储的全过程。服务网关对于全链路数据安全的设计主要从应用系统级别的数据传输、数据内容过滤和访问控制三个方面考虑，对数据存储提供安全标准规范。

从数据传输安全方面分析，要求服务网关做到数据传输过程的安全性、完整性和可靠性。数据安全性是指为数据提供保护性技术或防御手段，主要实现手段包括：数据加密、密钥管理等，其中数据加密技术包括采用混合加密机制、实时动态密钥策略和双向加密三种加密策略。数据完整性是指数据的正确性和合法性，可通过加密算法对请求内容数字签名来保证数据的完整性。数据可靠性是指在数据生命周期内保持完整、一致与准确的程度，主要实现手段包括：防重复请求、时间戳机制、关键数据拆分传输等。

4.2.3 实现基于API的服务治理

服务治理的目的是为了解决分布式服务和微服务在开发与运行时带来的运维问题、处理服务之间依赖关系。服务网关作为调用服务的唯一入口，封装内部服务架构，提供API给各个客户端，客户端无须直接与后端微服务交互，是客户端请求API服务的必经之路。基于服务网关统一对外提供API服务，阻止外部请求者直接访问内部服务，实现对微服务和API资源统一管理，使服务与服务之间相互解耦，对外提供标准化输出等功能。

服务网关需要面对众多不确定的接入方和未知的用户群体，也需要管控后端微服务对外输出的服务能力，这对于如何治理服务和控制资源的接入成为非常关键的问题。微服务的接入可以通过动态路由来完成治理，实现了包括微服务注册、微服务下线、重试服务等功能，只有存在于动态路由表的服务才能被外部应用访问到，而未在动态路由表中的后端微服务将无法被外部访问，因此通过动态路由的实现达到控制外部访问微服务的目的。

相对于微服务的接入治理，API资源接入的治理更加细粒度化。API是各后端微服务对外提供自身服务能力的唯一入口。服务网关实现对所有后端微服务API资源的统一管理，提供了API注册、下线、配置过滤规则等功能，API是后端微服务的子集。同样与后端微服务接入管控策略一致，未经注册API也将被拒绝访问。

服务网关通过对API请求的中间过程的控制来实现服务治理的目标。当服务网关接收到外部访问API资源的请求后，会对该请求进行一系列的前置过滤处理，包括加解密、签名验证、安全过滤、认证鉴权、用户身份识别等；然后再由服务网关进行动态路由，将请求转发至与API资源相应的后端微服务进行业务处理；当后端微服务业务处理完成后，服务网关将会接收到响应报文，对响应报文过滤处理后，最后返回给外部请求方。

4.4 开源网关方案的不足

目前基于Spring Cloud开源主流的网关框架主要有Zuul、Spring Cloud Gateway，以下对这两个开源网关进行分析：

4.4.1 Zuul

Zuul网关目前存在两个版本分别为Zuul1.0和Zuul2.0，其中Zuul1.0已经停更，而Zuul2.0也未被Spring Cloud所支持，而Spring Cloud则推出了自己的网关框架Spring Cloud Gateway。我之前所建设的网关是基于Zuul1.0所实现，包括携程也采用了成熟的Zuul1.0。Zuul1.0存在较多的问题，其中最重要的就是网关性能问题，Zuul1.0采用多线程阻塞模型进行请求转发，流量高峰期通常需要对资源进行扩容来缓解资源上的不足，且Zuul1.0也不支持Websocket协议，已经逐渐被弃用，更多的采用Spring Cloud Gateway。

4.4.2 Spring Cloud Gateway

Spring Cloud Gateway是Spring Cloud体系的网关组件，其集成了对负载均衡，动态路由，访问控制，限流熔断，埋点监控等功能的支持。但不支持自定义通信协议，不支持Socke长连接协议，性能方面也略有所不足，如果对接入要求不高，可完全采用Spring Cloud Gateway网关框架开发。