严选网关架构演进之路

原文转载自 「DockOne.io」 ( http://weekly.dockone.io/article/58867 ) By JetLee

预计阅读时间 0 分钟(共 0 个字, 0 张图片, 0 个链接)


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

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

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

总体演进历程

1.png

严选API网关演进图

如上图所示:


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

API网关1.0(严选Ianus网关)——体系建设

经过产品调研和技术选型,我们最终基于Kong构建严选API网关,命名为Ianus,开始了严选API网关的打怪升级之旅!

部署架构

2.png

严选Ianus网关模块架构图

如上图所示:


3.png

严选Ianus网关集群拓扑图

如上图所示,为数据面的具体部署拓扑,通过合理的集群规划,可以做到:


数据面建设

4.png

严选Ianus网关技术栈

如上图所示,数据面具体技术栈实现为:


控制面建设

Kong原生的配置管理,没有权限控制,没有版本记录,功能缺失较多,无法应用于生产环境。因此,我们对控制面进行了如下增强:


插件能力建设

Kong在Openresty上做的一项重大改进,就是对插件的规范,支持了热插拔、配置动态下发等能力。严选扩充了频控插件、路由插件、请求/响应转换插件等30余个,同时也为部分业务定制了功能插件,如AB实验分流插件、登录鉴权插件、身份信息提取插件等。


5.png

AB实验拓扑图

如上图所示:


收益启示

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


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

API网关1.5时代——边缘网关

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

为方便介绍,如下描述中“云外”代表Service Mesh 1.0,“云内”代表Service Mesh 2.0。

跨Service Mesh访问

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

云内云外互访流程图

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


跨环境访问

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

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

跨环境网关拓扑图

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

收益启示

通过上述工作,我们完成了:


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

API网关2.0(轻舟Envoy网关)——云原生

网关选型

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

云原生API网关选型对比

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

部署架构

9.png

轻舟Envoy网关模块架构图

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

数据面建设

10.png

基于轻舟的微服务架构

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

控制面建设

11.png

网关管理平台配置架构

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

轻舟Envoy网关配置下发链路

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


严选Service Mesh 2.0解决方案中,Pilot分饰两角,一个作为网格内服务控制面,另一个作为网关服务控制面。

插件能力建设

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

Envoy原生插件

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

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

LUA扩展插件

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

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

收益启示

通过上述工作,我们实现了:


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

总结

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

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

原文链接:https://mp.weixin.qq.com/s/4r0vVSQFw6tp5c7KyMzx3w
more_vert