服务网格与网关：Ingress与Gateway API

可视化演示

Ingress与Gateway API是云原生流量编排入口。拖动滑块调整流量。观察两种API的架构差异、路由流程与性能优化机制。

流量入口基础

一座写字楼再豪华，如果正门只够两个人并排走，高峰期就会乱成一团。Kubernetes 集群也是如此：外部用户要访问 AI 推理服务、模型 API，首先经过的就是“入口”。在云原生世界中，这个入口通常由 Ingress 和 Gateway API 来定义。你可以把 Ingress 理解成贴在写字楼门口的“接待说明牌”，上面写着：哪些访客走东门、哪些访客坐哪部电梯、哪些访客需要登记。不过，说明牌本身不会行动，真正守在门口执行接待工作的是 Ingress Controller，也就是写字楼的门岗保安。

从技术上看，Ingress 是 Kubernetes 的一种 API 资源对象，它描述“外部访问服务的规则”；Ingress Controller 则是独立部署的代理程序，负责监听 Ingress 对象的变化，把规则翻译成 Nginx、Envoy 等网关的配置。外部流量进入集群，再从服务暴露出去，这种“楼外到楼内”的流向叫南北向流量；而服务与服务之间互相调用，属于“楼内房间到楼内房间”，叫东西向流量。Ingress 解决的是前者。

入口的接待能力决定了整个系统能扛住多大的访问量。我们可以用一个小公式来估算：

所以，提高入口性能不只是加带宽，还要同时关注“减少响应耗时”和“合理设置并发连接”。这就像写字楼想要提高进门效率，既要加快登记速度，也要拓宽门廊，而不是只把门牌号写得更漂亮。

Ingress核心原理

回到前台保安的视角。保安手里有一本规则册：访客说“我要去 2 楼财务”，册子上写着“2 楼财务在 B 区，预约过才放行”。Ingress 也是一本规则册，规则由 host 和 path 组成。比如，访问 api.ai.com/v1/chat 时，Ingress 规则会把这个请求指向名为 chat-service 的 Service；而访问 api.ai.com/static 时，则指向静态资源服务。这样，一个入口就能根据 URL 把请求分流到不同后端。

然而，规则册不能自己执行。Ingress Controller 会实时 watch Kubernetes API Server，一旦 Ingress 规则发生变化，它就把新规则转换为代理配置，并加载到 Nginx 或 Envoy 等网关代理中。网关代理是真正站在门口的保安：它收到请求后，按规则册找到对应后端，再把流量转发进去。它还经常负责 TLS 终止，也就是把外部 HTTPS 加密流量解密成内部 HTTP，避免每个后端都做一遍加密解密；同时支持多域名共用一个入口，就像同一栋楼里多个公司共用正门。

当入口把请求转到多个后端时，需要留意每个后端的“拥挤程度”。一个简单的负载指标是：

Ingress 的规则册越是精细，越要考虑后端负载。就像前台保安如果发现某个公司在排队，就应该引导访客去另一家同样能处理业务的办公室。

Gateway API进阶

传统 Ingress 就像一名保安身兼数职：既决定装什么样的大门，又制定访客规则，还负责接待每个人。当楼里只有几家公司时还行，可一旦有几十个团队，就会互相踩脚。Gateway API 的诞生，就是要把这些职责拆开：物业负责选门禁品牌，安保负责设置入口实例，各家公司自己提交访客接待单。

在 Gateway API 中，GatewayClass 对应“物业选定的门禁供应商”，它声明使用哪种控制器实现；Gateway 对应一个具体入口，相当于楼下真正装好的那台门禁机；HTTPRoute 则是业务团队提交的路由规则，描述“什么请求去什么服务”。三者分离后，基础设施管理员和业务开发者可以并行工作，甚至可以跨命名空间引用路由，策略也不再像 Ingress 注解那样散落各处，而是能统一挂载到 Gateway 或 HTTPRoute 上。

路由规则往往要同时满足多个条件，比如“路径是 /v1/chat，且请求头里带有灰度标签”。我们可以用组合概率来理解：

Gateway API 的智能之处，是把“谁定门禁、谁管入口、谁定义路由”彻底分层。这就像物业、安保、公司前台各司其职，整栋楼的入口管理才真正走向规模化。

服务网格协同

访客通过门禁进入楼内后，要去不同的房间。房间之间怎么沟通？总不能每家公司都派一群人到处跑。于是，每个部门安排了一位“专属秘书”——Sidecar 代理。这位秘书负责替部门送文件、接收文件、做记录，还负责检查对方身份。一个 Pod 旁边挂一个 Sidecar，就相当于每个房间门口都有一位秘书，服务之间的所有通信都从秘书手里经过。

服务网格处理的就是这种东西向流量。它负责服务发现，让秘书们知道彼此在哪；负责 mTLS，让每次通信都加密且互相验证身份；还负责可观测性，把每次调用的延迟、状态、错误都记录下来。API 网关处理的是“楼外到楼内”，服务网格处理的是“楼内到楼内”。两者并不冲突，反而是配合关系：访客由门禁接入后，再由秘书带着去正确房间。

当楼内服务越来越多时，服务网格需要维护的安全通道数量会快速增长。例如 N 个服务都使用 mTLS 通信，两两之间都要建立可信连接：

