想象你是云端国际机场(AWS云)的运营总监。清晨六点,航站楼(API Gateway)刚刚开启,第一批乘客(API请求)已经涌入——有赶着去AI识别柜台(Lambda)办业务的,有托运大批量数据去计算中心(EC2)的,还有只是来窗口取回寄存行李(缓存)的。你的任务:让每一位乘客都快速到达正确的登机口,不让任何一条通道被挤爆,还要让整个机场的运营成本一目了然。 这座航站楼就是你今天要学习的 API Gateway——AWS 云上所有 AI 服务的统一入口。它负责接住四面八方飞来的请求,根据“登机牌”(URL路径)把请求送到对应的后端服务;通过“安检闸口”(限流)控制每秒涌入的请求量;用“行李寄存处”(缓存)让重复查询不用再跑到后端费时费力;还能把请求轻巧地甩给随叫随到的“摆渡小巴”(Lambda函数),或是稳重的大型客机(EC2服务器)。 读完这篇文章,你会像机场运营总监一样,亲手设计出一座高效、稳健、能算清每一笔账的 API 流量编排中心。

岗位关联

精通API Gateway流量编排,是云平台工程师构建AI服务门户的核心技能。掌握请求路由、限流缓存与Lambda/EC2集成,你就能为AI模型搭建高可用、可计量的云端出入口,是AI落地到企业的“最后一公里”基础设施。

目录
  1. 可视化演示
  2. 网关核心角色——云端唯一的航站楼
  3. 请求路由设计——登机牌上的目的地
  4. 限流与配额——安检闸口的智慧
  5. 缓存策略——行李寄存处的妙用
  6. Lambda集成——随叫随到的摆渡小巴
  7. EC2服务集成——重型客机的专属廊桥
  8. AI网关实战——把机场变成智慧机场
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示AWS API Gateway请求路由分发、令牌桶限流与HTTP 429机制及响应缓存与Lambda无服务器集成,切换模式理解AI服务网关核心流量治理能力。

本节配有交互动效(进入视口后自动加载,约 3KB)。

API Gateway请求路由与流量分发 路径路由将不同API路径映射到不同后端AI服务:/v1/chat→对话模型,/v1/embed→嵌入模型,/v1/image→图像生成 API Gateway作为统一流量入口,承载认证授权、请求转换、响应缓存等横切关注点 Client → API GW → {/v1/chat→LLM, /v1/embed→EMB, /v1/image→IMG} API Gateway是AI服务架构中统一的流量入口与控制平面

网关核心角色——云端唯一的航站楼

国际机场不会让每架飞机随意停靠跑道,乘客得先在航站楼统一办理手续,再分流登机。AWS 的 AI 服务生态也是这样:当你的模型端点多达几十个,客户端直接挨个调用会让管理彻底失控。API Gateway 就是那座航站楼——客户只认一个统一域名,剩下的调度、鉴权、限流全由它包办。

API Gateway 是 AWS 托管的 API 网关服务,本质上是“前置门卫 + 总机”。它站在所有后端服务前面,扮演四个关键角色:统一入口(所有请求走同一个域名)、流量闸门(控制进入系统的速率)、协议转换(把 HTTP 请求转成 Lambda 能理解的事件格式)、安全防护(API 密钥、IAM 鉴权)。有了它,客户端不需要知道后端藏着多少台机器。

为什么不能直接上负载均衡器?因为 ALB 偏向纯转发,而 API Gateway 更“懂业务”:它知道 /predict 要去找 Lambda、知道哪些客户有每日调用定额、还能对每个 API 生成调用指标送进 CloudWatch。它像一个航站楼的中央调度系统,不只是“把乘客送出去”,而是“知道送出去之后发生了什么”。

所以当你看到 CloudWatch 里网关请求堆积,先别急着加机器——用 Little 定律想想:是涌入的乘客变多了(λ 上升),还是安检太慢了(W 增加)?对症下药才能让航站楼恢复通畅。

