软件架构演进历程：从单体到云原生，阿里巴巴电商业务的架构变革

01

软件架构的演进过程及新要求

云原生

进化

首先，我们回顾一下软件架构的演变。这里我们以阿里巴巴的电商业务为例。它从单一结构开始。随着业务的发展，业务类型增多，然后垂直拆分为各个模块。基于SOA思想，构建分布式架构。互联网时代，流量增加，安全挑战更大。我们将服务分解为更多细节，并演变成微服务架构。随着整个应用架构的发展，我们的运维面临着巨大的挑战，所以我们容器化，实现集群管理。 K8s也成为云原生时代管理容器集群事实上的标准。

随着云计算的普及，我们将电子商务业务部署到云端。同时，我们不断提高业务的可用性以及研发和运维的效率。我们对流量控制也有了更极致的要求，所以我们开始提高微服务的粒度。精细拆分形成基于服务器的架构，做到资源按量使用、随时使用。一般来说，软件架构的演进随着业务的发展而不断演进，技术手段满足相应的业务需求。随着AI的普及，AI时代的应用架构其实正在慢慢成型。

如果说应用架构的演进是明线，那么其背后的隐线就是网关。网关其实很容易理解。比如我们的学校、办公楼、大型校园都会有一个大门，统一管理，保证入口的安全，控制入口的人流。计算机世界从物理世界学习了这种架构，并且从第一天起就拥有了网关。

单体架构的网关是Nginx，它只是一个流量网关。随着分布式架构的流行，各种服务之间的通信协议各不相同，需要进行一些协议转换来实现对各个服务的统一管理和控制，这就催生了ESB架构。微服务架构时代，我们对高可用、高性能有了更高的要求，于是就有了微服务网关、服务注册与发现、服务治理。其中，微服务网关不仅可以管理东西向流量，还可以管理南北向流量。在云原生架构方面，我们推出了云原生网关，将流量网关、微服务网关、安全网关合二为一，提升整个网关架构的整体性能和可用性。 AI时代，我们是否会有新的AI原生应用架构和相匹配的AI网关？

从数据来看，AI的发展速度非常快。今年2月至4月，AI应用日活跃用户在1亿左右。截至6月至​​8月，日活跃用户已达到150至1.6亿。半年时间，流量增长了50%。随着人工智能热潮的推进，人工智能原生应用架构的诞生将是必然的。

AI原生应用架构特点及新要求

那么AI原生应用架构到底是怎样的呢？经过我们两年来对AI技术趋势和AI应用的观察和实践，我们发现AI原生让整个应用架构变得更简单、更原子。 AI原生应用架构与云架构并不冲突。很多AI应用从第一天起就诞生在云端，并且是在云原生的基础上开发的。

那么AI原生应用架构有哪些特点呢？

AI时代除了交互方式的变化外，应用特性也出现了一些新的特点。无论是OpenAI还是其他大型模型，这两年服务器宕机事件接连发生。本质上，AI应用的特点给业务可用性带来了新的挑战。总结如下：

首先，API的数量增加了。 API将成为AI时代的一等公民。因为AI应用是由大模型API调用驱动的，而API会更加原子化，所以我们通过API的原子组装来设计应用能力，以满足一定的业务场景。以叫外卖为例。在非AI应用场景中，我们会打开一个外卖APP，根据自己的口味选择一家门店，然后再打开另一个外卖APP，对比同一家门店的价格，选择价格最优惠的一家下单。和付款。但如果是AI应用场景，我只需要告诉机器人我今天想吃什么，AI Agent就会为我推荐最便宜、最合适的商店并帮我下单。这背后，Agent需要调用一个大模型，根据我的喜好计算出我可能最感兴趣的外卖餐厅数量，并自动比较各个外卖APP的价格和偏好。这些都是由原子 API 驱动的。 。因此，我们的判断是，AI时代API调用数量肯定会大幅增加，API的全生命周期管理将变得越来越重要。

其次，长连接增加。移动互联网时代，用户点击并请求一次短链接后，交互就结束了。但在AI时代，用户与智能机器人的对话基本上不会一轮结束。在许多情况下，对话将基于上下文。就像人与人之间的对话一样，这种联系始终保持着。 AI应用基本上使用WebSocket或SSE等长期连接来维持人机会话。另外，如果我们因为业务需求或者稳定性要求，在后台做了一些配置更新或者其他运维动作，也会造成长连接的中断。用户侧会发现中断后的会话与中断前的会话完全是两个机器人。 ，就好像机器人失去了记忆一样，这对于用户体验来说是非常致命的。因此，为长连接配置热更新或优雅的上下线操作，以确保用户尽可能不敏感，至关重要。

