浅谈微服务之API网关

在微服务架构中，API Gateway作为整体架构的重要组件，它抽象了微服务中都需要的公共功能，同时提供了客户端负载均衡，服务自动熔断，灰度发布，统一认证，限流流控，日志统计等丰富的功能，帮助我们解决很多API管理难题。

浅谈API网关

一

作者说

随着微服务的大红大紫，大家纷纷使用微服务架构来实现新系统或进行老系统的改造。当然，微服务带给我们太多的好处，同时也带给我们许多的问题需要解决。采用微服务后，所有的服务都变成了一个个细小的API，那么这些服务API该怎么正确的管理？API认证授权如何实现？如何实现服务的负载均衡，熔断，灰度发布，限流流控？如何合理的治理这些API服务尤其重要。

什么是API网关

API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、流控。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

为什么需要API网关

从部署结构上说，下图是不采用API Gateway的微服务部署模式，我们可以清晰看到，这种部署模式下，客户端与负载均衡器直接交互，完成服务的调用。但这是这种模式下，也有它的不足。

第一、不支持动态扩展，如果发生服务实例新增、下线、IP或者端口变动等，需要修改负载均衡器的配置。

第二、无法做到动态的开关服务，若要下线某个服务，需要运维人员将服务地址从负载均衡器中移除。

第三、对于API的限流，安全等控制，需要每个微服务去自己实现，增加了微服务的复杂性，同时也违反了微服务设计的单一职责原则。

上图为采用API Gateway模式，通过图中可以看到，API Gateway做为系统统一入口，实现了对各个微服务间的整合，同时又做到了对客户端友好，屏蔽系统的复杂性和差异性。对比之前无API Gateway模式，API Gateway具有几个比较重要的优点：

第一、采用API Gateway可以与微服务注册中心连接，实现微服务无感知动态扩容。

第二、API Gateway对于无法访问的服务，可以做到自动熔断，无需人工参与。

第三、API Gateway可以方便的实现蓝绿部署，金丝雀发布或A/B发布。

第四、API Gateway做为系统统一入口，我们可以将各个微服务公共功能放在API Gateway中实现，以尽可能减少各服务的职责。

第五、帮助我们实现客户端的负载均衡策略。

API网关核心特性

01.负载策略

在实际的部署应用中，当应用系统面临大量访问，负载过高时，通常我们会增加服务数量来进行横向扩展，使用集群来提高系统的处理能力。此时多个服务通过某种负载算法分摊了系统的压力，我们将这种多节点分摊压力的行为称为负载均衡。

负载均衡分为服务端负载和客户端侧负载。服务端侧负载在访问者和目标服务之间架设LB硬件或者软件中间件，硬件流行的有F5，中间件主流的有Apache、Nginx、HAProxy、KeepAlived等。

请求首先发送到负载均衡服务器，负载均衡服务器根据一定算法，将请求转发给后端服务器之中的一个。服务端侧负载软硬件技术成熟，效率也高。不过后端服务器变动需要修改负载均衡服务器的配置，略有不便，且需要对负载均衡服务器本身实现高可用，增加了部署和维护成本。

客户端侧负载有所不同，后端服务器的地址列表不再由负载均衡服务器存储和维护，而是每个客户端都会存储在本地。后端服务器启动时自动向注册中心注册服务，服务下线时服务注册中心也能获知。客户端建立对服务注册中心的长监听，每当后端服务发生变化，注册中心自动通知客户端更新本地缓存的服务器列表。

目前主流的服务注册中心由Eureka、Zookeeper等。客户端侧负载的好处是方便，后端服务变化对客户端是透明的。但是相比服务端负载，客户端侧负载对后端服务有要求，不是所有的后端服务都能做客户端侧负载。

目前流行的API Gateway有Spring Cloud Zuul，Zuul默认使用Ribbon实现客户端侧负载，利用服务注册中心可知道所有后端服务的地址和状态，通过负载均衡算法，尽可能均衡的转发请求到后台微服务。

Ribbon支持的负载均衡策略即是网关支持的，其默认提供的负载均衡策略包括主要包括以下内容。

02.服务熔断

在实际生产中，一些服务很有可能因为某些原因发生故障而不可用，比如服务内部错误、网络延迟等，如果放任故障服务不管，可能会因为级联故障导致雪崩效应，使得整个系统瘫痪。为此，我们需要对不可用服务的调用快速失败。

Spring Cloud提供了Hystrix组件来实现这一点。当某服务在短时间内多次发生调用失败，服务消费方的断路器会被断开。开路的断路器就像电路跳闸一样，阻止消费方向故障服务发送请求，直接返回失败或者执行消费方的降级逻辑。断路器通常在一定时间后关闭，在这期间可以为底层服务提供足够的空间来恢复。

理解断路器需要了解以下几点：

第一、断路器只是作用在服务调用这一端。

第二、服务的健康状况 = 请求失败数 / 请求总数。

第三、断路器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的。

第四、关闭时, 请求被允许通过断路器. 如果当前健康状况高于设定阈值, 开关继续保持关闭. 如果当前健康状况低于设定阈值, 开关则切换为打开状态。