服务网格的可扩展性挑战也来源于此。正因如此，很多系统并不会让所有服务都全互联，而是通过服务发现和分层路由，把通道控制在一个合理范围。门禁管好外面，秘书管好里面，整栋楼才能有序运转。

调度与容错算法

门禁和秘书都解决“去哪”的问题，但具体“去哪个房间”需要算法说了算。最常见的策略是加权负载均衡：每个后端房间根据自己的硬件能力，拥有不同权重。能力强、机器多的房间权重高，承接更多请求；刚扩容的新房间权重低，先接收少量流量观察情况。

权重分配可以用一个概率公式描述：

光有负载均衡还不够，系统还要学会容错。比如，某个后端房间正在冒烟，如果一直把请求送进去，只会烧得更厉害。这时需要熔断降级：连续失败次数超过阈值后，入口直接“拉闸”，快速返回默认响应，而不是继续排队等待。重试也要有限制，失败就重试，看起来稳妥，但故障时无限重试会把后端彻底压垮。正确的做法是设置重试次数、超时时间和退避策略，再配合健康检查，只把流量发给体检合格的后端。

这套逻辑就像大楼里发生火情时，保安会临时封闭某些电梯，引导访客走备用楼梯；等到火情解除，再恢复电梯使用。调度与容错算法的核心，就是“永远不要把鸡蛋放进一个正在漏水的篮子”。

性能优化策略

写字楼高峰期，门口排队的人越来越多。与其让所有人挤在门口，不如优化进门流程。网关常见的性能优化手段包括：连接复用，把多个请求塞进同一条连接里，减少反复握手；内容缓存，把静态响应放在门口附近，访客不用每次都跑到后端房间；动态压缩，对大数据量的响应先压缩再传输。这些策略能显著降低入口延迟和后端压力。

但当流量突然暴增时，还需要“限流控制”。令牌桶算法是常用的一种思路：系统按固定速率向桶里放令牌，每个请求必须取到令牌才能进入。如果桶空了，请求就会被拒绝或排队，避免后端被超额流量冲垮。令牌桶可以表示为：

令牌桶算法非常适合 AI 推理服务：模型接口希望保持稳定吞吐，而不是被瞬间的高并发打乱节奏。门禁放行的速度一旦可控，整个楼内系统就能保持平稳，不至于因为一个高峰把所有房间都挤满。

实践与案例

把前面的知识拼起来，就是一次写字楼入口系统的整体升级。想象一家 AI 公司要发布新版推荐模型，团队不希望一次性切换用户，而是先让 10% 的流量走新模型，观察效果后再逐步扩大。这个场景就是灰度发布。用 Gateway API 可以轻松实现：为新旧两个版本分别定义后端，并通过 HTTPRoute 的权重字段控制流量比例。

灰度发布的核心公式非常直观：

除了灰度发布，生产环境还常用流量镜像：把线上请求复制一份发送给新版本，但不影响真实用户，用于搜集模型效果对比；故障演练则会在演练环境中随机杀掉一些 Pod，观察入口网关和服务网格能否自动切换流量；多集群网关更是 AI 基础设施的常见方案，让一个入口背后连接多个 Kubernetes 集群，实现容灾和弹性伸缩。这就像写字楼全面升级后，门禁、秘书、消防通道和应急预案都演练到位，楼内几千人也能安全高效地运转。

AI 应用场景

Python 演示

import randomfrom collections import Counter BACKENDS = [    {"name": "api-v1", "weight": 5, "healthy": True},    {"name": "api-v2", "weight": 2, "healthy": True},    {"name": "static", "weight": 3, "healthy": True},] def weighted_choice(backends):    total = sum(b["weight"] for b in backends if b["healthy"])    r = random.uniform(0, total)    upto = 0    for b in backends:        if not b["healthy"]:            continue        upto += b["weight"]        if r <= upto:            return b    return backends[0] def route(path):    if path.startswith("/api"):        return [b for b in BACKENDS if b["name"].startswith("api")]    if path.startswith("/static"):        return [b for b in BACKENDS if b["name"] == "static"]    return BACKENDS def simulate(requests):    counter = Counter()    for path in requests:        pool = route(path)        chosen = weighted_choice(pool)        counter[chosen["name"]] += 1    return counter if __name__ == "__main__":    random.seed(42)    paths = ["/api/order" if i % 2 == 0 else "/static/banner" for i in range(1000)]    result = simulate(paths)    for name in result:        print(name, result[name])

1. total = sum(b["weight"] for b in backends if b["healthy"])只对健康后端求权重总和，相当于门禁只把访客带到“正常营业”的房间。
2. r = random.uniform(0, total)生成一个 0 到总权重之间的随机数，相当于走到门口随机抽一个分流结果。
3. upto += b["weight"]逐个累加权重，把总权重切成连续区间。
4. if r <= upto:随机数落在当前区间内，就选中这个后端。
5. pool = route(path)先按路径缩小候选范围，例如 /api 请求只会进入 API 后端。
6. chosen = weighted_choice(pool)在候选池内执行加权随机选择。
7. counter[chosen["name"]] += 1记录每个后端被选中的次数，用于观察最终分流比例。

常见误区

面试题