为什么我们需要全能力云原生网关？（virtual slime）

作为现代云原生业务数据流转的重要通道，网关在行业数字化转型中发挥着日益重要的价值。网易数帆自 2017 年开始探索基于 Envoy 的云原生网关，并实现在互联网、金融等多个领域推广和规模化落地。本文结合网易数帆近期在金融场景下的实践，分享团队对于云原生网关建设的最新思考，以及在业务场景下解决用户痛点的方案与心得。要点如下：

网关能为业务带来什么价值；
网易数帆如何建设云原生网关；
云原生网关在金融场景如何解决业务痛点，及落地经验分享；
云原生网关的后续发展。
网关的背景与价值

在微服务场景下，服务之间的调用错综复杂。微服务如果需要一些治理能力，要么自己实现治理能力，比如认证、限流缓存等；要么借助一些第三方 SDK 提供，以 Spring Cloud 体系为主。

这种架构带来了业务不够聚焦的问题，微服务除了要关注自己的业务逻辑，还需要关注如何实现一些治理的诉求。网易数帆认为，可以将这部分逻辑上移，将治理能力通用化，并提供统一的可观测、监控追踪体系。这就是在微服务场景下网关的意义。在微服务场景下，网关可以简化架构；可以提供统一的安全方案，包括不限于认证鉴权、黑白名单控制；可以提供通用的监控能力，监控系统的运行；还可以提供灵活的通信协议。

云原生场景对网关提出了更高的要求，主要包括 6 个方面：

服务发现方式：和传统的静态发现方式相比，需要具备更灵活的动态服务发现方式，包括不限于对接到 K8s，以及 Eureka、Nacos 等微服务注册中心；
更卓越的性能：随着 K8s 以及服务网格化的微服务体系，网关的卓越性能可以减少整个链路的 RT；
云原生架构兼容：网关的部署架构是否可以无缝和容器以及微服务场景下的服务网格，云原生可观测 SkyWalking、Prometheus 进行对接；
动态配置：云原生场景下，代理的配置变化更加频繁，服务的实例地址，服务的连接池配置、重试策略等频繁变更，动态配置的下发能力尤为关键；
部署形态与架构：是否能够支持在云场景下快速弹性，是否能够支持从业务混部到独立部署的快速迁移能力；
监控追踪体系：良好的可观测便于运维人员快速定位问题。

网易数帆云原生网关架构

网易数帆云原生网关以 Envoy 为数据引擎。我们与 Envoy 结缘始于 sidecar 体系，Envoy 具有出色的代理性能，其 xDS 协议支持动态配置，并提供一系列 filter-chain，用于扩展，还可对接多种可观测系统，提供良好的指标体系以及日志体系，因而可以成为优秀的数据引擎。

在 2019 年，我们基于 Envoy 扩展调用链，提供细粒度指标，提供 Dubbo filter, soap filter，建设高性能微服务网关，用以替代网易集团内一些 Java 异步网关、一些同步网关的迁移，为集团业务容器化改造提供通用的流量入口支持。

在网易集团，需要使用网关数据面引擎的场景，主要有如下三类：

存量网关迁移：如果项目已存在一些网关，存在一些性能、可观察、可扩展的痛点，需要进行网关基础组件的升级；
云原生改造：在东西向流量进行云原生容器化改造，希望网关能够纳管容器流量，同时可以兼容后续微服务体系服务网格化；
多流量管理：不仅仅承接南北向流量，希望网关可以实现云内云外互通，多云管理的统一治理。

此时的网关，可以称为“微服务网关”。而随着业务的发展，业务对网关的诉求已不仅仅在微服务场景，因此我们逐步建设全能力云原生网关，主要有四点目标：

通用流量治理：网关不仅仅是微服务流量的入口，还要成为安全网关、流量网关、通用总线等全能力 7 层流量治理平台。
异构服务接入：越来越多的微服务场景不仅仅局限在某一个协议的治理，网关应该能够提供一种通用的协议转换能力。这里包括两层含义，第一是暴露通用的协议，作为流量入口，第二是支持协议转换互转、协议互调。
多数据源支持：不仅支持容器以及虚拟机服务的接入，还支持微服务体系的多注册中心的数据源接入。
自主可控：在当前复杂形势下，云原生网关需要能够运行在国产化操作系统，能够支持对接国产化中间件。

基于全能力网关的目标，网易数帆建设全能力融合云原生网关体系，其架构如下：

全能力云原生网关能力的设计，不局限于微服务网关，还能够支持通用 7 层流量，支持 Dubbo、gRPC、webservice 等多协议流量；可对接多数据源，已支持 Eureka/Nacos/ZK/Consul 的微服务注册中心；支持通用协议的互转；提供 40 余个内置插件，且支持灵活的通用插件扩展；提供丰富的可观测能力，可支持方法级别的观测体系；同时作为企业级网关支持多租户能力。

