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

本文插图

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

本文插图

如上图所示：
ServiceMesh1.0：严选自研的基于Consul+Nginx的服务网格，解决了内部微服务之间的流量治理问题，统一了严选微服务体系。 API网关1.0：即严选Ianus网关，解决了外部对服务访问的流量治理问题，并经受住了多次大促流量的考验。
ServiceMesh2.0：严选的服务网格进化为网易轻舟（下文简称轻舟）的基于Istio的服务网格架构，支持更丰富的流量管控能力。边缘网关：在流量迁移到轻舟过程中， API网关角色就转变为边缘网关，负责跨云的流量管控，这里也推进了云内边缘网关的建设。
API网关2.0：即轻舟Envoy网关，此时数据面抛弃了API网关1.0版本，与轻舟一起建设基于Envoy的云原生API网关。
2API网关1.0（严选Ianus网关）——体系建设
经过产品调研和技术选型，我们最终基于Kong构建严选API网关，命名为Ianus ，开始了严选API网关的打怪升级之旅！
部署架构

本文插图

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

本文插图

如上图所示，为数据面的具体部署拓扑，通过合理的集群规划，可以做到：
物理上对业务进行隔离，避免相互干扰。
集群根据自身业务流量进行容量配比，有利于资源精细化管理。
通过集群方式进行API的配置管理，理解直观、配置清晰。
数据面建设

本文插图

如上图所示，数据面具体技术栈实现为：
Nginx：以Openresty主版本依赖为准，扩充引入所需的功能模块，其中consul-module用于集成Consul ，统一到严选Servicemesh1.0的服务治理体系中；vts-module用于统计监控信息的采集。
Openresty：直接引入官方的稳定版本，不做额外变更。
Yanxuan-Kong：引入Kong的主干版本，并进行额外的功能扩展，包括参数路由、集群管理、租户管理、灰度发布等等。
Yanxuan-Ianus：所有扩展功能插件均在此管理，适配微服务形态的地址路由等。
控制面建设
Kong原生的配置管理，没有权限控制，没有版本记录，功能缺失较多，无法应用于生产环境。因此，我们对控制面进行了如下增强：
版本信息管理
在现有配置基础之上，包装了基于MongoDB的配置管理，支持历史版本的回溯、版本回退、版本比较等功能。有效地避免了配置出错导致的无法回滚，或回滚不方便等问题。
标准化配置流程
接入严选工单体系，提供统一的配置申请、审核、发布等节点动作，有效地对业务配置需求进行管理，在流程上对配置更新进行管控。
接入严选报警体系，在配置变更时，将变更通知到业务负责人、配置人员、网关运维人员，确保实时感知配置变动，预知风险点。
灰度发布功能
将配置下发到指定的网关实例节点，进行灰度验证，最小化配置出错的影响范围。
插件能力建设
Kong在Openresty上做的一项重大改进，就是对插件的规范，支持了热插拔、配置动态下发等能力。严选扩充了频控插件、路由插件、请求/响应转换插件等30余个，同时也为部分业务定制了功能插件，如AB实验分流插件、登录鉴权插件、身份信息提取插件等。
容灾能力
增加了按百分比进行限流的能力，并支持分地域差别处理。
熔断降级能力，按需熔断部分非重点业务接口，保证业务主体功能的稳定。
频控限流能力，根据服务自身的承载能力，在网关侧配置相应阀值，避免业务被突发流量打垮。
链路跟踪基于插件形式扩展，与严选APM体系集成，将网关的请求数据采集到全链路监控体系中，补齐链路节点，消除链路追踪盲点。为避免引入性能损耗，此处基于日志进行异步上报，并且采样率可通过插件配置参数进行调整。
AB实验分流支持
AB实验本身包括了多个方面的实验，而网关侧负责对入口流量的分流实验进行落地。

本文插图

1、网关管理平台对接实验平台，业务在实验平台配置实验后，相应配置会下发到网关。
2、网关对命中的接口，二次访问实验平台的决策接口，获取具体实验方案。
3、支持多种方案类型，根据决策平台返回的结果执行对应的方案。
收益启示
经过严选Ianus网关的体系建设，我们初步达成了：
1、统一严选的API访问入口，超过90%流量跑在严选Ianus网关之上。
2、统一流量治理，在控制面上与微服务达成统一。
3、提供标准的容灾能力，如频控、降级、静态化等，从而业务可以进行复用。
4、充分利用LUA的插件能力，满足业务个性化需求。
期间线上问题进行实时的总结归档，比如Nginx的配置使用问题， Kong的版本跟踪问题， PostgreSQL的优化等等。实际落地过程中，我们没有局限于网关，而是着眼于严选微服务体系的建设。
3API网关1.5时代——边缘网关
随着ServiceMesh从1.0向2.0演进，过渡期会存在ServiceMesh1.0（严选VM）与ServiceMesh2.0(轻舟K8S)两种类型的ServiceMesh共存的情形，自然面临两个ServiceMesh间的流量调拨问题。
为方便介绍，如下描述中"云外"代表ServiceMesh1.0 ， "云内"代表ServiceMesh2.0 。
跨ServiceMesh访问
在各个ServiceMesh之上，部署自建的边缘网关（EdgeGateway），与数据中心的基础设施集成。云内即推动轻舟将原有Istio服务网格中的Ingress/Egress进行替换，统一到轻舟Envoy网关（即下文的API网关2.0）。