L=λ×W\displaystyle L = \lambda \times W
这是排队论中的 Little 定律:系统中滞留的请求数,等于请求到达率乘以平均处理时长。航站楼如果涌入太多乘客、或者安检太慢,大厅就会人满为患。
  1. L(滞留请求数)系统中同时存在的请求数量,就像机场里正在排队等候的乘客数。
    LL
  2. λ(请求到达率)平均每秒钟新到达网关的请求数,相当于每分钟涌入航站楼的乘客量。
    λ\lambda
  3. W(平均处理时长)每个请求从进入网关到完成转发所花的时间,即每位乘客的平均安检加登机耗时。
    WW
  4. 三者关系滞留人数等于到达率乘以处理时长,人太多或处理太慢都会造成拥堵。
    L=λ×WL = \lambda \times W

请求路由设计——登机牌上的目的地

地勤人员扫一眼登机牌就知道该送你去哪个登机口。API Gateway 的路由引擎也有一双“火眼金睛”,它从请求的 URL 路径和 HTTP 方法中读出目的地,然后把请求送到对应的后端服务。这就是流量编排的第一步:把乘客分对航班。

路由规则就是网关的“航班时刻表”。常见配置包括:路径映射,比如 /predict 开头的请求走 Lambda 组、/batch 走 EC2 组;方法匹配,GET 通常用于查询(可以走缓存),POST 用于创建(必须直达后端);参数转换,把请求体里的 JSON 字段改写成后端需要的结构;后端连接,网关通过 HTTP 代理、VPC Link 或 Lambda 集成这三种方式把请求真正送出去。

当同一个路径后面挂着多个后端实例,还需要决定“这班飞机坐哪架”?如果后端性能不均,可以用加权轮询:权重大的后端多接请求。权重由你根据机器规格、网络带宽或压测结果设定。

就像航司根据机型大小分配登机口,你用权重告诉网关:那台高配 GPU 机器能力强、权重设 8,普通机器就设 2——强机多接活,弱机少接活,整个机队才不会被一台慢机器拖住。

Pi=wi∑jwj\displaystyle P_i = \frac{w_i}{\sum_{j} w_j}
加权轮询公式:请求被路由到第 i 个后端的概率,等于该后端权重占总权重的比例。
  1. w_i(单个权重)第 i 个后端服务被赋予的权重,代表它的处理能力,权重越大能接的请求越多。
    wiw_i
  2. Σw_j(权重总和)所有可用后端权重之和,相当于所有登机口的总吞吐容量。
    ∑jwj\sum_{j} w_j
  3. P_i(选中概率)每个新请求被路由到第 i 个后端的概率,等于该后端权重占总权重的比值。
    Pi=wi∑jwjP_i = \frac{w_i}{\sum_{j} w_j}

限流与配额——安检闸口的智慧

机场最怕什么?瞬间涌入两千名乘客,安检口排队排到大门外。机场的做法是“分批放行”——用闸口控制瞬时通过量。API Gateway 的限流就是这道安检闸口:它不拒绝所有人,只是让流量更均匀地进入系统。

AWS 限流的核心算法是令牌桶。想象一个桶:每秒往桶里丢 r 个令牌,请求来了必须拿一个令牌才能通过;桶满了(容量 C)令牌不再增加。这样一来,桶里积攒的令牌允许短时爆发,但长期平均速率被牢牢限制在 r 以内。配置时你要设两个参数:速率(每秒请求数上限)和突发量(桶容量)。

AWS 的 Usage Plan 把限流落到“客户”粒度:每个 API Key 对应一个使用计划,计划里规定速率(RPS)和每日配额(requests/day)。超过配额的请求直接返回 HTTP 429(Too Many Requests),相当于安检口举牌“今日放行名额已用完”。

安检口不会拒绝所有乘客,只是让排队更均匀。同样,429 不是坏事——它保护的是后端的“大动脉”,防止一台模型服务被一秒一万请求打崩。记住:限流永远是为了保护系统,不是为了刁难用户。

