从Kong到Envoy，网易严选网关架构演进之路

古语有云「一夫当关，万夫莫开 」,网易严选网关除了提供丰富的功能满足业务多样性的需求之外，更重要的是保证稳定、可靠和高效，我们的架构演进也是围绕这一核心目标进行。这两年随着严选云原生架构的逐步落地，我们也实践通过拥抱云利用云来更好的保证网关的稳定性。

 

网易严选自2016年诞生以来，不论从业务、技术还是体量，每年都在飞速发展。而作为严选对外服务的总入口，网关承接了主要的业务流量，保障着严选业务的稳定运行，并帮助业务进行更好的容灾和降级。

随着服务化、容器化的演进，严选API网关也转变角色，作为严选边缘网关，协助业务进行无感知的流量迁移。最后，严选API网关统一到了基于云原生的网易轻舟Envoy API网关，不断往更高级的形态演进。

总体演进历程

严选API网关演进图

 

如上图所示：

• ServiceMesh1.0：严选自研的基于Consul+Nginx的服务网格，解决了内部微服务之间的流量治理问题，统一了严选微服务体系。

• API网关1.0：即严选Ianus网关，解决了外部对服务访问的流量治理问题，并经受住了多次大促流量的考验。

• ServiceMesh2.0：严选的服务网格进化为网易轻舟（下文简称轻舟）的基于Istio的服务网格架构，支持更丰富的流量管控能力。

• 边缘网关：在流量迁移到轻舟过程中，API网关角色就转变为边缘网关，负责跨云的流量管控，这里也推进了云内边缘网关的建设。

• API网关2.0：即轻舟Envoy网关，此时数据面抛弃了API网关1.0版本，与轻舟一起建设基于Envoy的云原生API网关。

SeviceMesh的演进之前已经由其它同事分享过，这里不再详述，感兴趣的童鞋可以移步架构不止-严选Service Mesh架构的持续演进查看。

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实验分流插件、登录鉴权插件、身份信息提取插件等。

• 容灾能力

1. 增加了按百分比进行限流的能力，并支持分地域差别处理。

2. 熔断降级能力，按需熔断部分非重点业务接口，保证业务主体功能的稳定。

3. 频控限流能力，根据服务自身的承载能力，在网关侧配置相应阀值，避免业务被突发流量打垮。

• 链路跟踪

基于插件形式扩展，与严选APM体系集成，将网关的请求数据采集到全链路监控体系中，补齐链路节点，消除链路追踪盲点。为避免引入性能损耗，此处基于日志进行异步上报，并且采样率可通过插件配置参数进行调整。

• AB实验分流支持

AB实验本身包括了多个方面的实验，而网关侧负责对入口流量的分流实验进行落地。

AB实验拓扑图

如上图所示：

1. 网关管理平台对接实验平台，业务在实验平台配置实验后，相应配置会下发到网关。

2. 网关对命中的接口，二次访问实验平台的决策接口，获取具体实验方案。

3. 支持多种方案类型，根据决策平台返回的结果执行对应的方案。

收益启示

经过严选Ianus网关的体系建设，我们初步达成了：

1. 统一严选的API访问入口，超过90%流量跑在严选Ianus网关之上。

2. 统一流量治理，在控制面上与微服务达成统一。

3. 提供标准的容灾能力，如频控、降级、静态化等，从而业务可以进行复用。

4. 充分利用LUA的插件能力，满足业务个性化需求。

期间线上问题进行实时的总结归档，比如Nginx的配置使用问题，Kong的版本跟踪问题，PostgreSQL的优化等等。实际落地过程中，我们没有局限于网关，而是着眼于严选微服务体系的建设。

API网关1.5时代 - 边缘网关

随着ServiceMesh从1.0向2.0演进，过渡期会存在ServiceMesh1.0（严选VM）与ServiceMesh2.0(轻舟K8S)两种类型的ServiceMesh共存的情形，自然面临两个ServiceMesh间的流量调拨问题。

为方便介绍，如下描述中“云外”代表ServiceMesh1.0，“云内”代表ServiceMesh2.0。

跨ServiceMesh访问