第三，高延迟。大型模拟背后的计算任务通常很复杂，计算量很大，导致响应时间很长，而这个响应时间是用户明显感受到的。因此，在计算过程中RT会变长。在Vincentian和多模态场景下，响应时间较长，少则几十秒、几百秒，多则几分钟。高延迟使得AI应用程序容易受到恶意攻击，并且容易受到慢速请求的异步并发攻击。攻击者的成本很低，但服务器端的开销很高。在移动互联网中，系统TPS几百、几千、几千万是很常见的，但对于AI应用来说，系统TPS只有个位数，几十就已经代表了系统强大的处理能力。本质原因是AI应用的单位算力消耗呈指数级增长。

四是带宽大。由于我们的高延迟和高单位算力消耗，系统返回的内容更多，需要更大的出站带宽。如果我们按照传统的方法，在服务器上完成计算后返回结果给客户端，网络拥塞会非常大。因此，对于AI应用，系统采用流式推送的方式将单词一一发布，而不是一次性全部交给用户。一方面。用户体验更好。另一方面，服务器到客户端的传输压力也更小。

网关如何应对新挑战

面对上述新的挑战，我们可以得出结论，在AI时代，肯定需要一个新的网关来承载AI原生的应用架构。能够更好地满足API数量不断增加、长连接增加、高延迟、大带宽的新需求，而这正是AI网关要做的事情。另外，网关是不是越多越好？比如参加会议，前后要经过四次安检。这是一个好的用户体验吗？能否通过一次安检一次性满足各种安全需求？

同样，从单一应用时代到分布式应用时代，从微服务架构、云原生架构，到AI原生架构，相继产生了接入网关、流量网关、安全网关、业务网关等。同时，网关越多，维护成本也就越重。比如，不同技术栈的维护人员较多，响应时间不同，稳定性等通用要求难以管理，安全能力水平也参差不齐。那么，我们开始思考，是否可以有一个网关，能够统一不同类型的网关，既能满足我们当前的应用架构需求，又能满足未来的AI场景呢？这里我们分享一下3点网关的发展趋势。

首先，未来的网关必须是云原生的。因为经过这么多年的发展，云已经成为共识。所有业务都诞生于云中，这是不争的事实。因此，既然所有业务都已经在云上，那么网关也必须是云原生的。而且随着这些年互联网和移动互联网的发展，云原生时代默认的需求就是不规则流量的管理、突发流量、安全防护等，这些都应该基于云原生来解决。

二是集成度高。如果所有类型的网关不能集成在一起，就会出现上述“较重的维护成本”。例如，不同技术栈的维护人员较多，响应时间各不相同，稳定性等通用要求难以管理和保障。能力水平也参差不齐”等问题。因此，面向未来的网关必须高度集成、易于扩展。

第三，智力。 AI时代，所有商业都值得用AI技术重塑。涌现出大量新需求，如“API数量增加、长连接增加、高延迟、大带宽”。网关开始承载前所未有的使命，帮助企业快速发展。 。同时AI还可以支持网关变的更加智能。

阿里巴巴在网关演进的实践

从我们内部的业务需求来看，第一是流量网关的统一管控。阿里巴巴内部有很多业务应用程序，有数百万个。当外部请求量非常大时，如果不通过统一的流量入口进行调度，就无法实现统一的安全防护、统一的流量控制、统一的流量调度。想象一下大型促销或突发流量的场景。如果前面没有统一网关做一层拦截，而是各个业务方自己实现，管理成本将是巨大的。对流量网关的另一个要求是安全的统一保护。比如一些超便宜的产品，黄牛就在刷单。我们需要在入口处进行认证和防护，进行拦截，避免影响其他普通用户的权益。

二是微服务的统一管控。大家都知道阿里巴巴是微服务的先驱。我们从2008年开始就开始架构微服务化，建立了微服务网关，控制南北、东西流量，并作为全链路灰度等服务。治理的一个组成部分。

第三，被AI重塑的应用越来越多，API的数量也开始增加。我们内部实现了前后端分离的架构，通过网关对API进行统一管理，所以我们整合了API管理，希望通过API First的理念来驱动业务架构和研发。

无论是云原生时代还是AI原生时代，我们将流量网关、微服务网关、安全网关、AI网关四合一，并提供API管理能力。通过架构优势，一个团队只需维护一个网关即可。在这里，我们发布了云原生API网关，它统一了碎片化网关的架构，是一个高性能、安全、AI友好的统一网关。

