网关在网络通信中扮演着诸多角色，包括数据转发、协议转化、负载均衡、访问掌握和身份验证、安全防护、内容审核，以及做事和 API 颗粒度的管控等，因此常见的网关种类有流量网关、安全网关、微做事网关、API 网关等。在不同语义下，网关的命名也会有所不同，例如 K8s 体系下，有 ingress 网关，在 Sping 体系下，有 Spring Cloud Gateway。但不论如何命名，网关的管控内容险些都离不开流量、做事、安全和 API 这 4 个维度，只是功能侧重不同、所遵照的协议有差异。
其余，随着互联网从 Web 2.0 迈进到 AI 时期，用户和互联网的交互办法，AI 时期下互联网的内容生产流程都发生了显著的转变，这对根本举动步伐（Infra）提出了新的诉求，也带来了新的机遇。Infra 包含的内容非常丰富，本文仅从网关层面分享笔者的所见所感所悟。
我们先来看一些 AI 时期涌现的新场景和新需求：
在支持大量 LLM 客户的过程中，我们也看到了一些行业发展趋势，借本文分享给大家：
互联网内容的生产机制将从 UGC（User Generate Content） 转变为 AIGC（Artificial Intelligence Generate Content），互联网流量增长，除了要考虑传统的 SEO，还须要考虑 AI 抓取下的 SEO。目前处于 AI 时期的 Web 1.0 阶段，基于静态内容天生，可以预见，AI 时期的 Web 2.0 不久会到来，基于理解互联网内容来识别页面中供应的“可操作能力”，来完成繁芜任务，真正的 Web 3.0 也将由 AI 来实现。API 是 LLM 运用的一等公民，并引入了更多流量，催生企业新的生命力和想象空间。LLM 运用对网关的需求超越了传统的流量管控功能，承载了更大的 AI 工程化义务。AI 场景下的新场景和新需求
Cloud Native
比较传统 Web 运用，LLM 运用在网关层的流量有以下三大特色：
长连接。由 AI 场景常见的 Websocket 和 SSE 协议决定，长连接的比例很高，哀求网关更新配置操为难刁难长连接无影响，不影响业务。高延时。LLM 推理的相应延时比普通运用要赶过很多，使得 AI 运用面向恶意攻击很薄弱，随意马虎被布局慢要求进行异步并发攻击，攻击者的本钱低，但做事真个开销很高。大带宽。结合 LLM 高下文来回传输，以及高延时的特性，AI 场景对带宽的花费远超普通运用，网关如果没有实现较好的流式处理能力和内存回收机制，随意马虎导致内存快速上涨。传统 Web 运用中普遍利用的 Nginx 网关难以应对以上新需求，例如变更配置须要 Reload，导致连接断开，不具备安全防护能力等。因此国内外均涌现了大量基于 Envoy 为内核的新一代开源网关，本文将以笔者掩护的 Higress (https://github.com/alibaba/higress) 为例展开描述。
Higress 已经为通义千问 APP、灵积平台 (通义千问 API 做事)、人工智能平台 PAI 供应 AI 业务下的网关流量接入，以及多个头部 AGI 独角兽供应 API 网关。这篇文章详细先容了 Higress AI 网关的能力：《Higress 发布 v1.4，开放 AI 网关能力，增强云原生能力》
如何实现网关配置的热更新
互联网从 Web 1.0 演进到 Web 2.0 的时期，互联网从静态内容为主，变为动态更新的 UGC 内容为主，大量用户开始高频利用互联网。用户利用形态，以及网站内容形态的改变，催生了大量技能的变革。例如 HTTP 1.0 到 HTTP 1.1 协议的升级，办理了连接复用的问题。又例如以 Nginx 为代表的基于异步非壅塞的事宜驱动架构的网关出身，办理了 C10K 问题。
到了 AI 时期的互联网，LLM 驱动的对话式场景，大量采取 SSE/WebSocket/gRPC 等长连接协议来坚持会话。网关除了要办理并发连接问题，还须要办理配置变更导致连接断开的问题。配置变更时的连接断开，不但导致用户会话断开，影响体验，在高并发场景下，断开后的并发重连风暴很有可能将网关和后端业务同时打挂。
而类似 Nginx 这样 Web 2.0 时期出身的网关，并不能办理此问题，Nginx 的整体配置文件发生任意变更，都须要重启 Worker 进程，会同时导致客户端连接（Downstream）和做事端连接（Upstream）断开：
笔者参与掩护的 Higress 开源网关，利用 Envoy 作为数据面，来办理这一问题。Envoy 站在 Nginx 等网关的肩膀上，对网关配置做了更合理的抽象。例如将处理客户端连接（Downstream）的监听器（Listener）配置创造定义为 LDS（Listener Discovery Service），将处理后端做事连接（Upstream）的做事集群（Cluster）配置创造定义为 CDS（Cluster Discovery Service）。LDS 和 CDS 可以独立更新，从而 Listener 连接池参数更新不会断开 Upstream 连接，Cluster 连接池参数更新变了不会断开 Downstream 连接。
对付跟连接无关的配置，又做了进一步抽象，例如路由配置创造定义为 RDS（Route Discovery Service），TLS 证书 / 密钥配置创造定义为 SDS（Secret Discovery Service），都可以独立更新，那么无论是路由变更，还是 HTTPS 证书变更，都不会导致任何连接断开：
如何在网关层做好安全和流量防护
当前的 AI 技能，尤其是 LLM 正处于快速发展阶段。虽然模型压缩、知识蒸馏等技能正被广泛运用以提高效率，但 LLM 运用的资源花费仍旧显著高于传统 Web 运用。
针对传统的 Web 运用，做事端处理单个要求的资源花费常日不会大幅超过客户端，因此对客户端来说，发起分布式谢绝做事（DDoS）攻击的成本相对较高。然而在 LLM 运用的场景中，客户端通过发送长文本或提出繁芜的推理问题，可以轻易增加做事真个负载，而自身资源花费甚微。这种情形突显了在 LLM 运用中支配强大的网关安全防护策略的主要性。传统网关，常日具备两类限流能力：
Higress 不仅支持这些传统限流能力，例如每秒、每分、每小时和每天的要求次数限定（QPS/QPM/QPH/QPD），还引入了对令牌数量的细粒度管理，采取每分钟、每小时和逐日令牌数（TPM/TPH/TPD）作为衡量指标，除了 QPS，还支持面向 Token 吞吐的限流防护。
“令牌”（Token）在这里作为一个衡量单位，更准确地量化了 LLM 处理的数据量。对 LLM 运用而言，以令牌而非传统要求次数来计量利用情形，更能贴切地反响资源花费和本钱开支。同时也支持多种限流统计维度，包括：API、IP、Cookie、要求 Header、URL 参数和基于 Bearer Token 认证的调用方。
AI 场景下，后端保护式限流尤其主要，很多 AGI 厂商都有免费的 Web 运用吸引用户流量，而一些黑灰产可能会爬取页面调用封装成收费 API 来供应给用户实现牟利。这种情形下就可以利用 Higress 的 IP、Cookie 等维度的保护式限流进行防护。
此外，昔时夜模型未经由适当的过滤和监控就天生回合时，它们可能产生包含有害措辞、误导信息、歧视性辞吐乃至是违反法律法规的内容。正是由于这种潜在的风险，大模型中的内容安全就显得非常主要。在 Higress 中，通过大略的配置即可对接阿里云内容安全做事，为大模型问答的合规性保驾护航。
如何应对大带宽和高延时的流量特色
除了能针对 Token 进行限流，基于 Token 的完全可不雅观测能力，也是 AI Infra 中不可或缺的，例如供应日志、指标、告警等可不雅观测能力。下方展示的限流、不雅观测能力，都依赖对 HTTP 要求 / 相应 Body 的解析处理。
传统网关，如 Nginx/Openresty，以及基于此实现的 Kong/APISIX 等在 Lua 脚本中处理 Body 时，哀求必须对要求 / 相应开启缓存。而基于 Envoy 的开源网关，例如 Higress，其插件扩展机制是基于 Wasm 实现的，能够支持对 Body 的流式处理，以处理要求 Body 为例：
func onHttpRequestBody(ctx wrapper.HttpContext, config Config, chunk []byte, isLastChunk bool, log wrapper.Log) []byte { log.Infof("receive request body chunk:%s, isLastChunk:%v", chunk, isLastChunk) return chunk}
在 AI 场景下，由于大带宽 / 高延时的流量特色，网关是否对要求 / 相应进行真正的流式处理，影响是巨大的。
首先，LLM 场景下如果网关没有实现流式相应，将严重影响用户受到首个相应的韶光，其速率影响能从秒级变到分钟级，严重影响用户体验。其次，是对资源开销的影响。以 Higress 的一个开源用户 Sealos 举例（旗下有 FastGPT 等 AI 干系平台产品），在利用 Nginx 时由于开启了要求 / 相应缓存，在 AI 业务运用被高并发访问时，网关资源水位占用途于崩溃边缘。迁移到 Higress 之后，网关只需很少资源。由于 Higress 供应了完全的流式转发能力，而且供应的插件扩展机制也可以流失落处理要求 / 相应，在大带宽场景下，所需的内存占用极低。内存虽然比较 GPU 很廉价，但内存掌握不当导致 OOM，导致业务宕机，丢失不可估量。下图是常态流量下，Sealos 切换前后网关利用资源的比拟：
如何提升海量域名、海量情由规则下的多租能力
在 AI 场景下，Envoy 的热更新能力备受青睐，Higress 的一些 AI 平台场景的用户，在一开始也选用了基于 Envoy 的网关，例如 Contour、Gloo、Istio gateway 等。但大都会碰着两个问题：
给每个用户 or 每个模型分配一个域名，数量级达到一万规模时，新建路由的生效速率至少要 1 分钟；对多个租户域名利用同一本泛域名证书，开启 HTTP2 时，浏览器访问会碰着 404 问题。对付第一个问题，其根本缘故原由在于路由规则下发办法不足风雅，社区开拓者对此进行过分析。与此比较，Higress 可以在域名级别进行分片加载，纵然达到一万个域名，新增路由的生效韶光也只需三秒。此外，Higress 支持按需加载机制，即只有在吸收到特定域名的要求时才加载该域名下的路由配置。在配置了大量域名的环境下，这种策略只加载生动的路由配置，显著减少了网关的内存利用。
关于第二个问题，浏览器在 HTTP2 环境中会只管即便复用连接。两个要求的域名不同，但解析到的 IP 地址和利用的证书是相同时，连接复用会导致 Host 要求头与建立连接时的 SNI 不匹配，进而在 Envoy 场景下产生 404 缺点。多数基于 Envoy 的办理方案是返回 421 状态码，提示浏览器断开连接并重新发起要求，但这个办理方案在浏览器兼容性上存在问题。于是，Higress 借鉴了 Nginx 的办法，使 SNI 的查找（TLS 层）与 Host 头部的查找（HTTP 层）分离，许可它们不匹配，从而能精确地路由配置（在哀求客户端证书验证的场景例外）。
Higress 支撑海量域名的能力，也是浩瀚 MaaS/SaaS 做事用于实现多租的关键。比如智算做事 PAI- 灵骏平台在近期将网关从同样基于 Envoy 实现的 Contour 迁移到了 Higress 之后，新增路由生效的韶光从分钟级变为秒级，同时整体花费的云资源也大幅低落。
AI 场景下，网关比我们想象中更能打
Cloud Native
传统 Web 运用，网关扮演的根本角色是流量管理。但在 AI 场景下，网关正承载着更大的 AI 工程化义务，分别表示着 MaaS/AGI 接入层、运用接入层、和企业内部各种系统对接等。
MaaS/AGI 接入层
整体架构如下，网关对接入层进行流量管理，除此之外还具备知足负载均衡和流量灰度和不雅观测的能力。
负载均衡：
由于 AI 场景下，网关的后端常日是模型做事本身，对网关的负载均衡能力提出了分外哀求。由于 LLM 场景具有高延时，且不同要求差异大的特点，传统的 Round Robin 负载均衡策略无法精确平衡负载。Higress 目前采取基于最小要求数的均衡策略，将要求优先转发给当前处理中要求最少的后端节点。针对模型做事负载均衡的寻衅，Higress 操持在未来通过调用一个低延时的小参数模型进行旁路预测，以估计每个后端节点的实时负载，从而只管即便将要求发送给负载最低的后端节点。
流量灰度和不雅观测：
AGI 厂商高度依赖 A/B 测试和做事灰度能力来进行模型迭代。作为流量入口，AI 网关须要在流量灰度和不雅观测方面发挥关键浸染，包括灰度打标以及入口流量延时和成功率等指标的监测。Higress 凭借其在云原生微做事网关领域的履历，已经积累了强大的能力来知足这些需求。
AI 运用层
整体架构如下：
跟随 GPT4 等模型的爆火，呈现了大量的精良的 AI SaaS 运用，例如：
makelogo.ai：AI 天生产品 LogoMyMap.ai：AI 赞助方案 IdeaGamma：AI 天生 PPTPodwise：AI 赞助查看播客许多 AI 运用开拓者，尤其是独立开拓者，常日不会自己支配模型做事，而是直策应用模型厂商供应的强大 API 来实现创意运用。值得把稳的是，许多开拓者来自海内。然而，由于底层技能依赖于 OpenAI 等外洋 LLM 厂商，这些技能可能不符合海内法规。为了避免潜在的麻烦，这些开拓者每每选择将产品推向国际市场，而不是面向海内用户。
随着海内大模型技能逐渐遇上 OpenAI 等厂商，并且海内 API 在价格上具有竞争上风，越来越多的 AI 运用估量会选择利用海内厂商的 API 来实现干系功能。这将对网关提出特定需求：
通过网关的统一协议，屏蔽不同模型厂商 API 的调用差异，降落适配本钱。对涉黄涉政等敏感内容进行屏蔽和过滤，更好地符合海内法规哀求。切换模型后的 A/B 测试以及效果不雅观察和比拟，包括延迟、本钱、用户利用频率等成分。Higress 目前支持的 LLM Provider 有：通义千问、OpenAI/Azure OpenAI、月之暗面、百川智能、零一万物、智谱 AI、阶跃星辰、文心一言、腾讯混元、DeepSeek、Anthropic Claude、Groq、MiniMax、Ollama 等，借助 Higress 生动的开源开拓者社区，支持的类型还在持续增加中。
企业内部 AI 网关
整体架构如下：
大量 AGI 厂商在闭源和开源模型能力方面展开竞争，而受益者紧张是企业用户。企业在选择模型时须要在性能和本钱之间做 trade-off。面对浩瀚模型，尤其是在厂商供应的 API 不一致时，企业须要一个统一的网关来屏蔽模型协议的差异，从而供应一个统一接口，便于企业内部系统的对接和利用。在这种场景下，网关的架构类似于 ESB（企业做事总线）的架构，即所有内部 AI 流量都通过网关进行统一管理。这样的架构带来了以下好处：
整天职摊打算：借助网关的不雅观测能力，可以审计企业内部门歧业务部门的 Token 花费量，用于整天职摊并创造不合理的本钱。提高稳定性：基于网关供应的多模型对接能力，当主用模型调用失落败时，可以自动切换至备用模型，保障依赖 AI 能力的业务稳定性。降落调用本钱：在一些固定业务流程中，LLM 接口的输入输出相似性较高时，可以基于向量相似性进行缓存召回，从而降落企业的 AI 调用本钱。认证和限流：通过对企业内员工的 API 调用进行限量掌握，管理整体本钱。内容安全：实现统一的内容安全管理，禁止发送敏感数据，防止企业敏感数据泄露。这种架构下，网关不再只是接入层的流量网关，而是要处理来自所有依赖 AI 能力的业务模块的访问流量。网关更能打了。
畅想 AI 时期的互联网发展
Cloud Native
笔者创造在 AI 火了之后，大家已经很少提 Web 3.0 的观点了。而且很有趣的一个事是，CDN 和网络防护供应商 CloudFlare，已经将掌握台内的一级入口 Web 3.0 换成了 AI，并集成了 Workers AI 和 AI Gateway 这两款产品。而笔者以为，真正的 Web 3.0 大概将由 AI 带来。
就像 Web 1.0 到 Web 2.0 的演进，用户的交互办法和互联网的内容形式发生了彻里彻外的改变，我们实在已经身处在类似的改变之中。例如，笔者的常用搜索工具从 Google 换到了 Perplexity。做互联网流量增长，除了要考虑传统的 SEO，还须要考虑 AI 抓取下的 SEO，下面来自 Perplexity 对这一问题的回答：
到并不是说 Perplexity 未来一定会替代 Google，但这种改变实在反应了一种趋势：
从用户角度看，用户从主动参与互联网转变为通过 AI 帮助参与。从内容角度看，不仅须要做事于真实用户，还要同时做事于 AI。Perplexity 这样的工具还只是基于静态内容，可以类比为 AI 时期的 Web 1.0。可以预见，AI 时期的 Web 2.0 会是：
电阛阓景下，在用户浏览商品时，AI 将充当导购，根据商品信息与用户对话，并在用户确认后自动下单；出行场景下：AI 将根据用户的出行目标地点自动安排旅行操持，理解用户喜好，预订沿途餐厅和酒店；OA 场景下：用户须要操作资源时，AI 将自动提交审批申请，查询审批状态，并在获批后完成资源操作。在这种模式下，AI 须要理解互联网内容，并识别页面中供应的“可操作能力”，从而代替人类实行操作。苹果宣告将在 iOS 18 中 大幅提升 Siri 的能力，未来 Siri 将能够访问运用程序的各种功能，这也须要运用程序为 AI 供应“可操作能力”的声明。HTML 也有干系社区提案，让 AI 可以更方便地识别页面中的可实行任务，明确其输入和输出定义。
未来的互联网内容，无论是 APP 还是 HTML 场景，都将面向 AI 进行改变。核心在于让 AI 知道如何操作页面内容，从而帮助用户完成繁芜任务。为 AI 供应的“可操作能力”声明，实际上便是 API 声明。当前，大量互联网运用，尤其是 ToC 运用，API 仅在内部开拓过程中利用，最高频利用 API 的可能是前端或 BFF 层的开拓职员。在海内，由于研发本钱普遍低于国外，不会为了降落前后端对接本钱，而去优化 API 设计，开拓过程中每每忽略了 API 的主要性。因此，虽然在外洋 API 管理产品的市场竞争已经是一片红海，但在海内 API 管理以及 API First 的理念并不遍及。
随着 AI 操作互联网场景的不断增加，API 将成为 LLM 运用的一等公民，API 管理的主要性将愈发明显。类似于 Perplexity 在抓取页面内容时利用清晰的标题、小标题和列表以便 AI 更随意马虎理解和提取内容；定义清晰的 API、明确的输入输出参数，以及 API 的版本管理，将变得至关主要。
对网关来说，应回归实质，在 AI 的加持下，帮助用户做好 API 的设计、管理将成为核心能力。而通过合理设计的 API，网关也可以更深入地理解所处理流量的业务含义，从而实现更智能化的流量管理。
