从云原生到 AI 原生，网关的发展趋势和最佳实践

作者：谢吉宝（唐三）

编者按： 云原生 API 网关系列教程即将推出，欢迎文末查看教程内容。本文整理自阿里云智能集团资深技术专家，云原生产品线中间件负责人谢吉宝（唐三） 在云栖大会的精彩分享。讲师深入浅出的分享了软件架构演进过程中，网关所扮演的各类角色，AI 应用的流量新特征对软件架构和网关所提出的新诉求，以及基于阿里自身实践所带来的开源贡献和商业能力。通过本文，您将收获：

系统化了解软件架构的演进过程和由此产生的新的业务需求
由里及表的认知统一网关架构的优势
通义 APP、模型服务灵积、PAI、零一万物、震坤行在 AI 应用上构建网关的实践

软件架构的演进过程和新需求

演进历程

首先我们一起回顾一下软件架构的演进历程。这里以阿里巴巴电商业务为例，最开始是单体架构，随着业务的发展，业务的种类变多了，然后垂直拆分成各个模块。再基于 SOA 思想，构建了分布式架构。到了互联网时代，流量变大，安全挑战性变大。我们把服务拆得更加细致，演进到微服务架构。伴随着整个应用架构发展，我们的运维面临着巨大挑战，于是进行容器化，实现集群化的管理。K8s 也成为了云原生时代管理容器集群的事实标准。

随着云计算的普及，我们将电商业务部署到云端，同时对业务的可用性和研发运维效率精益求精，在流量的管控上有了更极致的要求，所以开始对微服务进行了颗粒度更细的拆分，形成了 Server 化的架构，从而实现资源能够按量使用、随弹随用。总的来讲，软件架构的演进是随着业务的发展而不断向前演进的，技术手段满足对应的业务需求。随着 AI 的流行，AI 时代的应用架构其实也在慢慢成型。

如果说应用架构的演进是明线，背后的暗线就是网关了。网关其实很容易理解，比如我们的学校、办公楼、大型园区都会设置一个大门，由它进行统一管理，确保入口安全，对入口流量进行管控。计算机世界从物理世界学习了这套架构，从第一天起就有了网关。

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

从数据上来看，AI 的发展非常快。今年的 2 月-4 月期间，AI 应用的日活大概是大概是 1 个亿左右，到了 6 月-8 月期间，日活已经达到了 1.5 到 1.6 亿。半年时间，流量就上涨 50%。随着这股 AI 热潮的推进，AI 原生应用架构的诞生也会成为一种必然。

AI 原生应用架构的特征和新需求

那么 AI 原生应用架构究竟是怎么样呢？经过我们这两年对于 AI 技术趋势和 AI 应用的观察和实践，我们发现 AI 原生让整个应用架构变得更加简单、更加原子化了。AI 原生应用架构和云的架构并不冲突，很多 AI 类的应用第一天起就诞生于云，是在云原生的基础上发展起来的。

那么 AI 原生的应用架构有什么特点呢？

AI 原生的应用架构由轻量化的 agent 构成，以大家熟知的智能聊天机器人为例，文生文/图的过程中，系统就会触发调用大模型的 API，通过 API 来返回文字、图片甚至视频结果，这是 AI 应用架构的一个显著变化。
交互方式的变化。执行器发展的初期是 CLI（命令行界面，Command Line Interface），后来随着图形化界面的发展，交互体系变成了 GUI（图形用户界面，Graphical User Interface），AI 时代交互开始出现了 LUI（语言用户界面，Language User Interface），并一步步发展成 LUI&GUI 相结合的产物。人机交互界面发生的这些变化，背后便是通过 API 所驱动的。

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 就会变长。在文生图和多模态的场景下，响应时间则更长，少则几十、上百秒，多则分钟级别的响应。延时高，使得 AI 应用面向恶意攻击很脆弱，容易被慢请求进行异步并发攻击，攻击者的成本很低，但服务端的开销很高。移动互联网，系统几百几千几万的 TPS 很常见，但是 AI 应用，系统的 TPS 只有个位数，几十已经代表了系统很强的处理能力了。本质原因就是 AI 应用的单位算力消耗是指数级增长的。

