分布式微服务-API网关(Api-Gateway)

API网关介绍

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

  • api-gw在整个框架结构中的位置如下图:

  • 传统的(微)服务部署框架

分析两种框架

没有对比就没有伤害,先看传统的的部署方式,咱们列一下传统部署方式的缺点:

a、不支持动态扩展,如果发生服务实例新增、下线、IP或者端口变动等,需要修改负载均衡器的配置。
b、无法做到动态的开关服务,若要下线某个服务,需要运维人员将服务地址从负载均衡器中移除。
c、对于API的限流,安全等控制,需要每个微服务去自己实现,增加了微服务的复杂性,同时也违反了微服务设计的单一职责原则。

然后咱们再看分析一下通过api网关的部署方式:

a、采用API Gateway可以与微服务注册中心连接,实现微服务无感知动态扩容。
b、API Gateway对于无法访问的服务,可以做到自动熔断,无需人工参与。
c、API Gateway可以方便的实现蓝绿部署,金丝雀发布或A/B发布。
d、API Gateway做为系统统一入口,我们可以将各个微服务公共功能放在API Gateway中实现,以尽可能减少各服务的职责。
e、帮助我们实现客户端的负载均衡策略。

Api-gw职责分析

  • 1负载均衡

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

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

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

客户端负载的好处是方便,后端服务变化对客户端是透明的。但是相比服务端负载,客户端侧负载对后端服务有要求,不是所有的后端服务都能做客户端侧负载。

  • 2服务熔断

在实际生产中,一些服务很有可能因为某些原因发生故障而不可用,比如服务内部错误、网络延迟等,如果放任故障服务不管,可能会因为级联故障导致雪崩效应,使得整个系统瘫痪。为此,我们需要对不可用服务的调用快速失败。当某服务在短时间内多次发生调用失败,服务消费方的断路器会被断开。开路的断路器就像电路跳闸一样,阻止消费方向故障服务发送请求,直接返回失败或者执行消费方的降级逻辑。

各个服务在写入注册中心的时候,都会和zk注册中心建立会话机制,比如“服务C”宕机,那么,其在“注册中心”写下的ip和端口也会自动删除。此时(API网关)消费者监听到zk数据节点有变动,重新读取到的“服务地址列表的数据”也会随之发生改变。

  • 3流量控制

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

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

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

  • 4权限管理

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

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

目前认证的主流方式是JWT(json web token),其认证流程图如下:

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

  • 5灰度发布

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

尾语

APi-Gateway某种程度上像不像咱们开发中使用的”过滤器”

常用api网关组件很多,我这边提供一个叫做Ocelot,(其功能包括:路由、请求聚合、服务发现、认证、鉴权、限流熔断、并内置了负载均衡器) 详细网址:Ocelot创建网关示例超简版 、 使用Ocelot创建API网关简单示例 和 Ocelot的使用和配置服务

示例程序:OcelotTest.rar (1.76 mb)切记示例先看压缩包内的说明文档

添加评论

Loading