网关 架构演进

最近由于工作需要，在看网关相关的文章，今天这篇是关于网关架构演进的，相信能给大家带来很多启发。

1、前言

天翼账号是中国电信打造的互联网账号体系产品，利用中国电信管道优势为企业提供用户身份认证能力。其中网关系统是天翼账号对外能力开放体系的重要组成：业务侧它以集中入口、集中计费、集中鉴权管控为目标，技术侧它支持隔离性、可配置、易开发、动态路由、可降级、高并发等场景。

自 2017 年天翼账号网关系统上线以来，历经数次互联网的营销大促活动，特别是 2021 年的春节红包活动和刚过去双 11 活动，天翼账号网关系统在 10 万级 QPS 和 10 亿级日请求量的情况下，各项指标依然保持平稳，顺利保障合作方活动的开展。在天翼账号产品能力不断提升的背后，是天翼账号网关系统架构技术迭代发展的过程。

2、天翼账号网关演进

2.1 重点演进历程介绍

2017 年~ 2021 年天翼账号网关系统经历数次重要更迭升级，每次升级都给产品带来新的发展机会，系统总体演进过程如下：

2.2 天翼账号网关系统 1.0

2017 年初，天翼账号技术团队基于开源微服务网关 Zuul 组件开展了网关系统 1.0 的建设。Zuul 是 Spring Cloud 工具包 Netflix 分组的开源微服务网关，它和 Eureka、ribbon、hystrix 等组件配合使用，本质是通过一系列的核心 filter，来实现请求过程的认证安全、动态路由、数据转化、熔断保护等功能。其系统核心运行流程如下：

2018 年中，随着天翼账号推出免密认证系列产品的快速发展，网关系统 1.0 的缺点日益凸显主要表现在两个方面：

1. 性能瓶颈: 微服务网关 Zuul 组件基于 Servlet 框架构建，采用的是阻塞和多线程方式实现，高并发下内部延迟严重，会造成连接增多和线程增加等情况，导致阻塞发生，在实际业务应用中单机性能在 1000 QPS 左右。
2. 灵活度有限：为了实现路由和 Filter 动态配置，研发人员需要花费时间去整合开源适配 Zuul 组件控制系统。

为应对业务高峰，技术侧常采用横向扩展实例的策略来实现对高并发的支持，该策略给系统稳定性带来一定的风险，同时部署大量的网关服务器也提高产品的运营维护成本，因此网关系统架构升级迫在眉睫。

2.3 天翼账号网关系统 2.0

2.3.1 技术选型

互联网企业常见的方案有基于 Openresty 的 Kong、Orange，基于 Go 的 Tyk 和基于 Java 的 Zuul：

apiaxle、api-umbrella： 考虑到学习成本和项目后期发展的兼容性，其语言和框架不在团队优先考虑范围

Zuul：目前正在应用中，Zuul 处理请求的方式是针对每个请求都启用一个线程来处理。通常情况下，为了提高性能，所有请求被放到处理队列中，等待空闲线程来处理。当存在大量请求超时后会造成 Zuul 线程阻塞，目前只能通过横向扩展 Zuul 实例实现对高并发的支持。而 Zuul2.0 将 HTTP 请求的处理方式从同步变成了异步，以此提升处理性能。但团队内部对继续采用 Zuul 比较慎重，原因主要有以下两点：

1. 版本稳定性需要斟酌 ，Zuul 的开源社区比较活跃，一直在更新状态
2. 应用企业较少，除了 Netflix，目前 Zuul 在企业中的应用还比较少，性能和稳定性方面还有待观察

Nginx： 高性能的 HTTP 和反向代理 Web 服务器，应用场景涉及负载均衡、反向代理、代理缓存、限流等场景。但 Nginx 作为 Web 容器应用场景较少。Nginx 性能优越，而 Nginx 开发主要是以 C/C++ 模块的形式进行，整体学习和开发成本偏高。Nginx 团队开发了 NginxScript，可以在 Nginx 中使用 JavaScript 进行动态配置变量和动态脚本执行。

目前行业应用非常成熟的扩展是由章亦春将 Lua 和 Nginx 黏合的 ngx_Lua 模块，将 Nginx 核心、LuaJIT、ngx_Lua 模块、多功能 Lua 库和常用的第三方 Nginx 模块整合成为 OpenResty。开发人员安装 OpenResty，使用 Lua 编写脚本，部署到 Nginx Web 容器中运行，能轻松地开发出高性能的 Web 服务。OpenResty 具有高性能，易扩展的特点，成为了团队首选。同时也面临两个选项：