第四，大带宽。 因为我们高延时、单位算力消耗大，系统返回的内容比较多，出向的带宽量需求会更大。如果按照传统的方式，我们是在服务端计算完后，再把结果返回给客户端，网络的拥塞会非常大。因此对于 AI 应用，系统是通过流式推送，一个字一个字的放出来，而非一次性全部给用户。一方面。用户体验更好，另一方面，服务端到客户端的传输压力也更小。

网关如何应对新挑战

面对以上这些新的挑战，我们可以断言，在 AI 时代一定需要一个新的网关来承载 AI 原生的应用架构。能更好的满足 API 的数量变多、长连接增多、高延时、大带宽这些新的需求，而这正是 AI 网关要去做的。此外，网关是不是越多越好？例如参加一个会议，要进行前后4道安检，这是好的用户体验么？我们能否通过一次安检就把各类安保需求一次性满足掉呢？

同理，从单体应用时代到分布式应用时代，从微服务架构、云原生架构，到 AI 原生架构，陆陆续续产生了接入网关、流量网关、安全网关、业务网关等等。同时，网关越多，维护成本越重，例如技术栈不同维护人员多&响应时间有差异、稳定性等通用性诉求难于管理、安全能力水平也参差不齐。于是，我们就开始设想，能否有一种网关，对不同类型的网关进行统一，既能够满足我们当下应用架构的需求，也能面向未来满足 AI 的场景？这里分享 3 点网关的发展趋势。

第一，未来的网关一定是云原生化的。 因为经过这么多年的发展，云已经成为共识。所有的业务天生长于云，也已经是不争的事实。所以说，既然业务都已经长在云上，那网关也必然是云原生化的。而且随着这么多年互联网、移动互联网的发展，云原生时代默认的诉求，就是对不规则流量、突发流量、安全防护等的管理。这些都应该基于云原生全都解决掉。

第二，高集成。 如果不能够把所有类型的网关集成到一起，就会出现上文所提到的“维护成本越重，例如技术栈不同维护人员多&响应时间有差异、稳定性等通用性诉求难于管理、安全能力水平也参差不齐”等问题。因此，面向未来的网关，一定是高集成、易扩展的。

第三，智能化。 AI 时代，所有的业务都值得用 AI 技术重塑，涌现了“API 的数量变多、长连接增多、高延时、大带宽”等大量的新诉求，网关开始承载着前所未有的使命，帮助业务高速发展。同时 AI 也可以支撑网关变更更智能。

阿里在网关演进过程中的实践

从我们内部的业务诉求来看，首先是流量网关的统一管控。阿里内部的业务应用非常多，成百上千万个。当外部请求量非常大的时候，如果不通过一个统一的流量入口来调度，就没法去做统一的安全防护，没法做统一的流量管控，没法做统一的流量调度。设想大促或者突发流量的场景，如果没有一个统一的网关在前面去做一层拦截，而是由各个业务方自行去实现，那管理成本是巨大的。流量网关上的另一个需求是安全的统一防护。例如一些超级便宜的商品，黄牛进行刷单，我们需要在入口处做鉴权和防护，进行拦截，以免影响其他普通用户的权益。

其次是微服务的统一管控。大家都知道阿里巴巴是微服务的先行者，我们从 2008 年就开始对架构进行微服务改造，并沉淀了微服务网关，对南北向、东西向流量进行管控，同时作为全链路灰度等服务治理不可或缺的组件。

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

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

云原生 API 网关提供了首月免费试用，不限购、不限时、不限首购的6折优惠。有兴趣的同学可以加入我们的客户群（钉群：88010006189），我们将提供试用和落地支持。

云原生 API 网关的优势和原理探析

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

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

可能很多人已经尝试过去构建一个 AI 应用，是相对比较简单的。例如选一个大模型，给一些提示词，通过这些提示词设定一个角色身份，然后问他一些问题，他就会给出一些反馈。这是一个最简单的 AI 应用-问答机器人。这就像互联网初期，我们开发一个博客网站也是非常简单的。但如果把应用上线，访问量变大，我们要考虑的事情就变多了。

