阿里亿级长连网关的云原生演进之路

解决发布和环境一致性问题的最优方案便是容器化技术，随着集团基础设施的完善，接入网关容器化改造扫除了障碍，把不变量（系统配置、二进制）打包成一体进行发布，把变量（应用配置、公共配置、证书）继续沿用配置管理平台进行管理，配合容器化技术进行调整。

容器化改造后的发布和配置变更流程：

容器化架构，简化了建站、扩缩容操作，发布效率有了极大的提升，增加审批流程，系统化卡点，避免了人为操作可能导致故障，发布流程还可对接监控系统，自动告警并暂停发布。

核心问题

随着电商业务发展越来越快，规模化达到瓶颈以后，业务就会有更多的横向扩展，精细化程度越来越高，迭代速度也随之变高，网关层适应业务的变化的成本也来越高，由此带来的核心问题：

• 运维操作复杂性：由于对性能的极致要求，网关集群对机器有着特殊的要求；由于网关配置管理的特殊性，导致了运维操作的复杂性；特殊性的存在无法很好对接集团现有运维体系，需要进行运维体系的升级；

• 动态编排能力不足：随着接入业务的增多，所支持的业务场景扩宽，业务对路由策略的灵活性、实时性要求越来越高，静态配置不论生效的实时性还是策略灵活性都难以满足业务发展需求，需要支持路由策略的动态编排能力；

• 流量隔离成本较高：缺乏轻量级业务范围隔离能力，通过新建集群实现的成本过高，为支持业务线不同封网节奏，以及支持故障隔离性，需要轻量级的多集群流量隔离方案。

云原生近年来的飞速发展，也为网关层提供了更好的架构选择。

云原生架构

=====

为解决接入网关现存问题，结合集团业务场景以及云原生的开源体系，开启了 AServer 接入网关的云原生演进之路，为了分步验证，分解三个阶段逐步实现：运维体系升级，服务治理 &网关 Mesh 化，南北向架构拆分。接下来对每一个步骤进行详细的演进说明。

运维体系升级

待解决问题

通过容器化升级部署，极大的简化了部署运维方式，能够解决当时最突出的问题，但仅仅改造部署方式还远远不够：

• 由于接入网关有着特殊性（如需要对接配置管理平台，有着大量的 VIP 需求），无法直接对接集团的基础设施，开发了独立的定制化化的运维工具，扩缩容流程需要多个基础组件通过非标接口配合进行，极大的影响了运维产品的迭代效率

• 故障机置换机器等操作，依赖外部系统轮询检测，并且集团基础设置系统跟定制运维平台对接才能处理，有较大时延

• 运维操作脱离集团运维体系

演进思路

随着集团内针对云原生应用设计的统一基础设施 ASI（Alibaba Serverless infrastructure）的逐步完善，提供了基于原生 K8S API 的完整云原生技术栈支持。

云原生方案可编排能力很强，通过自定义实现 k8s 扩展，非常容易抹平网关层的特殊性，ASI 原有的自动化运维手段，可直接应用于网关层。

网关层对机型的特殊性，可以通过节点池划分来实现，网关机器节点池可自定义机型以及内核参数，消除网关运维上的特殊性，统一管理运维。

演进方案

通过 k8s 自身的 Controller 扩展能力，自定义容器编排，在扩缩容时可以监听 Pod 变更事件对配置管理平台进行机器增删操作，同时也可以挂载/卸载 VIP，抹平运维上的特殊性，并且所有资源都通过声明式 API 定义，方便运维。

对于网关运维，还需要保留一个非常简单的运维平台，仅做建站之用，对比普通应用，网关建站需要在对应区域创建 VIP，进行域名绑定等操作，轻量且易维护：

通过进行 ASI 化改造，使得接入网关的运维融入集团 ASI 云原生体系（提升交付效率，去除特殊化运维），通用能力下沉至 ASI 和基础系统，同时具备了风险隔离、自恢复、弹性能力

• 风险隔离：使用 Sidecar 能力隔离安全和工程能力，避免二者的互相干扰，安全能力出现异常，只影响流量清洗，降级安全能力后，不至于服务整体不可用；

• 自恢复：对于容器自愈能力，原有容器化方式依赖外部应用的轮询检测，不论是准确性和实时性达都有所欠缺，升级 ASI 后，通过容器自身的检测，可在 3-5 分钟内识别并置换故障容器；

• 弹性能力：自动弹性能力，通过 ASI 的改造，各系统的对接方式可以使用标准的声明式 API，整合集团内各组件，极大的简化了扩缩容操作，为自动弹性提供了支持；

• 屏蔽机型差异：通过节点池划分，针对网关应用可使用特殊的机型，底层配置屏蔽差异，无需特殊操作。