1. 基于 OpenResty 自建，例如：一个类似于某东 JEN 的系统
2. 对开源框架二次开发，例如：Kong、Orange

根据调研结果，团队衡量学习成本和开发周期等因素，最终决定采用对 Kong 框架二次开发的方案。以下是调研后的一些对比总结，仅供参考，如有疏漏，请不吝指出。

2.3.2 架构升级

天翼账号技术团队制定了网关系统 2.0 演进方案，部署架构如图：

• 自研插件

除了 Kong 网关自带的原生组件外，2.0 网关系统还相继研发出：加密鉴权、日志处理、参数转换、接口协议、消息队列、服务稳定、链路追踪及其它等 8 大类共计约 30 多个组件。丰富的自研组件，保障了系统架构平稳的升级和业务的灵活性：

1. 支持产品 Appkey 认证，SSL/TLS 加密，支持针对 IP 或应用的黑、白名单
2. 符合自身业务的协议插件，包括了常见的加密、签名算法和国密 sm2，sm3，sm4 等金融级别的算法
3. 监控和统计方面增加了基于 Redis、Kafka 的异步日志汇聚、统计方式，并支持 Zipkin、Prometheus 的追踪、监控
4. 增加多种按业务精细化分类的限流熔断策略，进一步完善服务保障体系

改造上游

利用 Go 语言的高并发特性，对上游并发量大的微服务进行重构。

2.3.3 效果

网关 2.0 通过对 Kong 组件自研插件的开发和改造，实现了符合产品特性、业务场景的相关功能，也抽象了网关的通用功能。相较于 1.0 版本，具备以下优点：

1. 支持插件化，方便自定义业务开发
2. 支持横向扩展，高性能、高并发、多级缓存
3. 高可用、高稳定性，具备隔离、限流、超时与重试、回滚机制
4. 插件热启用，即插即拔、动态灵活、无需重启，能快速适用业务变化

为了验证新架构的性能，团队对网关系统 2.0 进行了压测：

• 结果 1：17:26 在当前测试环境下 QPS 在 1.2W 左右
• 结果 2：18:06 取消 Prometheus、流量控制、日志、权限校验等插件，QPS 达到 1.3W+

压测结果表明，天翼账号网关系统 2.0 已经达到单机万级 QPS，自研插件运行效率较高，对于网关性能的影响较小。

天翼账号网关系统 2.0 初期是基于 Kong-v0.14.0 版本开发，运行至 2019 年 5 月时，Kong 已经更新到 v1.1.X 版本，有很多重要的功能和核心代码更新，而且为了便于跟 Kubernetes 集成，团队决定将版本升至 v1.1.X。

通过同步迁移、并行运行的方式天翼账号网关系统 2.1 于 2019 年 9 月完成 Kong-v1.3 版本的升级。期间天翼账号网关系统仍平稳地完成了 2018 年阿里双 11 活动、2019 年春节活动等大型高并发场景的支撑工作。2020 年 3 月，网关 2.1 及底层微服务完成了镜像化改造，即可通过 Kubernetes 自动编排容器的方式部署，在动态扩容等方面有较大的提升。

2.4 天翼账号网关系统 3.0

随着免密认证逐渐成为互联网应用作为首选登录方式，互联网头部企业要求认证产品 SLA 相关技术指标对齐其内部指标，为了支撑产品精细化运营和进一步的发展，保障产品 SLA 合同及性能指标，技术团队制定了网关系统 3.0 演进方案。

3.0 网关部署架构图如下：

2.4.1 DP(Data Plane) 升级

2.4.1.1 Kong 组件升级

团队摸余（鱼）工程师对开源项目 Kong 的版本发布一直保持着较高的关注度，总结两年来 Kong 主要版本升级新特性：

考虑到 Kong 2.5.0 版本为刚刚发布的版本，采用的企业用户不多，且开源社区对之前发布的 V2.4.0 版有较好的评价，因此团队评审后决定升级到 V2.4.0。

Kong 2.4.0 采用 OpenResty1.19.3.1，基于 Nginx 1.19.3，官方文档测试单 Worker 可达 269,423 QPS。以 2.0 版本同样环境压测，天翼账号网关系统 3.0（Kong 2.4) QPS 可达到 2W+，对比天翼账号网关 2.X（Kong 1.3) QPS 1W+，性能预估可提升 80% 以上。

