作者：光锥
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 化，南北向架构拆分。接下来对每一个步骤进行具体的演进阐明。
运维体系降级
待解决问题
通过容器化降级部署，极大的简化了部署运维形式，可能解决过后最突出的问题，但仅仅革新部署形式还远远不够：
- 因为接入网关有着特殊性（如须要对接配置管理平台，有着大量的 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 架构，动静变更能力有余，域名变更每日定时推送配置并失效，无奈满足业务疾速迭代需要；
- 非标准协议间接跟不同管控平台间接对接，对接老本较高，并且不容易收口管控；
- 对于不同业务线（如淘系、优酷），要做到资源隔离，因为少数模块配置应用动态的公共配置，建站老本较高。
演进思路
如何动静编排、精细化的管制路由策略，是在云原生体系下首要思考的问题。参考比照业界网关层做法，如 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 接入网关云原生架构
- 对立管制面：通过团体对立管制面进行服务接入、服务发现、熔断限流管制，起到变更收口对立解决的作用；
- 北向连贯层：基于 tengine 承载亿级在线用户和流量洪峰，起到高水坝作用，晋升南向路由层资源利用率；
- 南向路由层：基于 Envoy 通过 Pilot 转换 xDS 协定动静下发路由策略，实现动静编排路由、轻量级流量隔离计划；
- 云原生基座：运维操作建设在团体对立基础设施 ASI，屏蔽网关差异性，升高运维复杂性。
将来
阿里 AServer 接入网关一步步向云原生演进，每次演进都是基于长久以来困扰咱们的问题，但又不仅仅止步于解决问题，同时基于以后时代的解决方案，云原生架构革新也远不是起点，云原生的劣势也尚未齐全施展。技术的降级最终是为产品服务，云原生降级之后，让咱们有了一个强有力的引擎，接下来须要做的就是利用这个引擎革新产品状态，让基于网关之上的开发者最终受害。
产品整合
什么样的状态才是一个网关产品最好的状态呢？开发者每天都在应用，但又无需关怀网关的存在，这样存在感最低的状态或者就是最优的状态。以后接入网关从产品状态上裸露了一些实现细节，一个入口利用上线须要通过若干不同零碎交互能力实现接入，在云原生革新实现后，能够更好的实现 All in One，产品上做到一体化和闭环。
疾速弹性
虽实现 ASI Pod 降级革新，可自动化执行故障机置换，机器迁徙等操作，升高了运维老本，但上云最重要的一项能力就是疾速弹性，如能够在双十一峰值大促前疾速扩容，大促过后疾速缩容，可极大缩小为筹备大促所保有的机器资源，从而节俭巨量的老本。当然其中要解决的问题也很多，如安全性可靠性，弹性的实时性，这都须要配合云的基础设施独特建设，真正施展云上的劣势。
关注咱们，每周 3 篇挪动技术实际 & 干货给你思考！