金融场景的落地实践经验

以下通过六个案例，分享网易数帆全能力云原生网关在金融场景下的落地实践经验与心得。

案例一：私有协议扩展

第一个案例是私有协议扩展，越来越多的大型证券，头部银行金融企业，要求核心交易系统具备协议私有化，自主可控的能力。主要有 2 点诉求，要求能够支持统一的协议入口，作为端网关暴露。

基于此，网易数帆对于入口网关提供统一方案。其架构如下：

复用 Envoy 的良好引擎，通过 http connection manager 通过 listener，我们提供通用的 geneirc filter 能力，实现 HTTP- 私有协议的编解码；提供通用的 bridge，作用在 router 模块之间。可以把已有的请求、响应插件链进行复用。当出现一个新的协议，只需要通过标准的 DSL 定义协议转换的定义，编写协议转换的编解码即可。聚焦在转换配置下发，我们抽象插件链的实现，不需要侵入到核心的链路，通过简单声明式的 EnvoyPlugin 的配置，即可以完成将协议转换配置下发到 Envoy 的 per-filter-config 中进行生效。

不局限在南北向入口，诉求中还会存在协议互转的诉求，在一些中台业务之间的互相调用，能够支持协议互转。这种场景下，无法复用 http connection manager 的能力。如果要在现有的基础上扩展，需要完备的实现一套 network filter，类似现在社区的 dubbo proxy 能力。考虑到这样完整的实现有比较高的代价。

大部分的 RPC 协议都有类似的请求 / 响应的架构体系。请求阶段，根据不同的请求属性将请求路由到不同的上游服务。对于这些相似的协议，一个功能完备的 network filter 可以被抽象为下面的几个模块：

编解码器：将二进制文件解析为请求 / 响应对象；
流管理：处理请求 / 响应的关系并管理其声明周期；
路由：基于请求的属性，路由到不同的上游服务；
L7 filter 链：对请求和响应进行处理的过滤器；
观测：提供调用链、指标、日志等可观测能力。

其中，除了编解码器无法脱离协议本身做到公用，其他的模块都可以被抽象为公共模块，并为所有的协议所复用。因此，我们抽象定义 generic Proxy，可用于通用扩展的通用协议代理。提供了可以让用户根据自己协议配置的通用编解码扩展点。开发人员只需要实现解析二进制的编解码器，使用者通过通用的配置完成对应的配置。其他的诸如路由，可观测，流处理全部由 Generic Proxy 进行实现。

这部分能力，我们已经完全贡献到了 Envoy 社区，通过 generic_proxy 的扩展，可以比较便捷的完成扩展。如下是一个扩展配置实现图：

我们扩展 Gateway 以及 VirtualService，通过结合自定义 EnvoyPlugin 以及 PluginManager，扩展并生成 generic route，完成对 Envoy generic listener 以及 generic route 的下发。其协议转换被生效在 generic route 的 per filter config。完成整个路由及协议转换的生效。

目前，通过这套标准的 generic proxy 的 API 扩展，可以很便捷的完成私有协议的扩展，研发提效 50% 以上。某头部券商通过该套框架，已落地 3 个私有协议的扩展。

案例二：全链路灰度

第二个案例是全链路灰度，在复杂的微服务集群，如何快速拉起一套全链路灰度，用于线下环境测试或线上问题复现。

全链路灰度的场景并不陌生，一套标准的基准环境，通过云原生网关为流量入口，下游为 A,B,C 三个微服务。如果服务 A，C 有灰度的诉求，在没有全链路灰度方案的时候，需要完整 copy 一套环境，其中的资源及机器部署申请，时间不可控。

在全链路灰度的场景下，业务只需要针对 A,C 服务进行灰度部署，由网关入口和微服务体系进行流量灰度穿梭，指定标签的流量可以打到灰度节点上，如果不存在灰度节点可降级到基准环境中的服务。

这个场景下，我们通过标签同步、条件打标、流量负载来进行全链路灰度。

通过 mesh-registry 组件，对接多注册中心，将不同注册中心中的实例进行聚合组装，提取其中的标签、metadata 信息，组装为 serviceentry 最终下发给 envoy eds 配置。

通过自研 header write filter，用于对不同的流量标识进行条件打标，支持 header/query/body 中的条件匹配。

通过结合 Envoy LB subset 的能力，提供基于标签的二级负载能力，进行流量的灰度。

案例三：插件扩展

第三个案例，在金融特性场景下，需要具备一定的功能拓展。提供插件扩展能力，考量主要有三点：1）敏捷扩展能力；2）插件之间相互独立，不受影响，能够进行配置之间的隔离；3）动态生效加载，不需要进行二次编译。