第五、打开状态, 经过一段时间后, 断路器会自动进入半开状态, 这时断路器只允许一个请求通过. 当该请求调用成功时, 断路器恢复到关闭状态. 若该请求失败, 断路器继续保持打开状态, 接下来的请求被禁止通过。

第六、保证服务调用者在调用异常服务时, 快速返回结果, 避免大量的同步等待。

第七、在一段时间后继续侦测请求执行结果, 提供恢复服务调用的可能。

API网关作为服务请求的统一入口，负责转发请求到后端服务。对于所有后端服务来说，网关就是服务请求方。所以，在网关上配置断路器是最佳实践。Spring Cloud Zuul默认提供了对Hystrix的支持。

03.流控

流控的目的主要是防止短时间内大量请求转发到后台压垮服务器，比如典型的DDos攻击，恶意攻击者操控大量僵尸机器，持续向目标服务器发送大量请求，让服务器忙于应付而无暇处理正常用户的请求，达到瘫痪服务器的目的。为了防止这种情况出现，API网关应对请求做限流，即流量控制也叫流控。API网关统计一个时间窗口内针对某服务的请求数量，如果超过一定的阈值，则应拒绝继续转发请求到后端服务。时间窗口是滑动窗口，下一个时间窗口到来时，计数器清零。

计数器被并发请求访问，如果设置为线程安全的，则并发性能大大降低，限流将成为服务的性能瓶颈，如果计数器不做线程并发控制，则可能导致计数错误。针对这个问题，可使用Redis解决。利用Redis的单线程模型和高性能的并发支持，可以在保证高并发下计数器计数准确。

流控的时间窗口设置不宜太大，因为请求数量有高峰和低谷，请求洪峰到来时可能短时间内将配额用尽，如果时间窗口过大，则窗口内其他时间里会一直拒绝请求，即便后端服务此时压力已经不大，这样流控的效果很差。流控时间窗口也不宜过小，否则损耗在流控计算上的资源代价太大，得不偿失。流控的阈值设置不能靠拍脑袋评估，需要在严谨的性能压力测试基础上得出。根据经验，可以将流控时间窗口设置为1秒，请求数量设置为服务的压测TPS数。

04.认证鉴权

从单体应用架构到分布式应用架构再到微服务架构，应用的安全访问在不断的经受考验。单体应用体系下，应用是一个整体，一般针对所有的请求都会进行权限校验。请求一般会通过一个权限拦截器进行权限校验，在登录时将用户信息缓存到会话Session中，后续访问则从会话中获取用户信息。

而在微服务架构下，一个应用被拆分为若干个微应用，每个微应用都需要对访问进行鉴权，每个微应用都需要明确当前访问用户及其权限，单体应用架构下的鉴权方式就不适合了。为了适应架构的变化，身份认证与鉴权方案也在不断的变革。面对数十个甚至上百个微服务之间的调用，如何保证高效安全的身份认证，如何提供细粒度的鉴权方案，是亟待解决的问题。

API网关作为服务访问的统一入口，所有用户请求都会过API网关，很适合用来做认证鉴权这类切面型服务。网关可以拦截用户请求，获取请求中附带的用户身份信息，调用认证授权中心的服务，对请求者做身份认证，即确认当前访问者确实是其所声称的身份，检查该用户是否有访问该后台服务的权限。

目前主流的认证鉴权方案有2种。

第一种是引入Redis做分布式会话，即用户登录成功后，将用户身份、权限信息存入Redis，以一个唯一ID作为Key，并设置信息在Redis里的失效时间。这个唯一ID的Key将返回给客户端，客户端可以放入Cookie，sessionStorage等处做本地存储。下次访问的时候，将这个唯一ID放入请求参数中一起发送（一般放入Header）。服务端通过检查Redis里有无这个ID来判断用户是否登录，获取用户身份和权限信息。客户端如果长时间没有操作，则存储在Redis里会话信息过期自动删除。客户端每访问一次服务端，需刷新一次会话信息的过期时间，避免固定过期时间带来的低用户体验。

第二种是JWT，即Java Web Token。用户登录成功后，服务端向客户端返回的唯一ID不再是无意义的字符串，而是包含了用户身份、权限、失效时间等信息的加密字符串。并且这个字符串包含数字签名，服务端可对这个字符串做数字签名验签，确保该字符串未经篡改和伪造。相比分布式会话方案，JWT虽省去了Redis存储，但是每次访问都要做数字签名验证，增加了CPU的资源损耗。

05.灰度发布

服务发布上线过程中，我们不可能将新版本全部部署在生产环节中，因为新版本并没有接受真实用户、真实数据、真实环境的考验，此时我们需要进行灰度发布，灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，同时影响小。API Gateway可以帮助我们轻松的完成灰度发布，只需要在API Gateway中配置我们需要的规则，按版本，按IP段等，API Gateway会自动为我们完成实际的请求分流。

——//////////——

平台云课堂

为邮储科技人带来有价值有温度的阅读