网易严选的网关架构演进之路 _网关架构

严选自 2016 年诞生以来，不论从业务、技术还是体量，每年都在飞速发展。而作为严选对外服务的总入口，网关承接了主要的业务流量，保障着严选业务的稳定运行，并帮助业务进行更好的容灾和降级。
随着服务化、容器化的演进，严选 API 网关也转变角色，作为严选边缘网关，协助业务进行无感知的流量迁移。最后，严选 API 网关统一到了基于云原生的轻舟 Envoy API 网关，不断往更高级的形态演进。
总体演进历程

文章插图
严选 API 网关演进图
如上图所示：

Service Mesh1.0：严选自研的基于 Consul+Nginx 的服务网格，解决了内部微服务之间的流量治理问题，统一了严选微服务体系。
API 网关 1.0：即严选 Ianus 网关，解决了外部对服务访问的流量治理问题，并经受住了多次大促流量的考验。
Service Mesh2.0：严选的服务网格进化为网易轻舟（下文简称轻舟）的基于 Istio 的服务网格架构，支持更丰富的流量管控能力。
边缘网关：在流量迁移到轻舟过程中，API 网关角色就转变为边缘网关，负责跨云的流量管控，这里也推进了云内边缘网关的建设。
API 网关 2.0：即轻舟 Envoy 网关，此时数据面抛弃了 API 网关 1.0 版本，与轻舟一起建设基于 Envoy 的云原生 API 网关。

API 网关 1.0（严选 Ianus 网关）——体系建设经过产品调研和技术选型，我们最终基于 Kong 构建严选 API 网关，命名为 Ianus，开始了严选 API 网关的打怪升级之旅！
部署架构

文章插图
严选 Ianus 网关模块架构图
如上图所示：

Yanxuan-Ianus：数据面组件，承接实际的业务流量。
Yanxuan-Ianus-PGProxy：控制面代理组件，对 PostgreSQL 写操作进行收敛，而 Yanxuan-Ianus 只保留只读权限，消除安全隐患。
Yanxuan-Ianus-Admin：控制面组件，提供完整的 API 配置、插件配置等操作。

文章插图
严选 Ianus 网关集群拓扑图
如上图所示，为数据面的具体部署拓扑，通过合理的集群规划，可以做到：

物理上对业务进行隔离，避免相互干扰。
集群根据自身业务流量进行容量配比，有利于资源精细化管理。
通过集群方式进行 API 的配置管理，理解直观、配置清晰。

数据面建设

文章插图
严选 Ianus 网关技术栈
如上图所示，数据面具体技术栈实现为：

Nginx：以 Openresty 主版本依赖为准，扩充引入所需的功能模块，其中 consul-module 用于集成 Consul，统一到严选 Servicemesh1.0 的服务治理体系中；vts-module 用于统计监控信息的采集。
Openresty：直接引入官方的稳定版本，不做额外变更。
Yanxuan-Kong：引入 Kong 的主干版本，并进行额外的功能扩展，包括参数路由、集群管理、租户管理、灰度发布等等。
Yanxuan-Ianus：所有扩展功能插件均在此管理，适配微服务形态的地址路由等。

控制面建设Kong 原生的配置管理，没有权限控制，没有版本记录，功能缺失较多，无法应用于生产环境。因此，我们对控制面进行了如下增强：

版本信息管理

在现有配置基础之上，包装了基于 MongoDB 的配置管理，支持历史版本的回溯、版本回退、版本比较等功能。有效地避免了配置出错导致的无法回滚，或回滚不方便等问题。

标准化配置流程

接入严选工单体系，提供统一的配置申请、审核、发布等节点动作，有效地对业务配置需求进行管理，在流程上对配置更新进行管控。
接入严选报警体系，在配置变更时，将变更通知到业务负责人、配置人员、网关运维人员，确保实时感知配置变动，预知风险点。

灰度发布功能

将配置下发到指定的网关实例节点，进行灰度验证，最小化配置出错的影响范围。
插件能力建设Kong 在 Openresty 上做的一项重大改进，就是对插件的规范，支持了热插拔、配置动态下发等能力。严选扩充了频控插件、路由插件、请求 / 响应转换插件等 30 余个，同时也为部分业务定制了功能插件，如 AB 实验分流插件、登录鉴权插件、身份信息提取插件等。