首先，我们要考虑如果大模型返回失败，或者没有响应，该怎么办？需要对接多个大模型，当大模型 A 调用失败，会自动切换到大模型 B，形成 Failover 机制，提升用户体验。
第二，大模型就像一个高智商的儿童，童言无忌，可能会说出一些比较敏感的话。需要通过敏感词过滤机制，对输出内容进行过滤。
第三，响应时长怎么办？因为每一个大模型背后的实时计算量都是非常大的，响应比较慢。用户体验非常不好。传统应用解决这个问题就是在前面加一个缓存，处理比较简单，一个 Key，对应一个 Value 就可以了。但是 AI 应用要设计缓存就比较难了。因为一段自然语言可能有 N 种说法，人听了知道这是一个意思，但不同的说法，计算机就对应了不同的 Key，并不是和 Value 是一一对应的关系，因此需要通过向量数据库来实现缓存，通过计算向量之间的距离来确定 Key，然后给出一个相对靠谱的答案。所以说，在前端挂向量数据库是一个必然的诉求。还有一个问题就是服务器的成本非常高。大模型有一个计量单位叫 Token，Token 量会影响成本，还需要实现 Token 级别的限流，保障可用性。

把以上需求对应的能力都集成进来的话，就需要大量的开发工作了。因此，我们在网关上设计了大量开箱即用的插件，这些插件都是开源的，包括缓存管理、敏感词过滤、请求响应转换等能力，并兼容了各类主流大模型、向量数据库和 AI 内容审核库，大幅降低了用户的集成成本。

我们再来看一些常见的场景。基于输出效果的考虑，我们训练了一个垂直领域的小模型。优先通过小模型去提供服务，但可能稳定性没那么高，所以一旦小模型出现不可用的时候，就会自动切换到大模型，进行兜底。虽然回答准确率不如小模型，但是相比模型失效不可用的情况，还是比较有意义的。

另外，当出现模型请求非常慢，需要让用户等待非常长时间的时候，此时可以通过 Fast Fail 机制设置一些超时时间，直接调度到其他到大模型上，而非反复尝试。

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

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

高集成：一键发布 API 服务

AI 时代，API 的数量和调用量都会暴增。因此，API 的全生命周期管理就变得至关重要了。虽然 API 管理这件事情喊了很多年，但为什么在国内的发展相对比较缓慢呢？是因为软件迭代的时候，API 给软件工程带来的开发效率提升效果并不明显。

基于这些思考，我们从 API First 开始，就考虑如何让开发提效更加明显。从 API 的设计、API 文档、Mock、端到端的代码生成以及 API 测试，我们都提供了全生命周期的管理能力，让开发者在网关上就能完成 API 相关的全部动作，并且在每一个环节，我们都尽可能的加入 AI 的支持，协助生成 API 文档，生成代码进行 Mock 测试等。
当 API 上线后，便可以对外提供服务了。这个时候，我就要去做一些 API 相关的防护。我们把安全防护、限流、超时重试和跨域重写等常见能力均内置在网关中。
如果希望把通过 API 构建开放平台，实现变现，也就是所谓的 API 货币化。API 货币化后，API 就是一个商品，我们在网关中内置了额度管理、API 计量计费等能力。

高集成：灵活扩展 AI 组件

当我们内置的插件不够用的时候，可以通过 Wasm 沙箱，自行开发插件。为什么要一直强调沙箱呢？这就是高可用的范畴了。当我们上线了很多插件的时候，万一某一个插件不可用了，会不会影响我们其他插件和网关的运行呢？其实是不会的，因为插件是沙箱机制运行，单个插件只会影响单个沙箱。因此，大家在不满足业务诉求的基础上，可以放心大胆的自定义插件。云原生 API 网关不仅支持 Wasm 插件，还支持 WAMR 插件，并且对插件的可观测体系做了非常大的增强，方便大家去优化和完善插件。