T(t)=min⁡(C, T0+r×Δt)\displaystyle T(t) = \min(C,\ T_0 + r \times \Delta t)
令牌桶公式:当前令牌数等于原有令牌加上按速率补充的数量,但最多不超过桶容量 C。
  1. T₀(当前令牌数)桶里此刻剩余的令牌数量,相当于安检口剩余的可放行名额。
    T0T_0
  2. r(补充速率)每秒新投入桶中的令牌数,即闸口每秒钟恢复的放行名额。
    rr
  3. Δt(时间间隔)距上次结算令牌数经过的秒数,这期间桶会按速率持续补充。
    Δt\Delta t
  4. min(C, ·)(容量封顶)令牌最多积累到桶容量 C,超出部分直接丢弃,保证突发量有上限。
    T(t)=min⁡(C, T0+r×Δt)T(t) = \min(C,\ T_0 + r \times \Delta t)

缓存策略——行李寄存处的妙用

经常出差的人喜欢办一张“行李寄存卡”:上次查过的航班信息不用再去柜台问,窗口一刷就出来。API Gateway 的缓存就是这样一个信息窗口——它把后端算过的结果“寄存”在网关层,相同请求再来直接取件,不用再跑到后端跑一趟。

开启缓存后,网关发现相同请求(相同 URL 加参数)在 TTL 内再次到达,就直接从内存返回缓存结果。这对 AI 查询类 API 尤其有用:同一个推荐模型的热门结果,一小时内大概率相同,没必要每次重新推理。缓存设计有三件关键事:缓存键(默认按 URL 拼接参数生成,也可以自定义成“业务 ID + 模型版本”)、TTL(缓存数据存活时间,AI 预测结果通常设 60~300 秒)、一致性(训练数据变更时主动失效缓存,别让用户看到旧结果)。

衡量缓存好坏的唯一标准是命中率——命中的请求不需要穿透到后端,命中率越高,模型服务的压力越小。

命中率是“行李寄存处的取件成功率”。但注意:TTL 太长就像行李放久会发霉——数据陈旧会让用户投诉“AI 结果不对”。你要在速度和新鲜度之间找平衡,而不是盲目追求 100% 命中率。

H=hitshits+misses\displaystyle H = \frac{hits}{hits + misses}
缓存命中率公式:命中次数占全部请求次数的比例。命中率 70% 意味着七成请求不用惊动后端。
  1. hits(命中数)请求在网关缓存中直接得到结果的次数,等于行李寄存直接取件的次数。
    hitshits
  2. misses(未命中数)缓存里没有结果、必须转发到后端的次数,等于去后端取件的次数。
    missesmisses
  3. H(命中率)命中的请求占全部请求的比例,命中率越高,后端承受的压力越小。
    H=hitshits+missesH = \frac{hits}{hits + misses}

Lambda集成——随叫随到的摆渡小巴

机场里除了大型客机,还有随叫随到的摆渡小巴:没有固定班次,接到单就发车,没人叫就熄火休息。Lambda 函数就是云端 AI 服务的摆渡小巴——它是“函数即服务”(FaaS),你只需上传代码,运行时长按毫秒计费,没有请求时完全零成本。

API Gateway 与 Lambda 集成有两种方式:非代理集成是网关先按映射模板把 HTTP 请求转成 Lambda 事件,网关可以做参数转换;代理集成(Proxy)则是网关把整个原始请求原样交给 Lambda,由函数自己解析,更灵活也更常用。调用模式上,同步调用适合在线推理(用户等着要结果),异步调用适合离线批处理(提交任务就返回,后台慢慢算)。

Lambda 最大的痛点之一是冷启动:函数闲置一段时间后,下次调用需要重新加载运行环境,产生几百毫秒到数秒的额外延迟。缓解手段包括启用 Provisioned Concurrency 预热实例、精简依赖包体积、选择冷启动较快的运行时。

明白这个公式,你就能解释“为什么我的 AI 接口有时快有时慢”——闲置后的第一个请求要付冷启动成本,后续请求复用已暖的实例就飞快。对延迟敏感的场景,用 Provisioned Concurrency 把“小巴”提前停在门口,随叫随走。