Kong 2.4.0 组件采用控制面 / 数据面（CP/DP） 混合部署新模式，具备以下优势：

• 功能解耦

混合部署模式，CP 负责将配置数据推动到 DP 节点，DP 节点负责流量数据处理。

• 运行稳定

当 CP 不可用时，DP 可按照本地存储的配置进行流量业务处理，待 CP 恢复，DP 会自动连接更新配置。

• 支持多语言插件

在原有 Lua 插件的基础上，支持使用 JavaScript 、TypeScript、GO 编写插件，后端 GO 语言团队可进行相关扩展。

• 支持 UDP 代理

Routes、Services、Load Balancing、日志插件支持 UDP 代理，满足业务发展需要。

2.4.1.2 精确网关分组

顶层采用分域名业务隔离，同时根据业务特性、保障级别、访问并发量等特点，对网关集群进行分组，完成子业务关联性解耦，在应对大流量冲击时降低对业务的影响，同时方便运维侧精准扩容。

2.4.1.3 混合云

新建阿里云节点，作为天翼账号产品双活系统的补充节点，在高并发时可由 DNS 调度实现自动切换，确保提供无间断的服务。

2.4.2 CP(Control Plane) 升级

2.4.2.1 优化调用链路

增加 Consul 作为服务发现、配置管理中心服务，替换原有 Nginx 层路由功能。对 Kong 组件提供 DNS 路由及发现服务，通过 Check 方式检查微服务是否可用。

2.4.2.2 新增插件

• DP 缓存控制插件

Kong 2.4 采用 DP 和 CP 混合部署模式，DP 平面的节点无管理端口，原 Kong 1.3 通过 admin API 管理缓存的模式无法适用现有场景，因此研发了 c-cache-manage 插件，添加后，可通过数据层面 URL 请求对 DP 缓存进行管理。

• 流量复制插件

为了测试网关 3.0 的适用性，团队自研流量复制插件，复制现网流量对网关 3.0 进行测试，整个测试过程不影响现网环境。

插件运行流程如下：

Konga 配置界面参考：

• Prometheus 插件改造

为了更好的展示 DP 和 CP 层面的数据，对自带 Prometheus 插件进行改造，增加 DP、CP 角色维度，区分并收集数据平面相关监控指标。

2.4.2.3 完善预警监控

在系统原有的监控的基础上，增加业务处理监控，通过业务处理监控，可将异常被动通知，转为主动发现。业务出现异常，可第一时间协助客户处理，提升系统的效能。

2.4.3 效果

演进完成后天翼账号网关系统 3.0 具备以下优势：

1. 高并发，可支撑十万级 QPS
2. 高可用 ，保障系统 SLA 达到 99.96%
3. 灵活性伸缩性、 DNS 调度自动切换，可通过阿里云 ACK 迅速扩容
4. 丰富开发和应用场景，支持多语言插件（Go、Javascript、Lua), 支持 UDP 代理

天翼账号网关系统 3.0 的部署，有效地保障了系统服务 SLA 等各项指标的达成。在今年双 11 期间十万级并发高峰时，系统 TP99 保持在 20MS 以内，总体表现非常稳定。

3、后序

天翼账号网关经过多次演进，已日趋完善，总结其优势如下：

1. 系统性能大幅度提升，天翼账号网关系统 3.0 相较 1.0 性能提升 20 倍以上
2. 统一网关流量入口，超过 90% 以上流量由天翼账号网关系统管控
3. 系统可用性得到加强，建立了基于 DNS 调度自动切换的三节点、混合云稳定架构
4. 标准化可复用的插件，如频控限流、降级熔断、流量复制、API 协议等标准化插件
5. 丰富的多语言插件能力，Lua、Go、Javascript 的插件，可满足不同技术团队的需求

天翼账号网关系统在中国电信统一账号能力开放平台中处于举足轻重的地位，它的迭代升级，为平台十万级高并发提供了坚实的保障，也为系统维护减少了难度、提升了便捷性，顺利支撑业务达成亿级收入规模。天翼账号技术团队在 follow 业界主流网关技术的同时，也注重强化网关插件的标准化、服务化建设，希望通过网关能力反哺其它产品赋能大网。随着中国电信服务化、容器化、全面上云的战略推进，天翼账号网关的系统架构也将随之变化，从全传统环境到部分云化再到全量上云，不断的向更贴近业务，更适用技术发展的形态演进。