云原生API网关提供首月免费试用，无购买限制，无时间限制，首次购买可享受40%的折扣。有兴趣的同学可以加入我们的客户群（鼎群：88010006189），我们将提供试用和实施支持。

02

云原生API网关的优势及原理分析

云原生

云原生API网关，高集成、高安全、高性能、高可用背后的实现机制是什么？

高集成：零代码构建AI应用

过去很多人可能尝试过构建一个AI应用程序，这相对简单。比如选择一个大模型，给出一些提示词，通过这些提示词设定一个人物身份，然后问他一些问题，他就会给出一些反馈。这是最简单的AI应用——问答机器人。就像互联网早期一样，我们开发一个博客网站非常简单。但如果应用上线，访问量增加，我们需要考虑的事情就会更多。

集成上述需求对应的所有能力将需要大量的开发工作。因此，我们在网关上设计了大量开箱即用的插件。这些插件全部开源，包括缓存管理、敏感词过滤、请求响应转换等能力，并且兼容各种主流大模型、矢量数据库和AI内容审核库，大大降低了用户的集成成本。

让我们看一些常见的场景。基于输出效果的考虑，我们在垂直领域训练了一个小模型。优先通过小模型提供服务，但稳定性可能没有那么高，所以一旦小模型不可用，就会自动切换到大模型提供覆盖。虽然答案准确率不如小模型，但相对于模型无效、不可用的情况来说，还是更有意义的。

另外，当模型请求很慢，用户需要等待很长时间时，可以通过Fast Fail机制设置一些超时，直接调度到其他大模型上，而不用重复尝试。

如果你调用大模型，都知道是按Token计费的。因此，我们通过网关上的插件呈现Token消耗的可视化，并设计限制规则来控制Token的数量，从而实现大型模型的调用成本控制。

最后，如果插件市场的插件无法满足您的需求，云原生API网关通过提供Wasm沙箱来支持自定义插件。无论你是Python、Go开发者，还是C、Rust开发者，都可以根据实际业务场景开发插件，而且开发规范也比较简单和通用。我们还提供AI辅助智能，可以通过自然语言描述自动为您生成代码。

集成度高：一键发布API服务

AI时代，API的数量和调用量将急剧增加。因此，API的全生命周期管理变得至关重要。虽然API管理已经被谈论很多年了，但为什么在中国的发展却相对缓慢呢？这是因为当软件迭代时，API给软件工程带来的开发效率提升效果并不明显。

高集成度：AI组件灵活扩展

当我们内置的插件不够用时，我们可以通过 Wasm 沙箱开发自己的插件。为什么一直强调沙箱？这是高可用性的范畴。当我们有很多插件在线时，如果其中一个插件不可用，是否会影响我们其他插件和网关的运行？其实不会，因为插件是通过沙箱机制运行的，单个插件只会影响单个沙箱。因此，大家可以放心大胆地定制插件，而无需满足业务需求。云原生API网关不仅支持Wasm插件，还支持WAMR插件，并且大大增强了插件的可观察系统，让大家更容易优化和改进插件。

零信任：人工智能保护和内容合规性

零信任旨在帮助我们的应用程序构建端到端的安全系统。安全性是一项非功能性需求。构建应用程序实际上非常简单。我们只需要编写一些业务代码就可以使用它。但要在线启动应用程序并将其提供给许多用户，需要考虑很多事情。非功能性需求远远大于功能性需求的设计开发工作量。所以我们希望通过网关，能够帮助大家一站式完成这些事情。

交通保障领域的容量规划是一个非常复杂的课题，涉及基础资源建设、容器管理、应用之间的依赖关系、峰水位评估等。这也与真实的交通模式密切相关。

以2012年双11为例。当我们坐在那里看着一场又一场的雪崩时，我们束手无策。重启也没有用。重新启动后，又崩溃了。只要高峰流量还在，就无法解决。 2013年，我们发明了一个强大的工具，叫做全链路压力测试，来模拟0点的真实流量。我们模拟了全国各地的CDN，然后对整个链路进行了压力测试。流量的真实形态也和我的双十一运营策略有关。哪些产品受欢迎，哪些商家更受欢迎。而且，流量的形式也不同。有些流量上升缓慢，有些流量可能呈脉冲状。 。假设一台机器可以处理100QPS。 100QPS无论是脉冲式上升还是缓慢上升，对服务器的压力都是不同的。因此，我们利用容量规划机制来不断模拟真实流量，增强架构的鲁棒性。云原生API网关将阿里巴巴的这些内部实践一一积累，并转化为产品能力。集成Sentinel，支持Token/API/服务级流控，集成Redis支持集群流控。