Ttotal=Tcold+Texec\displaystyle T_{total} = T_{cold} + T_{exec}
冷启动公式:用户感知的总延迟 = 冷启动时间 + 函数执行时间。闲置后的第一个请求往往最慢。
  1. T_cold(冷启动时间)函数从闲置状态重建运行环境所花的初始化时间,好比小巴点火、司机就位。
    TcoldT_{cold}
  2. T_exec(执行时间)函数真正执行业务逻辑的时间,相当于小巴从站台开到目的地的时长。
    TexecT_{exec}
  3. T_total(总延迟)用户感知的总响应时长等于冷启动加执行时间,理解它才能对症优化。
    Ttotal=Tcold+TexecT_{total} = T_{cold} + T_{exec}

EC2服务集成——重型客机的专属廊桥

机场里不是所有航班都靠小巴。重型货机需要专属停机坪和廊桥,EC2 服务器就像机场里的大型客机,负责承载 GPU 训练、大数据处理、长驻服务等重型任务。要让 API Gateway 和 EC2 通信,得修一条“专属廊桥”。

EC2 通常部署在私有 VPC 网络中,公网不能直接访问。打通网络需要几件套组合:VPC Link(基于 PrivateLink 技术,让网关请求跨过公网直连 VPC 内部服务);负载均衡(网关先把请求转发到 ALB/NLB,再由负载均衡器分发到多台 EC2);健康检查(负载均衡器定期探测 EC2 存活状态,失活实例自动摘除);安全组配置(只放行来自网关和负载均衡器的流量,其余全部拒绝)。

这样设计的收益很明显:EC2 横向扩展时,网关配置完全不用改;某台实例挂了,请求自动绕开;对外暴露的只有网关域名,内部拓扑完全隐藏。整座机场看起来只是“一个登机口”,背后却是整支机队在调度。

当健康检查发现一架“客机”引擎故障(响应超时或 5xx 增多),调度系统会把它从机队中摘除,其余客机继续分担航线,乘客毫无感知——这就是架构的韧性。

Tavg=1n∑i=1nTi\displaystyle T_{avg} = \frac{1}{n}\sum_{i=1}^{n} T_i
平均响应时间公式:所有实例响应时间的算术平均,反映整个 EC2 集群的整体表现。
  1. T_i(单台响应时间)第 i 台 EC2 实例处理一个请求所花的响应时间,对应每架客机的准点率。
    TiT_i
  2. n(实例数量)参与服务的 EC2 实例总数,对应机队中在飞的客机数量。
    nn
  3. T_avg(平均响应时间)全部实例的平均响应时间,用来监测整个 EC2 集群的健康水平。
    Tavg=1n∑i=1nTiT_{avg} = \frac{1}{n}\sum_{i=1}^{n} T_i

AI网关实战——把机场变成智慧机场

现在机场引进了 AI 服务柜台:图像识别、语音翻译、文本生成……每个柜台背后是不同的模型。智慧机场的核心,是用一座统一航站楼把所有 AI 能力包起来:一个 API 地址对外,内部自动调度模型、控制 Token 消耗、核算每笔成本。

实战中你需要落实四件事:模型端点管理,把多个模型(视觉、对话、语音)注册为网关后端,统一暴露 /v1/vision、/v1/chat 等路径;Token 管控,限制每次调用的输入输出 Token 上限,防止单个用户“刷爆”模型;多模型路由,根据业务 ID 或请求体特征把流量路由到不同规格的模型——轻量模型省钱、重型模型保质量;成本监控,网关把每次调用的模型名、Token 数、延迟全部写进 CloudWatch,按天、按客户端汇总账单。

这套架构让 AI 服务像水电一样“即开即用”:前端团队只对接网关文档,不关心后端是 Lambda 还是 EC2;算法团队可以悄悄换模型,无需通知任何人;财务拿到的账单精确到“哪个客户用了多少 Token”。

就像机场每个柜台背后都有一笔清楚账,AI 网关让你对每一分钱去向都了如指掌。这不仅是技术架构,更是商业模式——没有计量就没有账单,没有账单,AI 服务就无法规模化地卖给客户。