我们将插件扩展分为两层：1）开发人员，聚焦在插件开发，生成插件代码片段或可执行文件；2）插件使用人员聚焦在插件的使用、配置，并上线生效。

我们设计一套足够敏捷的可扩展插件体系，在代码编写上，提供基于 Rider 的 LUA 扩展脚手架，基于 FFI 实现，较社区提供更高性能及更灵活的扩展，提供基于 WASM 的脚手架，便于用户扩展，同时在可视化编程上，提供基于 schema 的前端渲染能力，使得用户可以敏捷的开发前端；在上传应用角度，提供不局限文件，OCI 的多种上传方式，提供 filter 的能力，扩展 EnvoyPlugin 和 PluginManger，用户可以指定插件作用顺序以及控制插件是否启用，灵活的生效配置及隔离化。

以上两个设计，我们都在社区进行了回馈，插件的扩展脚本开源于 Hango Rider(https://github.com/hango-io/rider)，插件的 Plugin 模块定义，开源于 Slime-io/slime(https://github.com/slime-io/slime)。

基于可扩展插件体系，要实现在证券行业的开市时间要求，在维护周期内，需要对某些请求进行确定周期的友好化响应。用户只需要进行插件的代码编写，简单的脚手架方式就可以编写完成对应的插件；通过平台化的方式，导入对应的代码，可选择文件或镜像；之后通过简单的拖拽方式，自动渲染生成可视化插件前端即可完成插件的开发，上架，交付。

案例四：业务平滑迁移

在金融场景的稳定性要求下，业务云原生改造不是一蹴而就的，而是根据业务敏感性要求，灰度迁移到云原生 K8s 中。云原生网关协助金融业务完成云原生改造，主要有三个痛点：

注册中心的复杂：传统行业注册中心不单一，包括存量的 Eureka、Nacos 以及虚拟机注册行为。
服务模型不统一：部署形态决定服务模型不同，例如虚拟机场景下的 IP,Port 服务属性，K8s 场景下的 K8s svc 服务模型；协议不同决定服务模型不同，例如 HTTP 场景下的域名 / 服务名，Dubbo 协议的接口粒度的服务模型。
存量网关迁移：企业中往往已经存在网关，如何敏捷且快速将存量的网关数据迁移到云原生网关上。

基于以上痛点，我们提供了标准的云原生网关迁移方案，其架构如下：

mesh-registry 对接多注册中心，提供对接 ZK、Eureka、Nacos 等注册中心，支持对接能力的扩展。
提供标准的 upstream 管理，抽象服务模型，对接静态 serviceentry 进行抽象，对接 envoy eds。同时，基于业务平滑上云，提供同协议多服务版本，用户可进行权重分流、版本分流用于灰度迁移。
标准的 sync 服务，对接已有结构化数据，协助企业完成存量网关数据迁移到我们的云原生网关体系。
案例五：多租户及配置隔离

在金融行业下，业务分级比较明显，需要完成对不同级别的系统在网关上的配置隔离。

Envoy Proxy 的核心处理流程就是接收客户端的下游请求，通过一系列过滤器 / 模块，将流量进行转发。Envoy 将接收下游请求抽象成为 Listener，对上游的转发成为 Cluster。其提供了多 Listener 的能力，可以支持在一个进程中动态多个 Port，开启多个 Listener，每一个 Listener 可支持动态刷新，且其 filter-chain 以及 route 相互隔离，互不影响。

因此基于 Envoy 的多 Listener，我们可以对网关从物理隔离抽象为逻辑隔离，在一个物理网关进程上，抽象多个逻辑网关。使得流量可以在不同的逻辑网关进行 filter 及 route 路由。

案例六：多集群建设

最后是我们如何建设金融级别稳定性保障体系，以满足金融行业的特殊行业属性以及政策指导要求。我们基于同城双活以及异地备份建设高可用架构，在同一个物理区域内建设不同的可用区，支持不同的集群 cluster，使得业务可以选择在同一个集群或者在同城双活的不同集群进行流量区域负载穿梭。

在网关金融行业大规模实践中，最核心的是以下两点：

丰富的能力建设：在支撑金融场景下，有一些特有的场景，因此要求云原生网关能够快速迭代，敏捷适配，提供标准的通用方案扩展。

稳定性体系建设：在事前，聚焦在降发生，聚焦在故障预防，提供全方位巡检方式，故障兜底以及灾备设计架构；如果事故发生，则从故障快速感知及恢复，快速的定位问题及恢复问题着手，降低事故影响，借助全链路排障以及 AIOps 能力，提供便捷的问题恢复手段。在事故后，进行经验沉淀及回归，完善经验知识库，指导高可用稳定性体系建设。