总体演进历程
如上图所示:
API网关1.0(严选Ianus网关)——体系建设
部署架构
严选Ianus网关模块架构图
如上图所示:
Yanxuan-Ianus:数据面组件,承接实际的业务流量。
Yanxuan-Ianus-PGProxy:控制面代理组件,对PostgreSQL写操作进行收敛,而Yanxuan-Ianus只保留只读权限,消除安全隐患。
严选Ianus网关集群拓扑图
物理上对业务进行隔离,避免相互干扰。
集群根据自身业务流量进行容量配比,有利于资源精细化管理。
通过集群方式进行API的配置管理,理解直观、配置清晰。
严选Ianus网关技术栈
Kong原生的配置管理,没有权限控制,没有版本记录,功能缺失较多,无法应用于生产环境。因此,我们对控制面进行了如下增强:
接入严选工单体系,提供统一的配置申请、审核、发布等节点动作,有效地对业务配置需求进行管理,在流程上对配置更新进行管控。
接入严选报警体系,在配置变更时,将变更通知到业务负责人、配置人员、网关运维人员,确保实时感知配置变动,预知风险点。
将配置下发到指定的网关实例节点,进行灰度验证,最小化配置出错的影响范围。
Kong在Openresty上做的一项重大改进,就是对插件的规范,支持了热插拔、配置动态下发等能力。严选扩充了频控插件、路由插件、请求/响应转换插件等30余个,同时也为部分业务定制了功能插件,如AB实验分流插件、登录鉴权插件、身份信息提取插件等。
3. 频控限流能力,根据服务自身的承载能力,在网关侧配置相应阀值,避免业务被突发流量打垮。
基于插件形式扩展,与严选APM体系集成,将网关的请求数据采集到全链路监控体系中,补齐链路节点,消除链路追踪盲点。为避免引入性能损耗,此处基于日志进行异步上报,并且采样率可通过插件配置参数进行调整。
AB实验分流支持
AB实验拓扑图
如上图所示:
网关管理平台对接实验平台,业务在实验平台配置实验后,相应配置会下发到网关。
网关对命中的接口,二次访问实验平台的决策接口,获取具体实验方案。
支持多种方案类型,根据决策平台返回的结果执行对应的方案。
统一严选的API访问入口,超过90%流量跑在严选Ianus网关之上。
统一流量治理,在控制面上与微服务达成统一。
提供标准的容灾能力,如频控、降级、静态化等,从而业务可以进行复用。
充分利用LUA的插件能力,满足业务个性化需求。
在各个ServiceMesh之上,部署自建的边缘网关(Edge Gateway),与数据中心的基础设施集成。云内即推动轻舟将原有Istio服务网格中的Ingress/Egress进行替换,统一到轻舟Envoy网关(即下文的API网关2.0)。
云内云外互访流程图
流量首先由ServiceMesh1.0进行管控,并路由/分流到边缘网关(Ianus OUT)。
边缘网关(Ianus OUT)进行出口流量的权限认证以及路由。
边缘网关(Envoy IN),对流量在SericeMesh2.0中进行正常的路由/分流。
已有跨环境访问,需要SA打通两两IP之间的防火墙。一方面,每次需要对应用服务器IPtable做专门的配置;另一方面,所有互访配置离散到各个应用服务器,无法做集中管控。
这里将跨数据中心的访问流量,统一走到边缘网关,在网关上进行相应的认证鉴权(基于插件实现)。
跨环境网关拓扑图
如上图所示,跨ServiceMesh可以认为是东西向流量,而跨环境可以认为是南北向流量。最终支持了各大环境互访,统一业务访问方式,消除环境差异,并对流量进行集中式管控,方便统一运维!
通过上述工作,我们完成了:
承接了100%的跨ServiceMesh流量。
无缝融合ServiceMesh1.0以及ServiceMesh2.0的流量调配机制,业务不感知流量跨ServiceMesh。
统一了跨环境的认证鉴权,方便集中管控。
通过流量兜底等能力,实现双ServiceMesh热备,支持业务的高可用。
这里跨环境的支持,是云内云外互访落地过程中,根据业务的需求反馈进行整理抽象得到的,进一步扩展了网关的部署架构,丰富了网关体系。
网关选型
上云之初,严选API网关团队也调研对比了Kong、Traefik、Ambassador、Gloo、Istio Gateway等的特性,目标是构建一个云原生的API网关。
云原生API网关选型对比
产品 | Kong | Traefik | Ambassador | Gloo | Istio Gateway |
语言 | Lua | Golang | Python | Golang | Golang |
部署复杂度 | 中等 | 简单 | 简单 | 简单 | 简单 |
依赖 | Cassandra或Postgres,可DBless | V2版本K8S | K8S | K8S | K8S |
开源 | Apache2.0开源 | MIT协议开源 | Apache2.0开源 | Apache2.0开源 | Apache2.0开源 |
核心技术 | Nginx/Lua | Golang | Envoy | Envoy | Envoy |
社区情况 | 大 | 大 | 中 | 中 | 大 |
API认证授权 | 支持 | 支持 | 支持 | 支持 | 支持 |
流控 | 支持 | 支持 | 支持 | 商业版支持 | 基于Envoy全局限流 |
数据转换 | 基于HTTP | 不支持 | 基于HTTP | 基于HTTP | 不支持 |
路由策略 | host,path,method | Host,path | host,head,path | header,queryparam,method,path,function | Host,head,path |
容器集成 | 自带数据面、控制面 | 仅作为网关 | 作为控制面适配Envoy | 作为控制面适配Envoy | 作为控制面适配Envoy |
随着上云的深入,综合考虑后,决定将云内网关建设的任务交给轻舟网关团队负责,严选则从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方案控制面组件,主要负责以下功能:
从注册中心获取服务注册信息,并转换为CDS,EDS下发。
从配置中心获取服务配置信息,并转换为LDS,RDS,CDS下发。
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网关的插件建设效率。
收益启示
通过上述工作,我们实现了:
网关管理平台复用,保证用户习惯一致性。
LUA插件复用,方便扩展功能的无缝迁移。
函数级别路由能力的支持,为后续FaaS的引流铺平了道路。
杨文超,2012年加入网易,资深JAVA开发,致力于服务端的技术研发及方案设计工作,目前在数据平台及风控部,负责严选FaaS平台的建设。主导了网易严选风控系统、网关系统建设。