Ctotal=Nin×Pin+Nout×Pout\displaystyle C_{total} = N_{in} \times P_{in} + N_{out} \times P_{out}
Token 成本公式:一次 AI 调用的总成本 = 输入 Token 数 × 输入单价 + 输出 Token 数 × 输出单价。
  1. N_in 与 N_out(Token 数)一次调用中输入和输出文本折算的 Token 数量,Token 就是模型计费用的“字数”。
    Nin, NoutN_{in},\ N_{out}
  2. P_in 与 P_out(单价)输入和输出各自的单价,不同模型价格不同,通常输出比输入贵。
    Pin, PoutP_{in},\ P_{out}
  3. C_total(总成本)输入费用加上输出费用就是这一次调用的成本,网关逐次记录并汇总成账单。
    Ctotal=Nin×Pin+Nout×PoutC_{total} = N_{in} \times P_{in} + N_{out} \times P_{out}

AI 应用场景

AI客服机器人网关

阶段:模型服务部署与调度

解决的问题:企业同时有意图识别、语音转写、文本生成三个 AI 模型,直接暴露三个 API 会导致客户端混乱、鉴权重复、限流缺失。用 API Gateway 统一暴露一个域名,通过路径路由到不同模型,按租户限流,并缓存高频意图识别结果。

具体案例:某银行要把 AI 客服接入微信小程序。网关注册了 /intent → Lambda 意图识别、/asr → Lambda 语音转写、/chat → EC2 上的对话模型。每个客户 API Key 配 300 QPS 限流、每日 2 万次配额,意图识别结果缓存 60 秒。上线后重复问题响应从 200ms 降到 30ms,后端压力下降 45%。

多租户大模型API服务

阶段:成本控制与计量计费

解决的问题:大模型 API 服务面对多个客户,必须清楚每个租户用了多少资源、花了多少钱。网关记录每次调用的模型名、输入输出 Token 数,按配额限制每位客户的使用量,超限自动熔断并告警。

具体案例:一家 SaaS 公司用 API Gateway 同时服务 50 家中型企业,网关按客户 ID 限制每天 100 万 Token 用量,超限返回 429 并在管理面板告警;每周自动按 Token 使用量生成账单分摊到各客户,运营成本从“拍脑袋”变成“按账本”。

Python 演示

python86 行
import timeimport random  class TokenBucket:    """令牌桶限流器:每秒补充 rate 个令牌,最多积累 capacity 个"""     def __init__(self, capacity, rate):        self.capacity = capacity        self.rate = rate        self.tokens = capacity        self.last = time.time()     def allow(self):        now = time.time()        self.tokens = min(self.capacity, self.tokens + (now - self.last) * self.rate)        self.last = now        if self.tokens >= 1:            self.tokens -= 1            return True        return False  class Router:    """请求路由器:根据 URL 路径映射到不同后端服务"""     def __init__(self):        self.backends = {            'lambda': 'AI推理服务(Lambda)',            'ec2': '批量计算服务(EC2)',            'cache': '缓存服务'        }        self.route_count = {'lambda': 0, 'ec2': 0, 'cache': 0}     def route(self, path):        if '/predict' in path:            return 'lambda'        if '/batch' in path:            return 'ec2'        return 'cache'  class ApiGateway:    """API 网关编排器:限流 + 路由 + 缓存一体化"""     def __init__(self, capacity=3, rate=1):        self.bucket = TokenBucket(capacity, rate)        self.router = Router()        self.cache = {}        self.hit = 0        self.miss = 0     def handle(self, path, payload=None):        if not self.bucket.allow():            return '429 请求被限流拒绝'        target = self.router.route(path)        if target == 'cache':            key = str(payload) + '|' + path            if key in self.cache:                self.hit += 1                return '200 缓存命中: ' + self.cache[key]            result = '结果-' + path.split('?')[0]            self.cache[key] = result            self.miss += 1            return '200 缓存写入: ' + result        self.router.route_count[target] += 1        return '200 转发到 ' + self.router.backends[target]  def main():    gateway = ApiGateway(capacity=3, rate=1)    paths = [        '/predict?q=cat', '/query?q=dog', '/batch?ids=1,2',        '/predict?q=cat', '/query?q=dog', '/batch?ids=3,4',        '/predict?q=cat', '/query?q=dog', '/batch?ids=5,6',        '/predict?q=cat', '/query?q=dog', '/batch?ids=7,8',    ]    for path in paths:        print(gateway.handle(path))        time.sleep(0.3)    print('路由统计:', gateway.router.route_count)    print('缓存命中:', gateway.hit, ' 未命中:', gateway.miss)  if __name__ == '__main__':    main()
目的:用 120 行 Python 模拟 API Gateway 的三大核心能力——令牌桶限流、路径路由、结果缓存,让你直观看到同一个请求如何被“航站楼”处理。
  1. class TokenBucket:定义令牌桶限流器,模拟安检闸口的放行名额池。
  2. self.tokens = min(self.capacity, self.tokens + (now - self.last) * self.rate)按时间流逝补充令牌,但不超过桶容量。
  3. def route(self, path):路由引擎根据路径给请求“分登机口”。
  4. target = self.router.route(path)网关第一步:确定这个请求要去哪个后端。
  5. if target == 'cache':识别出查询类请求,先去“行李寄存处”看看有没有现成结果。
  6. if key in self.cache:缓存命中,直接取结果,不再穿透到后端。
  7. self.router.route_count[target] += 1记录每个后端收到的请求数,方便对账。
  8. gateway = ApiGateway(capacity=3, rate=1)构建一个容量 3、每秒补 1 个令牌的网关。
  9. print(gateway.handle(path))模拟客户端发请求,观察限流、路由、缓存三种行为。