高性能：软硬件一体化，加速响应体验

高可用：服务治理的无损改变

高可用应该从两个维度来考虑。

第一个维度，如果你想帮助别人实现高可用，你首先要让自己成为高可用。当我们飞行时，广播会说，请系好您自己的安全带，然后帮助您的孩子系好安全带。如果发生灾难，请先自己戴上氧气面罩，然后帮助孩子戴上氧气面罩。我们也坚持这个原则，首先我们要实现高可用。因此，在整个网关技术架构体系中，我们的数据面、控制面、控制台都是隔离的。也就是说，当控制平面出现问题或者控制台出现问题时，不会影响数据平面。这是我们必须自己做的高可用性。

在第二个维度中，我们的数据表面支持热更新，而不是基于非常重的重载机制进行更新。这也大大提高了数据面的稳定性。在此基础上，基于阿里巴巴内部的高可用实践，我们将帮助运行在云原生API网关上的用户实现高可用。

阿里巴巴在内部开展安全生产工作时，每年都会为支持的企业制定目标。例如，统一钱文和淘宝设定了业务目标。管控流程中有一个概念叫变革三大支柱，分别是灰度、可观察、可回滚。乍一看很容易理解，看起来也很容易做，但实际实现起来还是蛮有挑战性的，尤其是灰度。我们应该在哪个维度进行灰度化？应该按照机器维度还是用户维度进行灰度化？ 。这就需要大量的改造和大量的适配来满足各种灰度的需求。因此，我们开始思考是否可以将灰度能力集成到我们的商业产品中，让客户的业务运行在我们的云产品上，自然而然地具备灰度能力。因此，我们将整个灰度能力集成到了云原生API网关中。从微服务请求开始，到网关，到后端服务，再到消息中间件，都支持这种灰度能力。

云原生API网关支持全链路灰度。先在末端设置泳道，然后在泳道上做标记。所有带有此标签的请求都会自动进入这条泳道，并会被逐步验证并切断。至于可观察性，有人说我做了灰度，但找不到问题。比如有100台机器，其中两台用于灰度。这两台灰度机的流量已经降到零了，但是我的市场只降了两个点。问题并不明显。这个时候，可观察性就至关重要了。这很重要。因此，对于灰度环境，我们需要提供一套完整的可观测能力。虽然只有两台机器，但是对于这个环境来说，是100%失败的。即使有一个宕机了，50%的流量也会失效，而不是1%的流量。针对灰度环境，我们有专门的观测系统和观测市场。创建泳道后，即使有一点抖动，也可以通过观察行情来发现问题，判断灰度效果是否符合预期。

此外，在服务运行过程中，可能需要处理一些请求、执行线上或线下的操作、或者扩展或收缩容量。这涉及到优雅地上线和下线的能力。可以等到服务处理完再下线吗？我们是否可以等到应用程序完全启动并检查没有问题后再上线，甚至先做一些预热。因此，我们将优雅上线和下线的能力集成到了网关中。同时，还集成了主动健康检查，确保服务一旦出现问题，将不再直接对外提供服务。

高可用性：全球灾难恢复

当某个区域出现问题时该怎么办？这时，多个AZ（可用区）就至关重要。

灾难恢复，简单来说就是冗余和隔离。物质世界给我们提供了很多案例。例如，一架飞机有多个发动机，这是典型的冗余，每个发动机独立工作，这是隔离。至于我们在街上看到的油罐车，里面有这么多液体，如果司机突然刹车会有什么后果吗？但实际上，油罐车的内部是有隔板隔开的，加油车的油箱也被隔离在里面。这些都是物理世界灾难恢复的经典案例。

我们先来说说冗余。我们不能把所有鸡蛋放在一个篮子里。如果这个篮子坏了，所有的鸡蛋都会坏掉。因此，我们尝试使用多个AZ进行部署，将服务部署到多个Region。再说说隔离，保证多个AZ之间的流量隔离，出现问题时可以进行有效的调度。

再比如，如果今天的会议地址突然发生变化，我们会在网关入口处告知用户变更后的会议室地址，而不是等大家都进来了再一一通知。这就是网关起到的隔离作用。通过网关，我们可以有效地调度入口处的流量。当后端发生变化时，只需将流量引导至指定位置即可。通俗来说就是通过云原生API网关统一调度流量，后端部署多个AZ，按照比例或者特征将流量调度到对应的地方。当一方发现问题时，我们可以直接将流量调度给另一方。