零信任：AI 防护 & 内容合规

零信任旨在帮助我们的应用能够构建一个端到端的安全体系。安全是一个非功能性需求，构建一个应用其实非常简单，我们只要写一些业务代码就能使用了。但是要把一个应用发布上线，提供众多用户使用，要考虑的事情就非常多。非功能性的需求，远远大于功能性需求的设计和开发的工作量。因此，我们希望通过网关就能一站式的帮助大家把这些事情都搞定。

首先是鉴权，对访问进行自定义控制。云原生 API 网关不仅支持支持 JWT/OIDC ，同时也支持自定义多种认证登录&退出，集成 IDaaS 对接支付宝、淘宝等三方认证。
其次是安全防护，用于防御恶意流量，确保应用可以正常对外提供服务。云原生 API 网关和阿里云的 WAF 做了深度集成。有些人说，我们对安全性要求没那么高，也不希望为此付钱。我能不能用一些开源的安全防护，也是没问题的。云原生 API 网关也支持开源 WAF 插件的集成，能够起到一定的防护效果。
内容合规。我们集成阿里云的绿网产品，可以快速使用绿网能力实现安全过滤。同时针对成本敏感的企业，我们也提供了开源的内容过滤插件。
流量防护。防护预期外的流量，保障业务稳定可用。业务后端只能支持 1000 个人的访问，突然来了 2000 个人，如果都把它放进来的话，可能前 1000 个的服务也会受到影响。

流量防护范畴中的容量规划是一个非常复杂的话题，涉及到基础资源的构建、容器的管理、应用之间的依赖关系、高峰水位的评估，同时也和真实的流量形态息息相关。

以 2012 年双 11 为例，当时我们坐在那看着一个个雪崩的时候，是束手无策的，重启也没有用，重启了它就又崩掉了，只要洪峰流量在就解决不了。2013 年的时候，我们发明了一个利器叫全链路压测，模拟 0 点那一刻的真实流量。我们从全国四面八方的 CDN 去模拟，然后来压测整个链路。流量的真实形态还和和我双十一的运营策略有关，哪些是热度的商品，哪些商家比较热，而且流量来的形态也不一样，有些流量是缓慢上升的，有些流量可能是脉冲式的。一台机器假设他能扛 100QPS，这 100QPS 是脉冲式的来，还是缓慢上升的来，给服务器的压力是不一样的。因此，我们就通过容量规划的机制去不断的模拟真实的流量，增强架构的健壮性。云原生 API 网关把阿里的这些内部实践都一一做了沉淀，并转化成产品能力，集成了 Sentinel，支持 Token/API/服务级别流控，并集成了 Redis，支持集群流控。

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

结合阿里大规模生产经验从操作系统/网络/内核深度调优，流式输出的性能比 Nginx/SCG 高出 90%，整体性能提升 40%。
将网关和 Intel 芯片、神龙服务器、阿里龙蜥操作系统合作，进行软硬一体化设计，HTTPS QPS 提升 112%，RT 下降 50%，硬件的压缩解压缩性能提升了 300%。压缩解压缩性的优势尤为适用于 AI 场景，可以极大节省端到端加密传输时的带宽压力。

高可用：服务治理无损变更

高可用要从两个维度来考虑。第一个维度，你想帮别人做高可用，首先自己要高可用。我们坐飞机的时候，广播里都会说请系好自己的安全带，再去帮你的小孩子系好安全带。如果发生灾难的时候，请你自己先带好氧气面罩，再帮小孩子带好氧气面罩。我们也是秉承这样的一个原则，首先自己就要做到高可用。所以在整个网关技术架构体系里，我们的数据面、控制面、控制台都是隔离开来的。也就是说，当控制面出现问题或者控制台出现问题的时候，并不会影响到数据面，这是我们自己要做的高可用。

第二个维度，我们的数据面是支持热更新的，而不是基于那种非常重的 reload 机制来更新。这也大大提升了数据面的稳定性。在此基础之上，基于阿里内部的高可用实践，再帮助运行在云原生 API 网关上的用户去做高可用。