本文插图

如上图所示，云外采用严选Ianus网关进行部署，云内采用轻舟Envoy进行部署。以云外访问云内为例：
1、流量首先由ServiceMesh1.0进行管控，并路由/分流到边缘网关（IanusOUT）。
2、边缘网关（IanusOUT）进行出口流量的权限认证以及路由。
3、边缘网关（EnvoyIN），对流量在SericeMesh2.0中进行正常的路由/分流。
跨环境访问
已有跨环境访问，需要SA打通两两IP之间的防火墙。一方面，每次需要对应用服务器IPtable做专门的配置；另一方面，所有互访配置离散到各个应用服务器，无法做集中管控。
这里将跨数据中心的访问流量，统一走到边缘网关，在网关上进行相应的认证鉴权（基于插件实现）。

本文插图
【网易|网易严选的网关架构演进之路】

如上图所示，跨ServiceMesh可以认为是东西向流量，而跨环境可以认为是南北向流量。最终支持了各大环境互访，统一业务访问方式，消除环境差异，并对流量进行集中式管控，方便统一运维！
收益启示
通过上述工作，我们完成了：
1、承接了100%的跨ServiceMesh流量。
2、无缝融合ServiceMesh1.0以及ServiceMesh2.0的流量调配机制，业务不感知流量跨ServiceMesh 。
3、统一了跨环境的认证鉴权，方便集中管控。
4、通过流量兜底等能力，实现双ServiceMesh热备，支持业务的高可用。
这里跨环境的支持，是云内云外互访落地过程中，根据业务的需求反馈进行整理抽象得到的，进一步扩展了网关的部署架构，丰富了网关体系。
4API网关2.0（轻舟Envoy网关）——云原生
网关选型
上云之初，严选API网关团队也调研对比了Kong、Traefik、Ambassador、Gloo、IstioGateway等的特性，目标是构建一个云原生的API网关。

本文插图

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

本文插图

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

本文插图

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

本文插图

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

本文插图

如上图所示，为整个控制面的下发链路，主要组件包括：
APIGatewayAdmin
严选网关管理平台，集成到现有的网关管理平台中，通过数据中心（严选|轻舟）的切换，实现两边配置的管理，对外展示表现完全一致。
APIPlane
轻舟Envoy网关控制面配置适配层，负责接收配置数据（严选API配置模型），转化格式（对应到Istio模型），并存储到K8SConfigStore 。严选负责严选适配组件的扩展开发，轻舟负责基础功能的实现。主要功能包括，网关集群获取、后端服务列表获取、插件列表/详情获取、API创建/删除等。最终发布时，将轻舟侧代码反向同步到严选侧的GIT上，统一到严选的发布体系中。
IstioPilot
Pilot作为IstioServiceMesh方案控制面组件，主要负责以下功能：
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网关体系，这也是我们未来的发展方向。
5总结
API网关1.0（严选Ianus网关）在过去两年的时间中发挥的作用是举足轻重的，并且在整个严选业务迁移上云的过程中也承载着核心流量调度管控。同时在API网关2.0（轻舟Envoy网关）崛起的过程中， Ianus网关也给出了有价值的参考，如插件体系的建设等。在接下来的道路中， API网关2.0将持续跟进云原生、Serverless等的步伐，并不断输出反哺业界和社区，最终成为网关的引领者！
作者简介：
杨文超， 2012年加入网易，资深Java开发，致力于服务端的技术研发及方案设计工作，目前在数据平台及风控部，负责严选FaaS平台的建设。主导了网易严选风控系统、网关系统建设。
点个在看少个bug

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

推荐阅读

青岛晚报官微|“老赖”看过来：这十起拒执案件中的被执行人，全进去了

长安号|秦岭峪口“摆渡人”，西安长安区：热心服务暖人心

“加长版”卡罗拉曝光！配2.0L发动机，油耗仅5.7L，或卖14万元起

大官主|朱棣是如何对待他的妻儿的？，朱允炆下落不明后

南柯影视解析|储户迎来好消息，存款抓住机会，银行存款利率创下近年来最高纪录

鳕鱼胶：鳕鱼胶与花胶有哪些区别

「美国」赵立坚转发华春莹推文，美国抗议活动蔓延70城，警长加入游行队伍

每日经济新闻|美国药管局PK特朗普？特朗普炮轰药管局：有人密谋针对我，或大选后才有疫苗！

『考研』一次性清退1300多人！读研比考研还难？

香酥酱鸭腿

吃什么容易减脂肪,吃什么食物减脂肪最有效呢

玩吧币能怎么领取

谈说历史|良民屈打成招，凶手自行投案，县官罢黜入狱，糊涂官糊涂审案

我发现不不善于解决问题，不会处理人际关系，做事的能力差，该咋做?希望各位能给出一些好的建议，谢谢

「清歌说养身」三高患者只能吃素？营养专家：错了！这3种肉反而是“三高克星”

小予说时尚|早秋该怎么穿？看这一篇就够了！

股价|第三代半导体持续火热！A股24只个股一览，一股流通市值达1072亿

张医生说妇科|长期嗜酒的人，突然戒掉了“酒瘾”，身体会有怎样的变化？

夷陵之战为什么刘备败了?夷陵之战刘备兵败原因_3

求助……我的腿该咋办……梨形身材……