AWS Serverless架构部署OneHub大模型API网关实战指南

为什么需要LLM Gateway统一管理层

在企业级AI应用开发中，单一LLM供应商往往无法满足多样化的业务需求。当团队同时接入OpenAI、Claude、AWS Bedrock等多家模型服务时，会面临以下工程挑战：

• 凭据管理分散：各供应商的API Key需要集中存储和轮换
• 接口协议差异：不同供应商的请求格式增加业务代码复杂度
• 用量监控困难：跨平台的调用统计和成本核算缺乏统一视图
• 权限控制缺失：难以对不同团队实施细粒度的模型访问控制

开源项目OneHub（基于one-api演进）提供了完善的多租户API分发能力，本文将详解如何在AWS上构建生产级部署架构。

架构设计与核心组件

整体架构特点

本方案采用全托管Serverless服务栈，具备以下架构优势：

• CloudFormation一键部署：基础设施即代码，可重复、可审计
• 零运维负担：ECS Fargate、Aurora Serverless均为全托管服务
• 弹性伸缩：根据CPU/内存指标自动扩缩容，高峰期承载高并发
• 安全纵深防御：源站私有化部署，CloudFront统一入口

Master-Slave节点职责分析

通过源码分析，OneHub的NODE_TYPE环境变量决定了节点行为差异：

• Master节点：执行定时任务、数据库写入操作、系统配置管理
• Slave节点：处理API请求、从数据库同步配置、支持水平扩展

关键部署约束：Master节点必须保持单实例，避免定时任务重复执行；Slave节点可根据负载动态扩展。

ECS集群部署规划

Task Definition配置策略

创建两个独立的Task Definition，通过环境变量区分节点类型：

# Master Task Definition 关键配置
environment:
  - name: NODE_TYPE
    value: master
  - name: SESSION_SECRET
    value: ${SessionSecret}
  - name: SQL_DSN
    value: ${DatabaseConnectionString}

# Slave Task Definition 关键配置
environment:
  - name: NODE_TYPE
    value: slave
  - name: SYNC_FREQUENCY
    value: 60

Service部署配置

针对两种节点类型创建独立的ECS Service：

• Master Service：固定1个Task实例，禁用自动扩展
• Slave Service：启用Application Auto Scaling，建议以CPU利用率70%为扩展阈值

建议开启Availability Zone Rebalancing，确保Task均匀分布在多个可用区，提升服务可用性。

数据库层设计

Aurora Serverless V2选型理由

Aurora Serverless V2 for MySQL是本方案的最佳数据库选择：

• 精细化扩缩容：支持0.5 ACU起步，最小扩展粒度0.5 ACU
• 按需计费：存储按实际使用量收费，无需预置容量
• 原生高可用：自动故障转移，RPO接近零
• 运维简化：内置RDS Data API，可通过Query Editor直接执行SQL

安全配置要点

部署时务必替换以下敏感参数的默认值：

# CloudFormation参数配置
DatabasePassword: [使用强密码，建议32位以上]
SessionSecret: [随机生成的会话密钥]
UserTokenSecret: [用户令牌加密密钥]

流量分发与ALB规则配置

路由策略设计

使用ALB Listener Rules实现流量分离：

• LLM API请求：路由至Slave Target Group
• 管理操作请求：路由至Master Target Group

{
  "Conditions": [
    {
      "Field": "path-pattern",
      "Values": ["/v1/chat/*", "/v1/completions/*", "/v1/embeddings/*"]
    }
  ],
  "Actions": [
    {
      "Type": "forward",
      "TargetGroupArn": "arn:aws:elasticloadbalancing:...:slave-tg"
    }
  ]
}

实践建议：上述路径规则需根据实际接入的LLM供应商API格式进行调整，避免与管理接口路径冲突。

网络安全架构

纵深防御设计

本方案采用CloudFront VPC Origin架构，实现源站零暴露：

• ECS Task：部署于私有子网，通过NAT Gateway访问外网
• Aurora集群：部署于私有子网，仅允许ECS安全组入站
• ALB：部署于私有子网，禁止公网直接访问
• CloudFront：作为唯一公网入口，自带Shield Standard防护

安全收益

此架构无需额外配置即可获得：

• 源站无公有IP，攻击面最小化
• Shield Standard自动抵御L3/L4层DDoS攻击
• 可通过AWS WAF在CloudFront层统一配置防护规则
• 利用全球PoP节点降低API访问延迟

运维与可观测性

日志与监控

• 容器日志：自动发送至CloudWatch Logs，支持Logs Insights查询分析
• 数据库运维：通过RDS Query Editor直连数据库，无需堡垒机
• 容器调试：启用ECS Exec可直接登录运行中的容器排查问题

# 使用ECS Exec连接容器
aws ecs execute-command \
  --cluster onehub-cluster \
  --task arn:aws:ecs:region:account:task/xxx \
  --container onehub \
  --interactive \
  --command "/bin/sh"

成本估算与优化建议

主要成本构成

以默认配置（256 CPU + 512 Memory，约1/4 vCPU）为例：

• ECS Fargate：3个Task实例的计算费用
• Aurora Serverless V2：ACU使用量 + 存储费用
• CloudFront：数据传输费用
• NAT Gateway：固定费用 + 数据处理费用

成本优化策略

• 非生产环境可将Aurora最小ACU设为0.5，实现闲时接近零成本
• 评估是否可使用Fargate Spot运行Slave节点，节省最高70%计算成本
• 配置CloudFront缓存策略，减少源站请求量

部署注意事项

首次部署问题：新AWS账号或从未使用过ECS的账号，首次创建堆栈可能报错提示缺少ECS服务链接角色。解决方法：删除失败的堆栈后重新创建，AWS会自动创建所需的服务链接角色。

Bedrock模型配置：在OneHub管理界面配置AWS Bedrock渠道时，需参考官方文档设置正确的模型映射关系，确保API调用能正确路由到目标模型。