阿里内部在做安全生产的时候，每年都会设定所支撑业务的目标，例如通义千问、淘宝设定一个业务目标，管控过程有一个概念叫变更三板斧，即可灰度、可观测、可回滚。大家一听很容易理解，看起来也很容易做，但实际落地还是比较有挑战的，尤其是灰度，按什么维度来灰度，是按机器维度来灰度，还是按用户维度来灰度。这都需要做大量的改造和大量的适配，才能够满足各类灰度的诉求。因此，我们开始思考，能不能把灰度的能力也都集成到我们的商业产品里，让客户的业务跑在我们云产品上，天然就具备灰度的能力。于是，我们就把整个灰度的能力融入到云原生 API 网关里，这个灰度能力从微服务请求开始，到网关，到后端服务，再到消息中间件，都是支持的。

云原生 API 网关是支持全链路的灰度的。首先在端上设置泳道，再给泳道打标。所有带有这种标记的请求，都会自动进入这个泳道，逐步验证、逐步切流。再是可观测，有些人说我做了灰度，但是发现不了问题。例如有 100 台机器，拿两台做了灰度，灰度的这两台机器流量都跌零了，但我大盘也就跌了两个点，问题并不明显，这时候可观测就至关重要了。所以，对于灰度环境，我们要提供一套完整的可观测能力。虽然只有两台机器，但是对于这个环境而言，就是 100% 失效。哪怕挂了一台，也是 50% 失效，而不是流量的 1%。针对灰度环境，我们有专门的观测体系和观测大盘。在创建泳道后，哪怕出现一点点抖动，也能够通过观测大盘发现问题，以判断灰度效果是否符合预期。

另外，服务运行期间可能要处理一些请求，做上线或者下线的动作，或者扩缩容。这就涉及到优雅上下线的能力。我们能不能等服务处理完再进行下线，能不能等应用全启动完之后，检查没有问题了再上线，甚至先做一些预热。于是，我们就在网关里集成了优雅上下线的能力。同时也集成了主动健康检查，一旦服务出现问题，可以确保不再直接对外提供服务。

高可用：全局容灾

当某个地域出了问题，我该怎么办？这时候，多 AZ（Available Zone：可用区）就显得至关重要了。

容灾概括来讲，就是冗余和隔离。物理世界已经给了我们非常多的案例。比如说飞机的发动机是多个引擎，这就是典型的冗余，并且它每个引擎都是独立工作，这就是隔离。那我们大街上看到的油罐车，里面的液体那么多，如果司机一脚急刹车会不会产生一些后果？但实际上，油罐车里面都是用一个个隔板隔离开来的还有燃油车的油箱，里面也是做了隔离的。这些都是物理世界容灾的经典案例。

先说冗余，我们不能把鸡蛋都放在一个篮子里，这个篮子破了所有鸡蛋都破了。所以我们尽可能的使用多 AZ 去部署，把业务放部署到多个区域。再说隔离，确保多 AZ 之间的流量是隔离开的，出现问题的时候，能够进行有效的调度。

再举个例子，比如今天的会议突然改地址了，我们在网关这个入口处就告知用户，变更后的会议室地址，而非等人都进来后，再逐个通知。这就是网关所起到的隔离作用。有了网关，我们就能在入口处对流量进行有效的调度。当后端发生变化的时候，直接把流量引到指定的地点去就可以了。总的来讲，就是通过云原生 API 网关进行流量的统一调度，后端做多 AZ 部署，并按照比例或者特征把流量调度到对应的地方。当一方发现问题的时候，我们直接把流量调度到另一方就可以了。

最后，云原生 API 网关还提供 AI 的诊断断和答疑能力。若应用遇到报错，比如 5xx、4xx 错误，只要接入了云原生 API 网关，我们会直接进行数据采集，帮你去分析和定位问题，并给出建议的解决方案。

云原生 API 网关的实践 Demo

内部实践

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

第一个业务诉求是支持长链接的热更新。 如果按照传统的处理方式，每一次配置更新，都要让配置连接断掉，这个体验是非常差的。AI 技术迭代这么快，每天的变更是非常频繁的，这就要求网关能够支持热更新。

