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

部署架构

文章插图
轻舟 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 等的步伐，并不断输出反哺业界和社区，最终成为网关的引领者！