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

• 容灾能力

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 网关选型对比

随着上云的深入，综合考虑后，决定将云内网关建设的任务交给轻舟网关团队负责，严选则从 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 平台的建设。主导了网易严选风控系统、网关系统建设。