第二个业务诉求是支持流式输出。 AI 产生的结构都比较大、比较长。如果都堆积服务器上，压力会比较大，客户这边看到一片空白，体验也不好。因此通过流式输出，大模型可以把结果持续性的输出给用户，体验更好，服务器的压力也会更小。

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

第四个业务诉求是支持超大规模的路由/域名这变更。 如果是传统网关，变更一次的推送时间非常长，reload 时间也很长，导致服务较长时间的中断。这还会带来一些衍生性的风险，例如突发流量进来后可用性下降的暴露风险，内存消耗变大等等。PAI 切换到我们的网关后。路由配置生效 RT 从原 10 分钟降到 30 秒内。

外部客户

再说两个外部客户。一个是零一万物，这是由国际 AI 专家李开复博士创办的全球化 AI 公司。他们提供了很多自己的大模型，并且把它开放出去。同时提供了大模型的 API 服务。在对 API 对外进行暴露的时候，也遇到了所有 AI 厂商都会遇到的长连接、高延时、大带宽等问题，限流稳定性，以及 Token 计量计费的问题。通过云原生 API 网关的插件热更新能力、细颗粒度的集群限流能力、流式处理能力、丰富的可观测能力，把这些问题都解决掉了。另外。我们提供的 Fast Fail 和 Failover 机制，提升了业务的可用性。

另一个客户是震坤行工业超市，是一家数字化的工业用品服务平台。他们研发了工业用品垂直领域的专用模型，并对外提供服务。他们担心的是万专用模型出现问题，能否自动切换到其他大模型进行兜底。这就是典型的云原生 API 网关的需求场景。客户的动手能力和执行力都非常强，在我们介绍云原生 API 网关的当天下午要体验了一下。不到半天时间，就把 Fast Fail 和 Failover 机制已经配好了，从前端流量代理，再到后面做限流拦截，并实现了专用模型和通用大模型之间的无缝切换。

随着客户更加深入了解云原生 API 网关，他们逐步使用了网关的更多能力，包括缓存 RAG 插件、提示词模板，实现了用户请求时反馈更加精准的推荐。此外还使用了网关的可观测能力、Token 限流、Token 计量计费等功能。

商业和开源

除了提供商业产品外，我们也提供了开源方案，供客户自由选择。类似的我们在云上提供了 Nacos 的商业托管版微服务引擎 MSE，RocketMQ 的商业托管版云消息队列 MQ。云原生 API 网关就是 Higress 这个开源网关的商业托管版。

开源和商业化，本质上是相辅相成的关系。我们最开始就是想通过开源将自己的技术沉淀开放出去，尽可能释放技术红利，帮助客户加速业务的发展。这个过程中，有不少企业客户反馈：“仅仅是开源还不够，你们能不能提供一些商业增值服务，帮我们更快的把体系支撑起来，有人进行商业兜底，这样子我们也会更加放心的去使用开源。”因此，我们在开源之后，也迅速提供了对应的商业产品，同时来确保开源的持续投入。

Higress 开源后，社区的活跃度非常高。累计发布 35 个版本，Folk 400+，Contributors 90+。而且 Higress 的质量是非常高，单测覆盖率能够做到 90% 以上，这在所有的开源项目中是非常难得的。另外，我们提供了非常不错的可扩展机制，即 Wasm 沙箱，通过发动了社区的力量，来提供丰富的插件市场。且这些插件都是开箱即用的。

在 AI 高速发展的这两年里，我觉得我们在网关上的积累和沉淀，现阶段已经可以满足大部分 AI 应用的诉求了。欢迎大家参与 Higress 的开源社区，和我们一起把它打造成 AI 时代最好用的 AI 网关。也欢迎来试用我们的商业产品云原生 API 网关，快速构建你的 AI 应用。最后，我们通过一段 Demo 来切身体会下云原生 API 网关的产品能力。

云原生 API 网关：https://www.aliyun.com/product/ap

Higress：https://higress.cn/