阿里亿级长连网关的云原生演进之路
作者：光锥
AServer接入网关承载整个阿里集团的入口流量，负责亿级用户的长链保活，支持上万路由策略转发，是连接上亿用户与后端几十万服务节点的桥梁，在去年双十一需要支撑亿级在线用户、千万级QPS、生效上万条API管控策略，做到了安全可靠的转发路由，并保障了用户体验如丝般顺滑。
在大规模业务流量与管控支撑的背后，需要对系统每一个细节的精确把控，消除每一个潜在的风险点。
借助云原生架构可以极大地简化运维操作，降低了潜在的风险，去年双十一阿里AServer接入网关上千台规模的Pod平稳扛过峰值。本文主要介绍阿里AServer接入网关如何从上一代架构拥抱变化，全面云原生的演进之路。
架构演进背景
每年双十一大促都是对阿里所有服务最严峻的考验，尤其对AServer接入网关来说，作为阿里集团第一道门户，需要抵御大促峰值带来的流量洪峰，清洗攻击流量，所需集群规模巨大。
巨大集群规模，以及对机器性能极致要求，导致了运维上的复杂性；随着接入业务的增多，所支持的业务场景扩宽，业务对路由策略的灵活性、生效的实时性要求变高，对路由策略的动态编排能力有着强烈诉求；由于业务的多样性，业务线不同封网节奏，以及故障隔离性，衍生出对流量隔离的稳定性诉求。
运维的复杂性、动态编排的诉求、流量隔离以及对性能的极致要求，推动着AServer接入网关不断演变和成长，紧跟业务的发展步伐的同时，逐步降低运维成本的，增强系统稳定性，能够一次又一次经受住双十一的考验。
业务背景
作为阿里集团AServer接入网关，承载整个阿里集团入口流量，最开始支持域名转发策略的tengine网关，根据域名 转发到后端不同服务，业务形态相对简洁。
来到All in无线时代，为优化手机端侧的用户体验，同时降级服务端人员的开发成本，集团自研了MTOP（Mobile Taobao Open Platform）API网关，为客户端和服务端提供了一致的API平台，相同的域名，仅通过URI携带的API信息转发到对应业务，接入网关需要支持按照API（通过URI区分）的路由转发能力，几年时间迅速增加到数万规则。
随着业务发展越来越精细化，期望对同一API下的不同业务场景进行细分，如针对双十一大促会场的来源，手淘、支付宝、其他外投页面等场景进行更精细化控制，为适应业务发展，网关需要支持精细化的管控能力，根据业务请求参数、请求头进行管控和分流。每一个请求都要从上万灵活的配置规则中匹配出唯一的路径，同时又要保持极高的性能，是一件极具挑战性的事情。
业务模型图
运维体系背景
最开始基础配套的基础设施并不完善，网关层基于tengine搭建，最简单快速的方案便是使用物理机，部署进程和配置即可完成服务搭建。随着业务增长，配置管理就成为瓶颈，网关层需要一个强有力的配置管理平台，通过标准化的方式生成业务配置，配套自研的配置管理平台把配置划分为应用配置、公共配置管理、证书配置三部分。
- 公共配置：通过Git版本管理方式生成tengine运行的基本配置，如启用模块配置，tengine运行逻辑配置
- 应用配置：通过标准的模板生成业务所需的tengine配置
- 证书配置：由于证书存在有效期，为了防止过期时忘记更新，还承担了证书自动更新任务
最初的系统部署架构：
该方案可以实现业务自助接入，通过配置管理平台的模板生成 tengine 配置，再由定时推送到网关机器并进行进程的reload，生效配置。
通过这种运维方式，不依赖基础设施，可以快速演进，但随着业务增长以及集群规模的上涨，物理机的运维方式弊端逐步显现，野蛮生长的时代过去，作为阿里服务入口，稳定性成为了重中之重，物理机的二进制发布依赖人工部署，需批量执行命令安装rpm包，并且分批restart进程，这一切都是黑屏操作完成。
此种运维方式显然无法满足现在的稳定性需求，通过手工发布，极易出现误操作导致系统性故障。另外物理机运维很难进行一致性保障，包括二进制的一致性，机器本身环境的一致性检查（如内核参数等），过去的手工运维方式显然已经跟不上时代的步伐。
解决发布和环境一致性问题的最优方案便是容器化技术，随着集团基础设施的完善，接入网关容器化改造扫除了障碍，把不变量（系统配置、二进制）打包成一体进行发布，把变量（应用配置、公共配置、证书）继续沿用配置管理平台进行管理，配合容器化技术进行调整。
容器化改造后的发布和配置变更流程：
容器化架构，简化了建站、扩缩容操作，发布效率有了极大的提升，增加审批流程，系统化卡点，避免了人为操作可能导致故障，发布流程还可对接监控系统，自动告警并暂停发布。
核心问题
随着电商业务发展越来越快，规模化达到瓶颈以后，业务就会有更多的横向扩展，精细化程度越来越高，迭代速度也随之变高，网关层适应业务的变化的成本也来越高，由此带来的核心问题：
- 运维操作复杂性：由于对性能的极致要求，网关集群对机器有着特殊的要求；由于网关配置管理的特殊性，导致了运维操作的复杂性；特殊性的存在无法很好对接集团现有运维体系，需要进行运维体系的升级；
- 动态编排能力不足：随着接入业务的增多，所支持的业务场景扩宽，业务对路由策略的灵活性、实时性要求越来越高，静态配置不论生效的实时性还是策略灵活性都难以满足业务发展需求，需要支持路由策略的动态编排能力；
- 流量隔离成本较高：缺乏轻量级业务范围隔离能力，通过新建集群实现的成本过高，为支持业务线不同封网节奏，以及支持故障隔离性，需要轻量级的多集群流量隔离方案。
云原生近年来的飞速发展，也为网关层提供了更好的架构选择。
云原生架构
为解决接入网关现存问题，结合集团业务场景以及云原生的开源体系，开启了AServer接入网关的云原生演进之路，为了分步验证，分解三个阶段逐步实现：运维体系升级，服务治理&网关Mesh化，南北向架构拆分。接下来对每一个步骤进行详细的演进说明。
运维体系升级
1待解决问题
通过容器化升级部署，极大的简化了部署运维方式，能够解决当时最突出的问题，但仅仅改造部署方式还远远不够：
- 由于接入网关有着特殊性（如需要对接配置管理平台，有着大量的VIP需求），无法直接对接集团的基础设施，开发了独立的定制化化的运维工具，扩缩容流程需要多个基础组件通过非标接口配合进行，极大的影响了运维产品的迭代效率
- 故障机置换机器等操作，依赖外部系统轮询检测，并且集团基础设置系统跟定制运维平台对接才能处理，有较大时延
- 运维操作脱离集团运维体系
2演进思路
随着集团内针对云原生应用设计的统一基础设施ASI（Alibaba Serverless infrastructure）的逐步完善，提供了基于原生K8S API的完整云原生技术栈支持。
云原生方案可编排能力很强，通过自定义实现k8s扩展，非常容易抹平网关层的特殊性，ASI 原有的自动化运维手段，可直接应用于网关层。
网关层对机型的特殊性，可以通过节点池划分来实现，网关机器节点池可自定义机型以及内核参数，消除网关运维上的特殊性，统一管理运维。
3演进方案
通过 k8s 自身的 Controller 扩展能力，自定义容器编排，在扩缩容时可以监听Pod变更事件对配置管理平台进行机器增删操作，同时也可以挂载/卸载VIP，抹平运维上的特殊性，并且所有资源都通过声明式API定义，方便运维。
对于网关运维，还需要保留一个非常简单的运维平台，仅做建站之用，对比普通应用，网关建站需要在对应区域创建VIP，进行域名绑定等操作，轻量且易维护：
通过进行ASI化改造，使得接入网关的运维融入集团ASI云原生体系（提升交付效率，去除特殊化运维），通用能力下沉至ASI和基础系统，同时具备了风险隔离、自恢复、弹性能力
- 风险隔离：使用Sidecar能力隔离安全和工程能力，避免二者的互相干扰，安全能力出现异常，只影响流量清洗，降级安全能力后，不至于服务整体不可用；
- 自恢复：对于容器自愈能力，原有容器化方式依赖外部应用的轮询检测，不论是准确性和实时性达都有所欠缺，升级ASI后，通过容器自身的检测，可在3-5分钟内识别并置换故障容器；
- 弹性能力：自动弹性能力，通过ASI的改造，各系统的对接方式可以使用标准的声明式API，整合集团内各组件，极大的简化了扩缩容操作，为自动弹性提供了支持；
- 屏蔽机型差异：通过节点池划分，针对网关应用可使用特殊的机型，底层配置屏蔽差异，无需特殊操作。
服务治理&网关Mesh化
1待解决问题
随着网关层接入的业务类型增多，需要支持上万条API路由规则，而且路由策略也越来越精细化，使用tengine原生能力无法满足业务需求。通过定制开发tengine模块，非标的定义方式，过去几年中可以很好适应业务的发展，但随着业务诉求愈发精细化，定制开发tengine模块的成本也逐步变大
2原有架构
- 路由配置通过模块配置+原生配置组合而成，多个模块配置共同决定路由策略，分散的配置无法对一个请求完整的路由路径的识别；
- 通过功能模块划分，想要按照业务粒度的进行增量更新较难实现；
- 基于tengine架构，动态变更能力不足，域名变更每日定时推送配置并生效，无法满足业务快速迭代需求；
- 非标准协议直接跟不同管控平台直接对接，对接成本较高，并且不容易收口管控；
- 对于不同业务线（如淘系、优酷），要做到资源隔离，由于多数模块配置使用静态的公共配置，建站成本较高。
3演进思路
如何动态编排、精细化的控制路由策略，是在云原生体系下首要考虑的问题。参考对比业界网关层做法，如Kong，Ambassador等，主流网关数据面实现都是基于nginx或者envoy，不同产品的扩展性、动态编排能力、成熟度的对比情况：
从动态性、标准性、性能方面综合考虑，使用envoy作为数据面更适合云原生演进方向：
动态性和灵活性
- envoy实现的标准xDS协议足够灵活，并且可全部动态配置和变更
- envoy扩展性足够好，可通过实现filter扩展实现集团内特有的路由逻辑
标准性
- istio标准组件，社区支持力度大，发展迅速
- 阿里集团mesh化使用istio技术方案，使用envoy作为数据面选项能够跟集团业务管控的统一化
性能
- C++实现，性能足够好，而开发效率比tengine高
而envoy不足之处在于作为istio标准组件，东西向路由能力较强，作为南北向需要进行一定性能和稳定性优化，但长远来看，动态性和标准性更为重要。
4演进方案
复用集团Pilot作为统一的控制面组件，实现网关自身的Mesh化：
控制面为提供各透出的业务产品写入，需提供一层管控逻辑进行权限的收口，各产品通过k8s声明式api写入路由策略，再由Pilot控制面转换为xDS数据面协议，实时同步给数据面Envoy，南向路由网关的实现架构：
由于集团的配置规模较大，数十万的路由规则和数千应用，几十万业务节点，开源体系鲜有如此规模。Pilot + Envoy方案应用于南北向网关后，需要对原生组件做一定的优化和定制，以解决规模化引起的性能和稳定性问题：
- Pilot支持SRDS协议：解决大规模API配置导致的线性匹配性能问题
- 增量配置更新：实现并完善控制面增量更新能力，避免全量更新导致变更半径扩大风险
- 节点变更优化：解决几十万业务节点的状态变更对控制面和数据面性能影响
- 扩展定制：针对集团特有的路由规则，定制filter实现
通过对开源体系进行定制和优化，可以很好的对接集团内的需求，通过灵活的配置组合，通过快速迭代控制面透传的能力，实现集团内不同业务的特殊需求。
南北向拆分
1待解决问题
网关作为用户跟业务的桥梁，对用户端保活长链，协议优化，让用户尽可能快速稳定的连到集团；对业务支持灵活的路由和熔断限流策略，负载均衡。虽然连接保活跟路由转发作为网关的整体能力透出，但二者的迭代效率的诉求，以及业务特点都有较大差异。
在一些大促活动场景，即使有预期外的流量洪峰，网关层作为保护业务服务的屏障，仍然可以做到稳如磐石，依赖于高性能和水位的预留。考虑到保活长链，协议优化有这较长的迭代周期，性能极高；路由转发和流量清洗由于策略灵活复杂，资源消耗自然相对较高，如把二者进行架构拆分，可以极大的提升整体资源的使用率。
2演进思路和方案
把协议卸载、长链保活等跟客户端交互，并且能够保有极高性能的模块，单独拆分为北向集群，由于性能很好，只需要少量的机器，便可筑高坝挡洪流；对于跟业务路由策略相关，以及安全清洗能力，消耗性能较多，拆分到南向集群，通过北向的高坝保护南向集群不会过载，南向集群可减少预留水位，进而提升整体的资源利用率，如此可做到即能够提升资源利用率，又可进行灵活配置适应业务快速发展的需求。
整体架构
通过三个阶段演进，终局架构图如下：
AServer接入网关云原生架构
- 统一控制面：通过集团统一控制面进行服务接入、服务发现、熔断限流控制，起到变更收口统一处理的作用；
- 北向连接层：基于tengine承载亿级在线用户和流量洪峰，起到高水坝作用，提升南向路由层资源利用率；
- 南向路由层：基于Envoy通过Pilot转换xDS协议动态下发路由策略，实现动态编排路由、轻量级流量隔离方案；
- 云原生基座：运维操作建立在集团统一基础设施ASI，屏蔽网关差异性，降低运维复杂性。
未来
阿里AServer接入网关一步步向云原生演进，每次演进都是基于长久以来困扰我们的问题，但又不仅仅止步于解决问题，同时基于当前时代的解决方案，云原生架构改造也远不是终点，云原生的优势也尚未完全发挥。技术的升级最终是为产品服务，云原生升级之后，让我们有了一个强有力的引擎，接下来需要做的就是利用这个引擎改造产品形态，让基于网关之上的开发者最终受益。
产品整合
什么样的状态才是一个网关产品最好的状态呢？开发者每天都在使用，但又无需关心网关的存在，这样存在感最低的状态或许就是最优的状态。当前接入网关从产品形态上暴露了一些实现细节，一个入口应用上线需要通过若干不同系统交互才能完成接入，在云原生改造完成后，可以更好的实现All in One，产品上做到一体化和闭环。
快速弹性
虽完成ASI Pod升级改造，可自动化执行故障机置换，机器迁移等操作，降低了运维成本，但上云最重要的一项能力就是快速弹性，如可以在双十一峰值大促前快速扩容，大促过后快速缩容，可极大减少为准备大促所保有的机器资源，从而节省巨量的成本。当然其中要解决的问题也很多，如安全性可靠性，弹性的实时性，这都需要配合云的基础设施共同建设，真正发挥云上的优势。
关注我们，每周 3 篇移动技术实践&干货给你思考！
……