1.1 认识API网关
1.1.1 API 网关是什么
工作中提及的网关特指 API 网关(API Gateway)。字面意思是将所有 API 的调用统一接入 API 网关层,由网关层负责接入和输出
什么情况下需要一个 API 网关?
单体应用时代,业务简单,功能都集中在一个应用中,统一部署、统一测试,随着业务发展组织成员日益增多。将多有的功能集中在一个Tomcat中的时候,每更新一个功能模块,势必要更新所有的程序。系统难以维护
微服务出现,将原来的单体应用进行微服务化。将原来集中于一体的功能(如商品功能、订单功能)进行拆分,每个功能模块有各自的自成体系的发布、运维等功能。解决了单体应用下的弊端
微服务化后,原来iOS、Android、PC客户端调用服务端的地方,需要多个URL地址,商品的、订单的、用户的。为服务化后就必须有统一的入口和出口,在这种情况下, API Gateway就出现了。
API Gateway 很好地解决了微服务下客户端调用、统一接入的问题。如下图
有了API网关之后,各个API服务提供团队可以专注自己的业务逻辑处理,而API网关更专注于安全、流量、路由等问题。
网关与代理的区别:
代理是纯粹的数据透传,协议不会发生变化;
网关在数据透传的背景下,还会涉及协议的转换,比如上图中用户请求传输到网关的协议是 HTTP,通过网关透传到下游则可能已经转换成企业内部的 RPC了(比如 JSF、Dubbo等企业自研的 RPC框架)
1.1.2 API 网关的基本功能
一个API网关的基本功能包括:统一接入、协议适配、流量管控与容错,以及安全防护,这四大基本功能构成了网关的核心能力。
网关首要的功能是负责统一接入,然后将请求的协议转换成内部的接口协议,在调用的过程中还要有限流、降级和熔断等容错的方式来保护网关的整体稳定,同时网关还要做到基本的安全防护(防刷控制),以及黑白名单(比如 IP 地址白名单)等基本的安全措施。如下图所示。
1.1.3 API 网关架构示例
除了基本的四个功能,网关运行良好的环境还包括注册中心(比如通过 ZooKeeper 读取已发布的 API 接口的动态配置)。为了实现高性能,将数据全部异构到缓存(比如 Redis)中,同时还可以配合本机缓存来进一步提高网关系统的性能。
为了提高网关的吞吐率,可以使用 NIO+Servlet 3 异步的方式,还可以利用 Servlet 3 的异步特性将请求线程与业务处理线程分开,为后续的线程池隔离做好基本的支撑。
访问日志的存储可以放到 HBase 中,如果要作为开放网关使用,需要一个支持 OAuth 2.0 协议的授权中心。同时还可以引入 Nginx+Lua 的方式,将一些基本的校验判断前置到应用系统之上,这样可以更轻量化地处理接入的问题。
整体的网关架构(涵盖开放网关)示例如下图所示
1.2 一个传统网关系统的几种“死”法
传统网关,是按照网关技术演进的阶段划分的,从同步到半同步,再到全异步。将同步和半同步技术下的网关称为“传统”网关。
同步网关的意思是从接收请求到调用API接口提供方的过程都是同步调用;
半同步则是指将 I/O 请求线程和业务处理线程分开,但业务线程内部还是同步调用 API 接口;
全异步是整个链路都是异步请求。
传统网关会在什么情况下 down 掉?
API 网关系统的两大特点:一个是访问量大,另一个是依赖系统多。如下图所示,“单纯”的情况下(比如系统A提供的接口只供网关调用)网关系统要承受比被依赖的系统多数倍的流量,因为 API网关是所有依赖 API的集合。
网关还会通过 RPC 调用很多底层系统,每个系统的稳定性水平参差不齐,接口的性能也会间接影响网关整体的运行稳定性。因此我们再做防范的时候就要从这两个特点入手。
上面介绍的 API网关的两大特点是外部因素,下面是内部因素。程序都是运行在计算机上面的,计算机的每个部件的利用率和负载水平直接影响程序的运行,比如 CPU、内存、磁盘等。另外系统之间的交互还需要网络,这些因素都需要考虑。
一段程序在计算机中运行依赖部件如下图:
1.2.1 关注CPU
用户请求在进入网关的时候从技术上已经把 I/O请求线程和业务处理线程隔离开了,这一点可以利用 Servlet3 异步特性实现。如下图所示
业务线程池是在 CPU中运行的,线程是计算机 CPU 最宝贵的资源,我们一定要重点关注 CPU 的利用率和 CPU 负载
CPU利用率:显示的是程序在运行期间实时占用的 CPU百分比
CPU负载:显示的是一段时间内正在使用和等待使用 CPU 的平均任务数。在 Linux系统中,我们可以使用 uptime 或 top命令查看系统的负载情况
top - 14:17:13 up 19 days, 3:27, 1 user, load average: 1.19, 1.39, 1.33
load averages 的意思是系统平均负载,包括三个数字,分别表示 1分钟、5分钟、15分钟内系统的负载平均值。可以按照 1 分钟的粒度取一个数字,从而判定系统负载的大小。
19 days 说明此台机器已经有23 天没有重新启动过了
CPU利用率高并不意味着负载就一定大,两者没有必然联系。线上生产环境需要重点监控CPU利用率和负载。
API 网关访问量大、依赖系统多,如果调用的 API 性能突然变差,在大访问量的情况下,线程数会逐渐升高,直至将 CPU 资源耗尽。蔓延到整个网关集群,这就是雪崩效应。
1.2.2 关注磁盘
磁盘有两个比较重要的指标分别是 磁盘使用率 和 磁盘负载百分比。
磁盘负载百分比:在Linux下查看该指标的命令是 iostat -x 110
%util 值接近 100%,说明产生的 I/O 请求太多, I/O系统已经满负荷,该磁盘可能存在瓶颈。
程序运行的过程中,我们可能都不会关注磁盘的使用,如果处理不当,则有可能成为一个'定时炸弹'。网关的特性访问量大,再加上有的程序里面的日志打印不规范,比如日志的级别设置的不合理,把 info 日志打印出来。
即使在日志级别合理的情乱下,比如 error 日志,这时又涉及网关的第二个特性,依赖系统多。当有 API 返回失败错误的时候,就会有大量的 error 日志写入磁盘,很容易把磁盘资源耗尽,尤其在容器时代,每台服务器分配的磁盘容量相对物理机来说都比较小,如果集群的所有机器的磁盘资源耗尽,那么对网关系统来说就是一场灾难。
1.2.3 关注网络
在微服务架构下,应用离不开网络,尤其是网关系统,它的特点之一就是依赖系统多。依赖就是 RPC 调用和网络。
在一个 RPC 环境下,网络占据了一次 RPC 调用所耗时间的很大比重。网络质量的好坏直接影响了一次请求从进入 API网关到返回给用户响应的时间长短。
如下入所示,网关到依赖系统B之间得网络突然变差,调用时长增加,在请求访问量多得时候,一请求一线程得模式下,会直接导致 API 网关系统的任务线程数增多,如果短时间内不能恢复,则整个 API网关的集群所有机器的 CPU 资源都会被线程耗尽。
同时现有的线上生产环境部署并不能保证同机房调用,甚至还有跨地区调用,因此网络是我们要考虑的一个重要因素,同时网络的因素需要和上面讲到的 CPU 的线程资源相关联去考虑。
总结一个传统 API 网关系统的几种 死法:
1.因为依赖的某个系统的 API 性能突然变差导致请求线程数量逐渐升高直至线程占满了 CPU,也就是 API 网关依赖系统多的特点因素,可以认为是被其他系统 拖死的。
2.线上生产环境日志打印不规范,过度打印日志,再加上请求量突然变大,导致清理工具来不及清理日志,最后磁盘满了。
3.网络一直是一个除系统本身外最不稳定的因素,在系统之间调用的时候,网络发生故障导致请求变慢,这一点和第一条被其他系统 拖死类似,只是这次是网络。
来源:https://www.cnblogs.com/veggiegfei/p/11791661.html