前言
在近几年，网易数帆轻舟云原生网关在国内头部证券，银行等金融场景进行大规模实践。在落地过程中，有一些典型场景以及一些痛点问题。本章主要聚焦几个真实的场景，分享在金融场景下的云原生网关大规模实践。
金融场景下的云原生网关
私有协议扩展
越来越多的大型证券、银行等金融企业要求核心场景下的协议私有化。一部分原因是从企业角度要求，需要自主可控，另一部分也是证券及银行属于敏感企业，有一定的国家监管层面要求。
总结下来主要有三个明显的特征需求：
协议定制化
入口协议统一
多协议转换诉求
针对性的，我们提供两个解决方案，针对入口协议统一，upstream协议多样的场景，通过复用Envoy HTTP Connection Managaer（HCM）提供的标准filter，提炼通用的generic_filter。针对性的扩展私有协议的编解码。这样实现的好处是，可以复用HCM提供的标准filter以及我们在http维度的积累。只需要扩展对应的协议即可以开箱即用的集成40余种插件。实现的架构如下图：
针对多协议互转以及入口协议非HTTP的场景，考虑到协议处理维度的相同点，大部分request,response的rpc架构都有相似的流式处理，路由，可观测等能力。为了简化及抽象协议扩展的复杂度，我们提出设计通用代理（generic_proxy）的架构。主要分析generic_proxy的设计理念及设计目标，提供通用的generic_proxy的编解码的扩展点，定义通用的generic route API。通过generic proxy的实现，旨在为私有协议的扩展提供通用性。其核心设计架构如下图：
插件扩展能力
在金融场景下，会有一些业务定制诉求。从敏捷开发角度上考虑，需要支持一定的快速扩展能力，满足业务敏捷开发；同时，由于存在一些敏感合规的要求，业务会要求具备自身定制特殊需求的能力。因此，对云原生网关提出了以下要求：
敏捷扩展
插件隔离
动态生效
从插件开发人员和插件使用视角，我们抽象插件扩展。形成插件扩展解决方案，流程如下：
从设计维度，本着多语言，无侵入，高性能，可视化的原则，我们从以下几方面进行扩展
业务平滑上云
金融企业作为敏感行业，稳定性压倒一切。因此，在云原生迁移过程一定不是一蹴而就的，对于网关提出，我们如何帮助业务顺利完成云原生改造，协助业务完成平滑迁移。
迁移过程中，主要有三点痛点：
注册中心复杂
服务模型不统一
存量网关迁移困难
基于以上痛点，我们从三个方面解决业务平滑上云的痛点，整体架构如下：
其核心主要有几点：
通过slime mesh-registry模块实现对接多注册中心能力，已经集成zk,eureka,nacos等注册中心。
提供丰富的upstream管理及路由能力
抽象服务概念，统一k8s svc、静态ip、eureka app以及dubbo interface
通过mesh-registry对接多注册中心，同步ServiceEntry资源
支持同协议多服务发布，用于流量灰度
提供权重分流、版本分流的能力，支持服务金丝雀发布
通过sync-service 对接同步不同注册中心的配置数据，支持对接DB、Zookeeper等配置结构化数据，用于业务原网关配置迁移至云原生网关。
全链路灰度
在实际开发过程中，会存在多版本的发布及上线。复杂的微服务集群，如何能够快速拉起一套全链路的灰度逻辑环境，用于线下全链路测试、生产版本问题定位等是一个比较棘手的事情。在传统的微服务架构下，业务会通过修改自身代码，将一定特征的流量自主路由至不同版本。或者提供一套独立的环境，用于问题复现。总之，两种方式都不够轻量，涉及链路及交付周期等问题。
因此，全链路灰度的提出，可以将特征请求独立在不同的完全逻辑隔离的运行时环境，能够响应快速迭代、测试、问题复现等场景。其示意图如下：
对于云原生网关来说，在全链路灰度场景下，需要关注到三个核心点：
标签同步：能够同步服务实例，支持多注册中心的实例标签同步。
条件匹配：能够支持对入口流量根据不同的条件进行流量打标。
流量负载：根据不同的流量标签，将流量目的路由到对应标签（颜色）的实例。其流量架构如下：
我们通过slime mesh-registry同步不同注册中心的实例，并通过Header Rewrite能力进行路由匹配条件的重写，将匹配后的信息增加额外的实例颜色标签。这一流程，从处理上为入口流量染色。之后进入核心负载均衡阶段，通过Envoy LB Subset的能力，实现染色路由。完成全链路灰度的第一跳灰度。
网关多租户及隔离性
租户隔离是在企业网关中非常重要的特性，特别是在金融场景下，例如银行，其下属有众多分行；而在证券企业中，又有应用分级。网关需要具备多租户的配置隔离能力，针对不同系统之间的配置互不影响。
在传统的网关实现中，只能通过部署不同的网关集群，业务进行不同集群的划分进行强物理隔离。如下图
但是这种隔离会存在一定的资源浪费，集群之间的流量不均等，有的业务集群流量很低，但是因为其系统的特殊性，政策要求必须对齐进行配置隔离以避免相互影响。我们从Envoy的实现角度，进行优化。Envoy的核心就是代理，其最主要的就是确认流量，并将流量转发到对应的upstream。
下图是Envoy作为Proxy的核心流程，Envoy会对每一个监听器抽象一层Listener，此Listener可以通过动态的方式扩展并对外暴露。流量通过对应的Listener进入核心L4,L7 Filter后，通过负载均衡策略路由至不同的cluster（即Upstream）
因此，我们可以通过抽象不同的Listener为逻辑网关，每一个Listener上的配置相互独立。基于此，用户可以选择性的在同一个物理网关集群上抽象不同的逻辑网关，提供不同的网关分组。其逻辑图如下：
总结与展望
在云原生网关的探索上，我觉得还可以从以下三个方面进行后续的演进。
全能力网关建设： 网关逐步被大家作为南北流量的通用性所接纳，不止南北流量，当前网关也会结合编排等能力，多协议转换能力被用于微服务体系。
生产级别稳定性持续建设：从细粒度观测 -> 精准化告警 -> 快速恢复 -> 流量无损 四位一体构建监控体系；从事前阶段，提升系统稳定时间为目标，尽可能在不确定环境中降低事故发生率，事中阶段降低系统不稳定时间，事故发生尽可能快速恢复角度持续优化立体化监控，支撑事故发生的问题焦点快速发现。
AI赋能：通过沉淀专家经验，结合AI洞察能力，尽量做到问题前置，洞察故障。
