网关知识整理
2022-09-28 15:44:22 2 举报AI智能生成
网关相关知识，微服务入口相关知识
作者其他创作
大纲/内容
实践
自己搭建的服务网关介绍
部分功能截图
举例令牌限制
举例配置过滤
业界的方案
实现方案
基于Nginx+Lua+ OpenResty
Kong,orange都是基于这个方案
基于Netty、非阻塞IO模型
宜人贷等一些公司是基于这种方案，成熟的方案。
基于Node.js
应用了Node.js天生的非阻塞的特性
基于java Servlet
zuul基于的就是这种方案
产品介绍
Nginx
说明
模块编译
Lua及C++开发（OpenResty）
优点
具备URL转发映射及反向代理功能
效率高
占有内存少
并发能力强
缺点
如具备身份认证与安全、审查与监控，需要模块化开发，开发成本高
限于HTTP的解析，非JAVA语言开发
Kong
说明
基于OpenResty的 API 网关服务和网关服务管理层
优点
基于Nginx的，所以在性能和稳定性上表现不错
插件扩展功能
前置的负载均衡器分发请求
网关热更新，不重启服务
多种集群缓存
缺点
需要自研相应功能插件
有一定的学习成本
Netflix 的 Zuul
说明
核心是一系列的过滤器
JAVA开发
优点
具备URL转发映射及反向代理功能
可以扩展自己需要的过滤器
缺点
性能和线上大面积故障
Spring Cloud 的 Zuul
说明
Spring Cloud整合和增强
优点
JAVA原生，设计简单代码不多，容易读懂；同步 Servlet，采用多线程阻塞模型；
具备URL转发映射及反向代理功能
增加了安全验证、动态路由、负载分配等
缺点
线程本身需要消耗 CPU 和内存资源，多线程之间切换开销多；
预热后性能更会好，Servlet容器把.class文件中的数据读到内存中；
更新需要重启中断服务；
网络请求处理位于高层次网络层
Spring Cloud Gateway
说明
Spring Cloud的开源项目之一
与整合增强zuul地位不一样
优点
具备URL转发映射及反向代理功能
可以扩展自己需要的过滤器
效率相对较高
缺点
基于JAVA，运行体量大
依赖使用Spring多套框架
netty自研API网关
说明
利用Netty实现的filter
JAVA开发
优点
具备URL转发映射及反向代理功能
利用了netty的高性能
可以实现的filter来增加各种功能
缺点
需要从头开发，踩坑会较多
filter越多性能会不断下降
缓存不容易做好
比对
通常比对
分支主题
选两个重点架构技术对比
语言
zuul:JAVA
优势
kong:LUA
设计
kong:脚本作用于Nginx的不同工作阶段，需要原理性理解
zuul:设计简单代码不多，容易读懂
优势
功能扩展
zuul:通过filter重复开发
kong:通过插件扩展功能
优势
负载层次
zuul:顶位负载网络层
kong:四层或七层网络层负载
优势
负载均衡器
zuul:后置的负载均衡器分发请求
kong:前置的负载均衡器分发请求
优势
网关更新
zuul:会中断服务
kong：热更新，不中断服务
优势
性能
zuul:性能平稳
kong:性能优秀
优势
网关的作用（具体有哪些）
统一接入
请求路由
协议转换
API网关的一大作用在于构建异构系统，API网关作为单一入口，通过协议转换整合后台基于REST、AMQP、Dubbo等不同风格和实现技术的微服务，面向Web Mobile、开放平台等特定客户端提供统一服务
路由转发
路由是微服务网关的核心能力。通过路由功能微服务网关可以将请求转发到目标微服务。在微服务架构中，网关可以结合注册中心的动态服务发现，实现对后端服务的发现，调用方只需要知道网关对外暴露的服务API就可以透明地访问后端微服务。
负载均衡、容灾切换（异地多活）
API网关结合负载均衡技术，利用Eureka或者Consul等服务发现工具，通过轮询、指定权重、IP地址哈希等机制实现下游服务的负载均衡。
三大特性
高性能
高可用
概念
对于大多数网站，2个9 是基本可用；3个9 是叫高可用；4个9 是拥有自动恢复能力的高可用
例如QQ的可用性是 4个9，就是说 QQ 能够保证在一年里99.99%的时间是可用的，只有0.01%不可用（大约53分钟）
简单总结
一个请求过来，首先经过 Nginx 的一层负载，到达网关，然后由网关负载到真实后端，若后端有问题，网关会进行重试访问，
多次访问后仍返回失败，可以通过熔断或降級立即返回结果。而且由于是负载均衡，网关重试时不ー定会访问到出错的后端（当主服务器发生故障或者宕机，备份服务器可以立即充当主服务器进行不间断工作）
高并发
版本控制
灰度发布
微服务网关可以根据HTTP请求中的特殊标记和后端服务列表元数据标识进行流量控制，实现在用户无感知的情况下完成灰度发布。
流量染色
和灰度发布的原理相似，网关可以根据HTTP请求的Host、Head、Agent等标识对请求进行染色，有了网关的流量染色功能，我们可以对服务后续的调用链路进行跟踪，对服务延迟及服务运行状况进行进一步的链路分析。
容错性
服务熔断
异常熔断
超时熔断
信号量熔断
线程池熔断
服务埋点
请求/响应数据
服务耗时
调用链
日志
调用日志
微服务网关可以作为统一的日志记录和收集器，对服务URL粒度的日志请求信息和响应信息进行拦截。
参数结果
调用审计
日志审计
微服务网关可以作为统一的日志记录和收集器，对服务URL粒度的日志请求信息和响应信息进行拦截。
简单划分
接口访问日志
接口限流日志
接口熔断日志
接口异常日志
回溯
指标监控
网关可以统计后端服务的请求次数，并且可以实时地更新当前的流量健康状态，可以对URL粒度的服务进行延迟统计，也可以使用Hystrix Dashboard查看后端服务的流量状态及是否有熔断发生
API文档
文档中心
API文档生成
网关结合Swagger，可以将后端的微服务暴露给网关，网关作为统一的入口给接口的使用方提供查看后端服务的API规范，不需要知道每一个后端微服务的Swagger地址，这样网关起到了对后端API聚合的效果。
在线测试
mock测试
数据存储
MySQL (持久化)
数据缓存 (cache)
结果缓存
预热
ES (日志)
流量管控
流量错峰、分流
访问时间段
熔断
自动熔断
当出现流量洪峰或者后端服务出现延迟或故障时，网关能够主动进行熔断，保护后端服务，并保持前端用户体验良好。
自动恢复
服务降级
限流
限流算法
漏桶算法
令牌桶算法
Gateway 官方提供了 RequestRateLimiter GatewayFilterFactory 过滤器工厂，使用 Redis 和 Lua 脚本
URI 限流
参数限流
IP 限流
限流功能
客户端限流
应用级限流
网关级限流
在某些场景下需要控制客户端的访问次数和访问频率，一些高并发系统有时还会有限流的需求。在网关上可以配置一个阈值，当请求数超过阈值时就直接返回错误而不继续访问后台服务。
安全防护
传输保护
Token机制
签名，加密
权限控制
应用授权
接口权限
统一鉴权
身份认证
一般而言，无论对内网还是外网的接口都需要做用户身份认证，而用户认证在一些规模较大的系统中都会采用统一的单点登录（Single Sign On）系统，如果每个微服务都要对接单点登录系统，那么显然比较浪费资源且开发效率低。API网关是统一管理安全性的绝佳场所，可以将认证的部分抽取到网关层，微服务系统无须关注认证的逻辑，只关注自身业务即可。
监控告警
调用量，最大并发，qps
最大耗时，平均耗时
单机监控
集群监控
报警规则
度量管理(influxdb)
接口状态度量
接口响应时间度量
接口访问量度量
接口异常率
内外网隔离
防护功能
XSS防护
CSRF防护
SQL注入防护
数据脱敏
黑白名单
说明
微服务网关可以使用系统黑名单，过滤HTTP请求特征，拦截异常客户端的请求，例如DDoS攻击等侵蚀带宽或资源迫使服务中断等行为，可以在网关层面进行拦截过滤。比较常见的拦截策略是根据IP地址增加黑名单。在存在鉴权管理的路由服务中可以通过设置白名单跳过鉴权管理而直接访问后端服务资源。
分类
URL黑/白名单
IP黑/白名单
频率限制
频次限制
风控防刷
业务隔离
松耦合
什么是API网关
网关通俗理解（去某公司找煤老板）
统一入口（前端）
鉴权检验（查看邀请函）
动态路由 （转到其它部门可以办的话就转接到相关部门）
包装 （如给请求出具一个访问凭证类似）
不同的解读
API网关是一个服务器，是系统的唯一入口。 从面向对象设计的角度看，它与外观模式类似
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。
API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、协议转换、限流熔断、静态响应处理。
易混淆区分
网桥
2层，数据链路层，跟据mac地址决定转发
工作在数据链路层，在不同或相同类型的LAN之间存储并转发数据帧，必要时进行链路层上的协议转换。可连接两个或多个网络，在其中传送信息包。
路由器
3层，网络层，根据ip地址决定转发。
网关
4层，传输层，根据段口号决定转发。
是一个大概念，不具体特指一类产品，只要连接两个不同的网络都可以叫网关，网桥一般只转发信息，而网关可能进行包装。
为什么（微服务）一定要有API网关？
原因
网络场景
某种情况下需要限制流量
用户增长过快
某个热点事件
竞争对手爬虫
恶意的请求
服务都存在一定的不稳定问题，也就是说如何高可用
... ...
其他背景
部分服务使用的协议不是Web友好协议。可能使用 Thrift 二进制 RPC，也可能使用 AMQP 消息传递协议。
直接暴露：微服务难以重构
... ...
解决了哪些问题
1. 解决 API 放哪里的问题
微服务里面的API不直接对外暴露，否则会出现安全问题
引入网关，在客户端和微服务之间加了一层隔离。
API只需要访问一次网关，再由网关分别访问同在一个机房的不同的服务，再把拿到的数据统一在网关封装好，返回给客户端就好。
2. 解决边缘功能集成的问题
什么是边缘功能
为了系统自身的健壮与安全，以及微服务本身的管理。非业务又很重要的功能，我们统称为边缘功能。
流量过大，系统承载不了了，怎么办
限流：通过令牌桶等算法，把一些额外的流量挡在系统外面，不让其访问。
降级：由于系统可能已经过载了，此时，我们就放弃处理一些服务和页面的请求或者仅简单处理，比如直接返回一个报错。
熔断：有些时候，系统过载过度或者上线出了 bug，影响很大时，会出现一系列负面连锁反应，我们称之为雪崩。而为了防止雪崩，我们就会坚决把缓存失效导致数据库被频繁访问的服务给停掉，这就是熔断
3. 解耦了客户端和后端微服务
一套项目，在使用微服务模式的初期，往往后端变化是十分频繁的,有了网关，进行了解耦
当风控服务本身频繁变化的时候，我们只需要改动网关的代码就好。(服务器代码的升级比客户端代码的升级容易)
网关核心
核心概念
路由(Route)：路由是网关的基本模块，它由ID，目标URI，一系列的断言和过滤器组成
断言(Predicate)：规则判断，true还是false，如果断言为true则匹配该路由
过滤器(Filter)：可以在请求被路由前或者后对请求进行修改（GatewayFilter｜GlobalFilter）
网关的本质
网关的本质应该是对请求进行路由转发，以及对请求进行前置和后置的过滤
API 网关是微服务架构中的基础组件，位于接入层之下和业务服务层之上
请求的转发和路由
接收客户端的所有请求，并将请求转发到后端的微服务中
因为微服务的粒度比较细，所以API网关又类似于门面模式，对多个微服务进行功能整合，提供唯一的业务接口给客户端
过滤
网关会拦截所有的请求来完成一系列的横切工作，比如鉴权、限流
工作原理
基于过滤器实现，有pre和post两种方式的 filter,分别处理前置逻辑和后置逻辑。客户端的请求先经过pre类型的 filter，
然后将请求转发到具体的业务服务，收到业务服务的响应之后，再经过post类型的 filter 处理，最后返回响应到客户端
路由规则
Path
http://localhost:9000/product/1
Query
http://localhost:9000/product/1?token=abc1
Method
Datetime
After｜Before｜Between
RemoteAddr
http://192.168.10.1:9000/product/1
Header
动态路由
动态获取URI
服务名称转发
http://localhost:9000/product-service/product/1
过滤器
网关过滤器
通过 spring.cloud.routes.filters 配置在具体路由下，只作用在当前路由上
通过 spring.cloud.default-filters 配置在全局，作用在所有路由上
全局过滤器
不需要在配置文件中配置，作用在所有的路由上
种类
Header、Parameter、Path、Body、Status、Session、Redirect、Retry、Ratelimiter 和 Hystrix
Path 过滤器
RewritePath GatewayFilter Factory
PrefixPath GatewayFilter Factory
StripPrefix GatewayFilter Factory
SetPath GatewayFilter Factory……
Parameter 参数过滤器
Status 状态过滤器
自定义全局过滤器（重点）
自定义全局过滤器需要实现以下两个接口：Globalfilter，Ordered
通过全局过滤器可以实现权限校验，安全性验证等功能
代码
使用它只需要加上@Component注解
请求过滤
0 条评论
下一页