在各个ServiceMesh之上，部署自建的边缘网关（Edge Gateway），与数据中心的基础设施集成。云内即推动轻舟将原有Istio服务网格中的Ingress/Egress进行替换，统一到轻舟Envoy网关（即下文的API网关2.0）。

云内云外互访流程图

如上图所示，云外采用严选Ianus网关进行部署，云内采用轻舟Envoy进行部署。以云外访问云内为例：

1. 流量首先由ServiceMesh1.0进行管控，并路由/分流到边缘网关（Ianus OUT）。

2. 边缘网关（Ianus OUT）进行出口流量的权限认证以及路由。

3. 边缘网关（Envoy IN），对流量在SericeMesh2.0中进行正常的路由/分流。

跨环境访问

已有跨环境访问，需要SA打通两两IP之间的防火墙。一方面，每次需要对应用服务器IPtable做专门的配置；另一方面，所有互访配置离散到各个应用服务器，无法做集中管控。

这里将跨数据中心的访问流量，统一走到边缘网关，在网关上进行相应的认证鉴权（基于插件实现）。

跨环境网关拓扑图

如上图所示，跨ServiceMesh可以认为是东西向流量，而跨环境可以认为是南北向流量。最终支持了各大环境互访，统一业务访问方式，消除环境差异，并对流量进行集中式管控，方便统一运维！

收益启示

通过上述工作，我们完成了：

1. 承接了100%的跨ServiceMesh流量。

2. 无缝融合ServiceMesh1.0以及ServiceMesh2.0的流量调配机制，业务不感知流量跨ServiceMesh。

3. 统一了跨环境的认证鉴权，方便集中管控。

4. 通过流量兜底等能力，实现双ServiceMesh热备，支持业务的高可用。

这里跨环境的支持，是云内云外互访落地过程中，根据业务的需求反馈进行整理抽象得到的，进一步扩展了网关的部署架构，丰富了网关体系。

API网关2.0（轻舟Envoy网关）- 云原生

网关选型

上云之初，严选API网关团队也调研对比了Kong、Traefik、Ambassador、Gloo、Istio Gateway等的特性，目标是构建一个云原生的API网关。

云原生API网关选型对比

产品	Kong	Traefik	Ambassador	Gloo	Istio Gateway
语言	Lua	Golang	Python	Golang	Golang
部署复杂度	中等	简单	简单	简单	简单
依赖	Cassandra或Postgres，可DBless	V2版本K8S	K8S	K8S	K8S
开源	Apache2.0开源	MIT协议开源	Apache2.0开源	Apache2.0开源	Apache2.0开源
核心技术	Nginx/Lua	Golang	Envoy	Envoy	Envoy
社区情况	大	大	中	中	大
API认证授权	支持	支持	支持	支持	支持
流控	支持	支持	支持	商业版支持	基于Envoy全局限流
数据转换	基于HTTP	不支持	基于HTTP	基于HTTP	不支持
路由策略	host, path, method	Host,path	host, head, path	header, queryparam, method, path,function	Host, head, path
容器集成	自带数据面、控制面	仅作为网关	作为控制面适配Envoy	作为控制面适配Envoy	作为控制面适配Envoy

随着上云的深入，综合考虑后，决定将云内网关建设的任务交给轻舟网关团队负责，严选则从API网关的需求以及当前的工程建设规划出发，给出设计和建议。数据面部分，考虑了现有轻舟微服务体系的无缝融合以及主流的产品实现，选型采用了Envoy进行数据面的建设；控制面部分，考虑到严选需要复用现有管理平台的功能，则基于现有的Istio体系进行共建。

部署架构

轻舟Envoy网关模块架构图

如上图所示，整体分为控制面和数据面两部分。数据面由双方共建设计方案，落地交由轻舟负责；控制面严选跟轻舟共建，统一到已有严选API网关管理平台。而具体数据面集群的规划，沿用了严选Ianus网关的部署方式，在此不再赘述。

数据面建设

基于轻舟的微服务架构