常见误区

误区后端有多个 EC2,我用 ALB 就够了,为什么还要单独的 API Gateway?感觉功能重复啊。

正解ALB 是“流量搬运工”,侧重四层/七层转发;API Gateway 是“业务调度中心”,懂 URL 路径、能把 HTTP 转成 Lambda 事件、能做 API 级限流和缓存、能按 API Key 计费。生产环境往往两者结合:Gateway → ALB → EC2,各司其职。

为何常见:两者都能分发请求,表面能力重叠,初学者容易把它们当成同类产品。

误区把限流上限调到 10000 QPS,总不会误杀正常用户了吧?反正数字大点更安全。

正解限流是为了保护后端。若后端 Lambda 并发上限只有 1000,网关放进来 10000 个请求只会瞬间雪崩。正确做法是限流值 = 后端压测得出的最大安全吞吐,再留 20% 余量。

为何常见:误以为限流是“限制用户”而非“保护系统”,把限流与体验牺牲画上等号。

误区TTL 设成 24 小时,命中率冲到 90%,感觉缓存优化特别成功。

正解AI 模型的结果会随数据变化,24 小时前的旧数据可能早已过时。要结合业务容忍度:非实时榜单缓存 1 小时没问题,实时推荐场景 TTL 超过 5 分钟用户就会察觉“推荐怎么还是上周的”。

为何常见:只盯着命中率这一指标,忽略了数据新鲜度这个更重要的业务维度。

误区多一跳就多一层延迟,让客户端直接调 Lambda 不是更快吗?干脆不要网关。

正解网关处理延迟通常只有几毫秒,与 AI 推理的上百毫秒到秒级相比可忽略。它带来的统一鉴权、限流、监控、缓存收益远大于那点开销,而且 AWS 还提供 CloudFront+DDoS 防护等加速能力。

为何常见:用“中间层越少越快”的朴素直觉套分布式系统,忽略了网关在治理上的杠杆价值。

误区既然用了 Serverless,就不该再碰 EC2,否则就是架构倒退。

正解最佳实践是混合编排——在线推理用 Lambda(弹性好、按量付费),需要 GPU 或长驻任务用 EC2(可控性强、GPU 独享)。API Gateway 按路径把流量编到最合适的一侧,这才是流量编排的意义。

为何常见:把 Serverless 当成银弹,忽视了 GPU 计算、长时运行等场景下的局限。

面试题

Q1. API Gateway在云架构中最重要的角色是?

单选题 · easy

  • A.连接后端与客户端的唯一门户← 正确答案
  • B.替代数据库缓存查询结果
  • C.代替EC2运行业务代码
  • D.替代DNS完成域名解析

答案:A。网关是统一门户,负责把请求路由、限流、鉴权后转发给后端,相当于航站楼。B 是缓存服务的职责,C 是计算服务的职责,D 是 DNS 的职责。

