学习总结-网关 架构演进

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

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 服务器，应用场景涉