如上图所示，数据面在选型时，对流量是否要经过网关和Sidecar两层进行了权衡，从简化调用链路，网关与Sidecar角色差异考虑，采用了绕过Sidecar的模式。此时网关部分功能与Sidecar功能虽有重合，但与ServiceMesh保持了独立，可各自演进。当前支持的基础功能包括：默认路由能力、版本分流能力、兜底路由能力等。特别地，对请求流量治理时，需要同时考虑ServiceMesh跟API网关的控制指令下发。

控制面建设

网关管理平台配置架构

如上图所示，为了保持严选API网关产品的一致性，轻舟的控制面最终需要跟当前严选API网关的管理平台功能对齐，复用严选Ianus网关管理平台的能力，包括配置管理、API发布管控等等，确保用户体验的一致性！

轻舟Envoy网关配置下发链路

如上图所示，为整个控制面的下发链路，主要组件包括：

• API Gateway Admin

严选网关管理平台，集成到现有的网关管理平台中，通过数据中心（严选|轻舟）的切换，实现两边配置的管理，对外展示表现完全一致。

• API Plane

轻舟Envoy网关控制面配置适配层，负责接收配置数据（严选API配置模型），转化格式（对应到Istio模型），并存储到K8S Config Store。严选负责严选适配组件的扩展开发，轻舟负责基础功能的实现。主要功能包括，网关集群获取、后端服务列表获取、插件列表/详情获取、API创建/删除等。最终发布时，将轻舟侧代码反向同步到严选侧的GIT上，统一到严选的发布体系中。

• Istio Pilot

Pilot作为Istio ServiceMesh方案控制面组件，主要负责以下功能：

1. 从注册中心获取服务注册信息，并转换为CDS，EDS下发。

2. 从配置中心获取服务配置信息，并转换为LDS，RDS，CDS下发。

3. Envoy静态配置的生成以及生命周期的管理。

严选ServiceMesh2.0解决方案中，Pilot分饰两角，一个作为网格内服务控制面，另一个作为网关服务控制面。

插件能力建设

为支持严选Ianus网关长期的演进迁移到轻舟Envoy网关，同时参考了Kong和Envoy已有的插件能力进行落地。

Envoy原生插件

原生Envoy单个功能插件的开发，涉及到整个配置链路多模块变更，丧失了插件可扩展性的优势。

落地时，对插件配置的转换进行了规范，归一到Schema上来，后端根据该Schema进行统一的Istio资源转换，前端管理平台根据Schema进行统一的配置页面渲染。开发成本缩减到一个模块，扩展优势得到体现。

LUA扩展插件

严选Ianus网关下，基于Kong的LUA插件扩展能力，已经实现了较丰富的功能插件，如果直接切换到轻舟Envoy网关，则原有的插件都需要按照新的规范重新开发。

在Envoy现有插件的基础上，扩充LUA插件开发的能力。严选侧总结分享Kong现有的插件开发实践，为Envoy下LUA插件的规范提供参考，最终保证两者上手的差异最小化。落地迁移时，基本复用了严选Ianus网关的插件代码，插件迁移代价（不论是开发还是测试）非常低，提高了轻舟Envoy网关的插件建设效率。

收益启示

通过上述工作，我们实现了：

1. 网关管理平台复用，保证用户习惯一致性。

2. LUA插件复用，方便扩展功能的无缝迁移。

3. 函数级别路由能力的支持，为后续FaaS的引流铺平了道路。

整个控制面共建过程，Kong与Envoy两个技术栈取长补短，共同打造了基于云原生的轻舟Envoy网关体系，这也是我们未来的发展方向。

总结

API网关1.0（严选Ianus网关）在过去两年的时间中发挥的作用是举足轻重的，并且在整个严选业务迁移上云的过程中也承载着核心流量调度管控。同时在API网关2.0（轻舟Envoy网关）崛起的过程中，Ianus网关也给出了有价值的参考，如插件体系的建设等。在接下来的道路中，API网关2.0将持续跟进云原生、Serverless等的步伐，并不断输出反哺业界和社区，最终成为网关的引领者！

 

作者简介

杨文超，2012年加入网易，资深JAVA开发，致力于服务端的技术研发及方案设计工作，目前在数据平台及风控部，负责严选FaaS平台的建设。主导了网易严选风控系统、网关系统建设。

 

本文由严选技术团队授权发布