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

  • 熔断降级能力,按需熔断部分非重点业务接口,保证业务主体功能的稳定 。
  • 频控限流能力,根据服务自身的承载能力,在网关侧配置相应阀值,避免业务被突发流量打垮 。
    • 链路跟踪
      基于插件形式扩展,与严选 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 体系进行共建 。


    推荐阅读