网易严选的网关架构演进之路_服务革新_杨文超



 写点什么

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

容灾能力

增加了按百分比进行限流的能力，并支持分地域差别处理。
熔断降级能力，按需熔断部分非重点业务接口，保证业务主体功能的稳定。
频控限流能力，根据服务自身的承载能力，在网关侧配置相应阀值，避免业务被突发流量打垮。

链路跟踪
基于插件形式扩展，与严选 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 体系进行共建。