最后，云原生API网关还提供AI诊断和问答能力。如果应用遇到错误，比如5xx或者4xx错误，只要连接到云原生API网关，我们就会直接采集数据，帮助您分析定位问题，并提供推荐的解决方案。

03

云原生API网关实战demo

云原生

内部实践

云原生API网关的产品能力并不是凭空想象出来的，而是通过内部实践一步一步孵化出来的，源自真实的业务需求。比如统易APP、模型服务灵机、人工智能平台PAI都使用我们的网关。

第一个业务需求是支持长链接的热更新。如果按照传统的处理方式，每次更新配置时都会断开配置连接。这种体验非常差。 AI技术迭代如此之快，日常变化非常频繁，这就需要网关支持热更新。

第二个业务需求是支持流式输出。 AI生成的结构相对较大且较长。如果都堆在服务器上，压力会更大，而且客户会看到一片空白，体验也不好。因此，通过流式输出，大模型可以不断地向用户输出结果，从而获得更好的体验并减轻服务器的压力。

第三个业务需求是安全和限流。由于AI如此流行，蜂拥而至的频率和流量都非常大，几乎所有AI供应商都经历过宕机事件。因此，需要一个网关来控制流量，而不是在应用端做太多非功能性的定制。

第四个业务需求是支持极大规模的路由/域名变更。如果是传统网关，变更的推送时间很长，重载时间也很长，导致服务长期中断。这也会带来一些衍生风险，比如PAI切换到我们的网关后，突发流量进来后可用性降低、内存消耗增加等暴露风险。路由配置生效的RT由原来的10分钟缩短为30秒。

外部客户

我们来谈谈两个外部客户。其中之一是零一愿望，这是一家由国际人工智能专家李开复博士创立的全球人工智能公司。他们提供了很多自己的大模型并开放。同时提供大模型的API服务。在对外暴露API的时候，我们也遇到了所有AI厂商都会遇到的长连接、高延迟、大带宽、限流稳定性以及Token计量计费问题等问题。这些问题通过云原生API网关的插件热更新能力、细粒度集群限流能力、流处理能力、丰富的可观测能力来解决。此外。我们提供的快速故障和故障转移机制提高了业务可用性。

另一个客户是数字化工业用品服务平台振坤兴工业超市。他们在工业用品垂直领域开发了专门的模型并向外部提供服务。他们担心的是万年模型是否出现问题，能否自动切换到其他大型模型进行掩护。这是一个典型的云原生API网关需求场景。客户的动手能力和执行能力都很强，下午我们介绍云原生API网关的时候就不得不体验一下。不到半天的时间，Fast Fail和Failover机制就配置完毕，从前端流量代理到后端限流拦截，实现了专用机型和通用大机型的无缝切换。

随着客户对云本地API网关有更深入的了解，他们逐渐使用门户的更多功能，包括缓存的抹布插件和及时的单词模板，以在用户请求反馈时获得更准确的建议。此外，还使用了网关的可观察性功能，令牌电流限制，令牌计量和计费以及其他功能。

商业和开源

除了提供商业产品外，我们还提供开源解决方案供客户自由选择。同样，我们提供NACOS的Microservice Engine MSE的商业托管版本和RocketMQ在云上的云消息队列MQ的商业托管版本。云本机API网关是Higress的商业托管版本，Higress是一个开源网关。

开源和商业化本质上是彼此补充的。从一开始，我们想通过开源开放我们的技术，尽可能释放技术股息，并帮助客户加速业务发展。在此过程中，许多公司客户已经提供了反馈：“仅开源是不够的。您能否提供一些商业增值服务来帮助我们更快地支持该系统？如果有人提供商业支持，我们会感到更加放松。”去使用开源。”因此，在开源之后，我们迅速提供了相应的商业产品，同时确保对开源的持续投资。

Higress开源后，社区变得非常活跃。总共发布了35个版本，有400多个人和90多个贡献者。此外，Higress的质量非常高，单个测试覆盖率超过90％，这在所有开源项目中都是非常罕见的。此外，我们还提供了一种非常好的可扩展性机制，即WASM沙箱，该机制动员了社区提供丰富的插入市场。这些插件可以开箱即用。

在过去的两年中，AI快速发展，我认为我们在网关上的积累和降水现在可以满足大多数AI应用的需求。欢迎每个人参加Higress的开源社区，并与我们合作将其构建为AI时代最有用的AI网关。也欢迎您尝试我们的商业产品云本地API网关来快速构建您的AI应用程序。最后，我们使用演示体验云本机API网关的产品功能。