Q2. API Gateway根据什么信息决定请求转发到哪个后端?

单选题 · easy

  • A.请求的路径与HTTP方法← 正确答案
  • B.云账户的余额大小
  • C.EC2实例的CPU品牌
  • D.客户端操作系统的版本

答案:A。路由引擎读“登机牌”——URL 路径(/predict 还是 /batch)和 HTTP 方法决定去哪个后端。余额、CPU 品牌、客户端系统与路由无关。

Q3. 令牌桶中桶的容量C代表什么含义?

单选题 · easy

  • A.允许的最大突发请求数← 正确答案
  • B.每秒新增的令牌数量
  • C.网关允许的总请求上限
  • D.后端服务器的总数量

答案:A。桶容量决定瞬间爆发能消耗多少积攒的令牌,对应突发上限。B 是补充速率 r,C 是总量配额,D 与令牌桶无关。

Q4. 提高缓存命中率最直接的手段是?

单选题 · mid

  • A.延长缓存TTL有效时间← 正确答案
  • B.删除网关中的缓存键
  • C.增加后端EC2的数量
  • D.关闭API请求的限流

答案:A。TTL 越长,相同请求越容易在缓存生命周期内命中,但要警惕数据陈旧。删缓存键会降低命中,加 EC2 和关限流与命中率没有直接关系。

Q5. Lambda冷启动对用户的主要影响是?

单选题 · mid

  • A.首次调用响应时延明显偏高← 正确答案
  • B.函数代码编译出错概率增大
  • C.每次调用都会产生额外费用
  • D.函数实例被意外强制回收

答案:A。闲置函数重新初始化需要时间,所以冷启动请求的延迟显著高于热请求,就像小巴要现点火。冷启动不会导致编译错误或额外费用,实例回收是正常伸缩行为。

Q6. API Gateway在哪一层对请求做流量控制?

单选题 · mid

  • A.应用层按API业务规则限流← 正确答案
  • B.网络层按IP地址包过滤
  • C.传输层按端口号转发
  • D.物理层按网线信号控制

答案:A。API Gateway 是应用层网关,按 API 路径、Key、使用计划做限流;网络层和传输层的控制是安全组/NACL/LB 的活,物理层更是无关。

Q7. 权重为8的后端在加权轮询中收到请求的比例是?

单选题 · hard

  • A.8除以所有后端权重之和← 正确答案
  • B.8乘以每秒请求总数的积
  • C.8除以后端实例的个数
  • D.8减去其他后端的权重

答案:A。加权轮询的选中概率 = 自身权重 ÷ 全部权重之和(P = w_i / Σw_j)。B、C、D 都是对权重语义的错误推导。

Q8. API Gateway实现流量编排的常用能力有哪些?

多选题 · mid

  • A.按照请求路径进行路由← 正确答案
  • B.对API实现限流配额← 正确答案
  • C.对响应结果做缓存← 正确答案
  • D.编写业务核心逻辑

答案:ABC。路由、限流、缓存正是网关流量编排的“三板斧”。业务核心逻辑应写在 Lambda 或 EC2 上,网关只做转发与治理,不写业务代码。

Q9. 构建多租户AI网关需控制单客户成本,有效手段有哪些?

多选题 · hard

  • A.按API Key分配每日配额← 正确答案
  • B.限制模型输入输出Token← 正确答案
  • C.记录调用日志分摊账单← 正确答案
  • D.删除网关的限流规则

答案:ABC。配额管调用量,Token 管控管单次用量,日志账单让成本透明可分摊,三者并用以控制成本。D 相当于拆掉水表,会让成本彻底失控。

Q10. 将API Gateway接入VPC内EC2集群,需要哪些配置配合?

多选题 · hard

  • A.创建VPC Link连接通道← 正确答案
  • B.配置负载均衡健康检查← 正确答案
  • C.安全组放行网关流量← 正确答案
  • D.修改EC2实例的镜像

答案:ABC。VPC Link 打通私有网络、负载均衡分发流量、安全组放行网关来源流量,这是标准三板斧。修改镜像与控制网络路径无关,属于实例生命周期管理。