服务治理 &网关 Mesh 化

待解决问题

随着网关层接入的业务类型增多，需要支持上万条 API 路由规则，而且路由策略也越来越精细化，使用 tengine 原生能力无法满足业务需求。通过定制开发 tengine 模块，非标的定义方式，过去几年中可以很好适应业务的发展，但随着业务诉求愈发精细化，定制开发 tengine 模块的成本也逐步变大

原有架构

• 路由配置通过模块配置+原生配置组合而成，多个模块配置共同决定路由策略，分散的配置无法对一个请求完整的路由路径的识别；

• 通过功能模块划分，想要按照业务粒度的进行增量更新较难实现；

• 基于 tengine 架构，动态变更能力不足，域名变更每日定时推送配置并生效，无法满足业务快速迭代需求；

• 非标准协议直接跟不同管控平台直接对接，对接成本较高，并且不容

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

易收口管控；

• 对于不同业务线（如淘系、优酷），要做到资源隔离，由于多数模块配置使用静态的公共配置，建站成本较高。

演进思路

如何动态编排、精细化的控制路由策略，是在云原生体系下首要考虑的问题。参考对比业界网关层做法，如 Kong，Ambassador 等，主流网关数据面实现都是基于 nginx 或者 envoy，不同产品的扩展性、动态编排能力、成熟度的对比情况：

从动态性、标准性、性能方面综合考虑，使用 envoy 作为数据面更适合云原生演进方向：

• 动态性和灵活性

• envoy 实现的标准 xDS 协议足够灵活，并且可全部动态配置和变更

• envoy 扩展性足够好，可通过实现 filter 扩展实现集团内特有的路由逻辑

• 标准性

• istio 标准组件，社区支持力度大，发展迅速

• 阿里集团 mesh 化使用 istio 技术方案，使用 envoy 作为数据面选项能够跟集团业务管控的统一化

• 性能

• C++实现，性能足够好，而开发效率比 tengine 高

而 envoy 不足之处在于作为 istio 标准组件，东西向路由能力较强，作为南北向需要进行一定性能和稳定性优化，但长远来看，动态性和标准性更为重要。

演进方案

复用集团 Pilot 作为统一的控制面组件，实现网关自身的 Mesh 化：

控制面为提供各透出的业务产品写入，需提供一层管控逻辑进行权限的收口，各产品通过 k8s 声明式 api 写入路由策略，再由 Pilot 控制面转换为 xDS 数据面协议，实时同步给数据面 Envoy，南向路由网关的实现架构：

由于集团的配置规模较大，数十万的路由规则和数千应用，几十万业务节点，开源体系鲜有如此规模。Pilot + Envoy 方案应用于南北向网关后，需要对原生组件做一定的优化和定制，以解决规模化引起的性能和稳定性问题：

• Pilot 支持 SRDS 协议：解决大规模 API 配置导致的线性匹配性能问题

• 增量配置更新：实现并完善控制面增量更新能力，避免全量更新导致变更半径扩大风险

• 节点变更优化：解决几十万业务节点的状态变更对控制面和数据面性能影响

• 扩展定制：针对集团特有的路由规则，定制 filter 实现

通过对开源体系进行定制和优化，可以很好的对接集团内的需求，通过灵活的配置组合，通过快速迭代控制面透传的能力，实现集团内不同业务的特殊需求。

南北向拆分

待解决问题

网关作为用户跟业务的桥梁，对用户端保活长链，协议优化，让用户尽可能快速稳定的连到集团；对业务支持灵活的路由和熔断限流策略，负载均衡。虽然连接保活跟路由转发作为网关的整体能力透出，但二者的迭代效率的诉求，以及业务特点都有较大差异。

在一些大促活动场景，即使有预期外的流量洪峰，网关层作为保护业务服务的屏障，仍然可以做到稳如磐石，依赖于高性能和水位的预留。考虑到保活长链，协议优化有这较长的迭代周期，性能极高；路由转发和流量清洗由于策略灵活复杂，资源消耗自然相对较高，如把二者进行架构拆分，可以极大的提升整体资源的使用率。

演进思路和方案

把协议卸载、长链保活等跟客户端交互，并且能够保有极高性能的模块，单独拆分为北向集群，由于性能很好，只需要少量的机器，便可筑高坝挡洪流；对于跟业务路由策略相关，以及安全清洗能力，消耗性能较多，拆分到南向集群，通过北向的高坝保护南向集群不会过载，南向集群可减少预留水位，进而提升整体的资源利用率，如此可做到即能够提升资源利用率，又可进行灵活配置适应业务快速发展的需求。

整体架构

通过三个阶段演进，终局架构图如下：

AServer 接入网关云原生架构