导AServer接入网关承载整个阿里巴巴集团的入口流量，负责保活亿级用户长链，并支持数万种路由策略转发，是连接亿万用户和数十万后端服务节点的桥梁。今年的双11需要支撑数亿在线用户、千万级QPS、数万种有效的API控制策略，才能实现安全可靠的转发路由，保证丝般顺畅的用户体验。在支撑大规模业务流和管控的背后，需要对系统的每一个细节进行精准把控，杜绝每一个潜在风险点。借助云原生架构，可以大大简化运维操作，降低潜在风险。今年双11阿里AServer接入网关上千个Pod成功突破峰值。本文主要介绍阿里AServer接入网关如何拥抱上一代架构的变化，以及全面云原生的演进路径。（更多干货请关注【淘科技】公众号）一、架构演进背景门户网站需要抵御大促高峰带来的流量泛滥，清洗攻击流量，需要庞大的簇的大小。庞大的集群规模和对机器性能的极端要求导致运维复杂；随着接入业务的增加，支持的业务场景不断扩大，业务对路由策略灵活性和路由策略实时有效性的要求发生变化。high，对路由策略的动态编排能力有强烈需求；由于业务的多样性、业务线的收网节奏不同、故障隔离等，衍生出对流量隔离的稳定性需求。运维的复杂性、动态编排的需求、流量隔离、对性能的极致要求，驱动着AServer接入网关的不断演进和壮大。在紧跟业务发展步伐的同时，逐步降低运维成本，增强系统稳定性，经得起一次次双十一的考验。一、业务背景作为阿里集团AServer的接入网关，承载着整个阿里集团的入口流量。一开始，tengine网关支持域名转发策略。它根据域名转发给不同的后端服务，业务形式比较简单。Allin无线时代，为优化手机端用户体验，降低服务端人员开发成本，集团自研MTOP（手机淘宝开放平台）API网关，为手机端提供统一的API客户端和服务端平台，相同的域名只是通过URI携带的API信息转发给相应的业务。接入网关需要支持根据API（以URI区分）的路由转发能力，几年间迅速增加到几万条规则。随着业务发展越来越精细化，期望在同一个API下细分不同的业务场景，比如对双十一大促场馆、手机淘宝、支付宝等对外招商页面的源头等场景进行更精细化的管控，为适应业务发展，网关需要支持细粒度的管控能力，根据业务请求参数和请求头对流量进行控制和导流。从数以万计的灵活配置规则中为每个请求匹配一条独特的路径，同时保持极高的性能是极具挑战性的。（业务模型图）2.运维系统背景基础配套基础不完善，网关层基于tengine构建。最简单快捷的方案是使用物理机，部署流程和配置即可完成服务搭建。随着业务的增长，配置管理成为瓶颈。网关层需要一个强大的配置管理平台，以标准化的方式生成业务配置。自主研发的配置管理平台将配置分为应用配置、公共配置管理和证书配置。三个部分。公共配置：通过Git版本管理生成tengine运行的基础配置，如启用模块配置、tengine运行逻辑配置应用配置：通过标准模板生成业务需要的tengine配置证书配置：由于证书有有效期，为了防止过期忘了更新，还承担了证书自动更新的任务。初始系统部署架构：该方案可以实现业务的自助接入，通过配置管理平台的模板生成tengine配置，然后定时推送到网关机并重新加载进程，使配置生效.通过这种运维方式，不依赖基础设施，可以快速演进。但随着业务的增长和集群规模的增大，物理机运维方式的弊端逐渐显现。野蛮生长的时代已经过去。它已成为重中之重。物理机二进制发布依赖人工部署。需要批量执行命令安装rpm包，批量重启进程。这一切都是通过黑屏操作完成的。这种运维方式显然不能满足当前的稳定性要求。手动发布容易出现误操作和系统故障。此外，物理机运维的一致性也难以保证，包括二进制一致性和机器自身环境（如内核参数等）的一致性检查。过去的人工运维方式显然跟不上时代的步伐。解决发布和环境一致性问题的最佳方案是容器化技术。随着集团基础设施的完善，接入网关容器化改造扫清了障碍，将不变量（系统配置、二进制）打包发布。继续使用配置管理平台管理变量（应用配置、公共配置、证书），并通过容器化技术进行调整。容器化改造后的发布和配置变更流程：容器化架构简化建站、扩缩容操作，发布效率大幅提升，增加审批流程，增加系统卡点，避免人工操作可能导致的故障。放行过程也可接入监控系统，自动报警并暂停放行。3、核心问题随着电商业务发展越来越快，在规模达到瓶颈后，业务会有更多的横向扩展，精细化程度会越来越高，迭代速度也会相应加快。网关层适应业务变化的成本也在增加，由此带来的核心问题是：运维操作的复杂性：由于对性能的极端要求，网关集群对机器有特殊的要求；由于网关配置管理的特殊性，导致了运维操作的复杂性；存在特殊性，无法与集团现有运维系统很好对接，运维系统需要升级；动态编排能力不足：随着接入业务的增加，支持的业务场景扩展，业务对路由策略的灵活性和实时性要求越来越高。无论静态配置的实时性还是策略灵活性，都难以满足业务发展的需要。需要支持路由策略的动态编排能力；流量隔离成本高：缺乏轻量级业务范围隔离能力，新建集群成本过高。为了支持业务线不同的收网节奏，支持故障隔离，需要一个轻量级的多集群流量隔离方案。近几年云原生的快速发展，也为网关层提供了更好的架构选择。2.云原生架构为解决接入网关存在的问题，结合集团的业务场景和云原生开源系统，开启了AServer接入网关的云原生演进路径。维度系统升级，服务治理&网关Mesh，南北架构拆分。接下来，对每个步骤给出了详细的演化描述。1.运维系统升级1.1需要解决的问题通过容器化升级部署，部署运维方式大大简化，可以解决当时最突出的问题，但对部署进行改造是远远不够的方法：因为接入网关有特殊的（如果需要对接配置管理平台，有很多VIP需求），不能直接对接集团的基础设施，自己开发了独立的自定义操作和维修工具。扩缩容过程需要多个基础组件通过非标准接口协同操作，极大影响运维产品的迭代效率，如故障机器更换、依赖外部系统轮询检测、组基础设置等系统接入定制运维平台处理，运维操作存在较大延时。集团运维体系1.2演进思路随着集团内部针对云原生应用设计的统一基础架构ASI（AlibabaServerlessinfrastructure）逐步完善，提供基于原生K8SAPI的完整云原生技术栈支持。云原生方案具有强大的编排能力，通过自定义k8sextensions可以很容易的磨平gateway层的特殊性。ASI独创的自动化运维方式，可以直接应用到网关层。网关层对模型的特殊性可以通过划分节点池来实现。网关机节点池可自定义模型和内核参数，消除网关运维的特殊性，统一管理运维。1.3演化方案使用k8s自带的Controller扩展能力，自定义容器编排。扩缩容时，可以监听Pod变化事件，在配置管理平台上进行增删机操作。同时，还可以挂载/卸载VIP，解决运维问题。具体的，所有的资源都是通过声明式的API来定义的，方便运维。对于网关运维，也需要保留一个非常简单的运维平台，仅用于网站建设。与普通应用相比，网关建站需要在相应区域创建VIP，并进行域名绑定等操作。轻量易维护：通过ASI改造，将接入网关的运维集成到集团ASI云原生系统中（提高交付效率，去除专业化运维），将通用能力降为ASI和基础系统，同时具备风险隔离、自恢复、弹性能力风险隔离：使用sidecar能力隔离安全和工程能力，避免两者相互干扰。如果安全能力异常，只会影响流量清洗。安全能力降级后，服务不会整体不可用；自愈：针对容器的自愈能力，原有的容器化方式依赖于外部应用的轮询检测，缺乏准确性和实时性。升级ASI后，通过对容器自身的检测，可在3-5分钟内识别并更换故障容器；flexibilityCapabilities：自动弹性，通过ASI的改造，各个系统的对接方式可以使用标准的声明式API来集成组内的各个组件，大大简化了扩容和收缩的操作，并提供了对自动弹性的支持；屏蔽机型差异：通过节点池划分，网关应用可以使用特殊机型，底层配置屏蔽差异，无需特殊操作。2.ServiceGovernance&GatewayMesh2.1需要解决的问题随着网关层接入的业务类型越来越多，需要支持数以万计的API路由规则，路由策略也越来越细化。使用tengine的原生能力不能满足业务需求。通过tengine模块的定制开发和非标定义的方式，已经能够适应这几年的业务发展。但随着业务需求的细化，tengine模块的定制化开发成本也逐渐增加。原有的架构路由配置是通过模块来配置的。+它由本机配置组成。多个模块配置共同决定路由策略。分布式配置无法为请求识别完整的路由路径；通过功能模块的划分，很难按照业务的粒度实现增量更新；基于tengine架构，动态变更能力不足，域名变更每天定时推送配置生效，不能满足业务快速迭代的需求；非标准协议直接接入不同管控平台，对接成本高，不易关闭管控；对于不同的业务线（如淘系、优酷），必须做到资源隔离。由于大多数模块配置使用静态公共配置，因此建站成本相对较高。2.2演进思路如何动态编排和精细控制路由策略是云原生系统首要考虑的问题。参考并对比业界网关层实践，如Kong、Ambassador等，主流网关的数据面实现是基于nginx或envoy。不同产品的可扩展性、动态编排能力、成熟度对比：从动态性、标准化、性能等方面综合考虑，使用envoy作为数据面更适合云原生演进的方向：动态性和灵活性envoy实现的标准xDS协议足够灵活，可以动态配置和更改。独特的路由逻辑标准istio标准组件，强大的社区支持，快速发展阿里巴巴集团采用istio技术方案进行mesh化，使用envoy作为数据平面选项可以实现与C++统一性能进行集团业务管控，性能良好足够了，而且开发效率比tengine高，但是envoy的缺点是作为一个istio标准组件，东西向路由能力很强。作为南北路线，需要对一定的性能和稳定性进行优化，但从长远来看，动力和标准更重要。2.3演进方案复用GroupPilot作为统一的控制面组件，实现网关自身的网格化：控制面提供一层控制逻辑关闭权限，以提供每个暴露的业务产品的写法，以及每个product通过k8s声明路由策略写入API，然后Pilot控制面转换为xDS数据面协议，实时同步到数据面Envoy。南向路由网关实现架构：由于集团配置规模庞大，数十万条路由规则和数据、数千个应用、数十万个业务节点，开源系统很少有如此规模。Pilot+Envoy方案应用于南北网关后，需要对原生组件进行优化定制，解决规模化带来的性能和稳定性问题：Pilot支持SRDS协议：解决线性匹配带来的性能问题通过大规模API配置增量配置更新：实现并提升控制面的增量更新能力，避免全量更新带来的变更半径扩大的风险。节点变化优化：解决数十万业务节点状态变化对控制面和数据面性能的影响。扩展定制：针对群组特定的路由规则，自定义过滤器实现通过开源系统的定制优化，可以很好的满足群组的需求，通过灵活的配置组合，通过快速迭代透传的能力控制平面，可以实现集团内不同业务的特殊需求。3.南北分流3.1需要解决的问题网关作为用户和业务之间的桥梁，在用户端保持长链存活，优化协议，让用户能够快速、稳定地接入群组可能的;支持业务Policy的灵活路由和熔断限流，负载均衡。连接保活和路由转发虽然是网关的整体能力，但是两者的迭代效率要求和业务特点却有较大差异。在一些促销活动场景中，即使出现突发的流量高峰，网关层作为保护业务服务的屏障，依然可以坚如磐石，靠的是高性能和水位预留。考虑到保活链长，协议优化迭代周期这么长，性能极高；路由转发和流量清洗策略灵活复杂，资源消耗自然也比较高。如果将两者的架构拆分，可以得到很大的提升。提高整体资源利用率。3.2演进思路和方案通过协议卸载、长链保活等方式与客户端交互，可以维护极高性能的模块，分别拆分成北向集群。由于性能好，只需要少量的机器就可以建造高坝防洪；将性能消耗较大的业务路由策略和安全清洗能力相关，拆分成南向集群，通过北向高坝保护南向集群不超载，降低南向集群的预留水位。提高整体资源利用率，既可以提高资源利用率，又可以灵活配置，满足业务快速发展的需求。4、整体架构经历三个阶段演进，最终架构图如下：AServer接入网关云原生架构统一控制面：服务接入、服务发现、熔断和限流控制通过组，统一处理变更端口北向连接层：基于tengine，承载数亿在线用户和流量高峰，起到高坝作用，提高南向路由层资源利用率;南向路由层：基于Envoy，通过Pilot转换xDS协议动态下发路由策略，实现动态编排路由和轻量级流量隔离方案；云原生基础：运维操作建立在集团统一基础设施ASI上，屏蔽网关差异，降低运维复杂度。3、未来阿里AServer接入网关将逐步向云原生方向演进。每一次进化都是基于长期困扰我们的问题，但又不止于解决问题。同时，基于当前时代的解决方案，云原生架构的转型也远未结束，云原生的优势还没有得到充分发挥。技术的升级最终是为产品服务的。云原生升级后，我们拥有了强大的引擎。接下来要做的就是利用这个引擎来改造产品形态，让基于网关的开发者最终受益。1.什么样的产品集成状态才是网关产品的最佳状态？开发者每天都在使用，但不需要关心网关的存在，所以存在感最低的状态可能就是最优状态。当前的接入网关从产品形态中暴露了一些实现细节。一个门户应用需要与几个不同的系统交互才能完成访问。完成云原生改造后，可以更好的实现AllinOne，产品可以集成闭环。2、快速弹性虽然ASIPod升级改造已经完成，故障机器更换、机器迁移等操作可以自动进行，降低了运维成本，但上云最重要的能力是快速弹性。大促前的快速扩张和大促后的快速收缩，可以大大减少为准备大促而预留的机器资源，从而节省大量的成本。当然，还有很多问题需要解决，比如安全可靠，弹性实时性能，这些都需要和云基础设施一起建设，才能真正发挥云的优势。加入我们的淘喜架构和基础服务团队，为淘喜和阿里提供基础核心能力、产品和解决方案：下一代网络协议QUIC的实现和落地-XQUIC自适应高可用解决方案和核心能力-诺亚新一代业务研发模型platform-Gaia支持阿里整个移动中间件体系（千万级QPS接入网关、API网关、推送/消息、移动配置中心等）团队人才济济~~如果你想加入我们，请简历发邮件至：miaoji.lym@alibaba-inc.com（更多干货请关注【淘科技】公众号，每日更新阿里工程师技术干货）
