486 lines
13 KiB
Markdown
486 lines
13 KiB
Markdown
# 专业架构深度评审报告
|
||
|
||
> 评审日期：2026-03-18
|
||
> 评审方法：架构评审 + 模式分析 + 行业对标
|
||
> 评审范围：整体架构与技术决策
|
||
|
||
---
|
||
|
||
## 1. 评审团队与方法
|
||
|
||
### 1.1 评审专家
|
||
- **云原生架构师** - 负责微服务架构评审
|
||
- **分布式系统专家** - 负责数据一致性评审
|
||
- **性能工程师** - 负责性能与扩展性评审
|
||
|
||
### 1.2 评审框架
|
||
| 维度 | 评估方法 |
|
||
|------|----------|
|
||
| 架构合理性 | 模式对照 + 反模式检测 |
|
||
| 可扩展性 | 容量规划 + 水平扩展能力 |
|
||
| 可用性 | SLO分析 + 故障模式分析 |
|
||
| 可维护性 | 模块化 + 依赖管理 |
|
||
| 性能 | 基准测试 + 瓶颈分析 |
|
||
|
||
---
|
||
|
||
## 2. 架构整体评估
|
||
|
||
### 2.1 当前架构概述
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────┐
|
||
│ 控制面 (Control Plane) │
|
||
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
||
│ │ 租户管理 │ │ 计费引擎 │ │ 策略引擎 │ │ 管理后台 │ │
|
||
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
|
||
└─────────────────────────────────────────────────────────────────┘
|
||
│
|
||
▼
|
||
┌─────────────────────────────────────────────────────────────────┐
|
||
│ 数据面 (Data Plane) │
|
||
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
||
│ │ Router │ │Provider │ │ 熔断 │ │ 计费 │ │
|
||
│ │ Core │ │ Adapter │ │ 器 │ │ 收集器 │ │
|
||
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
|
||
└─────────────────────────────────────────────────────────────────┘
|
||
│
|
||
▼
|
||
┌─────────────────────────────────────────────────────────────────┐
|
||
│ subapi (外部集成) │
|
||
└─────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 2.2 架构评分
|
||
|
||
| 维度 | 评分 | 说明 |
|
||
|------|------|------|
|
||
| 模块化 | 7/10 | 控制面/数据面分离清晰 |
|
||
| 可扩展性 | 6/10 | 水平扩展能力需验证 |
|
||
| 可用性 | 7/10 | 故障隔离机制需完善 |
|
||
| 性能 | 7/10 | 60ms目标可达 |
|
||
| 可维护性 | 6/10 | subapi耦合需解耦 |
|
||
|
||
**架构综合评分：6.5/10**
|
||
|
||
---
|
||
|
||
## 3. 深度问题分析
|
||
|
||
### 3.1 严重问题（Critical）
|
||
|
||
#### 问题 A-01：Router Core 自研技术风险
|
||
|
||
**发现**：
|
||
规划中 S2 阶段要自研 Router Core 接管 60% 流量，这是一个重大技术决策：
|
||
|
||
**风险分析**：
|
||
```
|
||
自研 Router Core 的挑战：
|
||
|
||
1. 复杂度
|
||
- 需要实现完整的路由决策逻辑
|
||
- 需要实现熔断、降级、重试
|
||
- 需要实现成本优化策略
|
||
|
||
2. 时间
|
||
- S2 只有 16 周（含 buffer）
|
||
- 需要达到 60% 接管率
|
||
- 需要保证稳定性
|
||
|
||
3. 稳定性
|
||
- 初期稳定性可能不如 subapi
|
||
- 需要双轨运行
|
||
- 需要快速回滚能力
|
||
```
|
||
|
||
**行业对标**：
|
||
```
|
||
Litellm: 3年+ 开源社区维护
|
||
OpenRouter: 2年+ 商业化验证
|
||
我们的团队: 初次自研
|
||
```
|
||
|
||
**建议**：
|
||
1. **降低预期**：首年目标调整为 30-40%
|
||
2. **分阶段**：
|
||
- S2-A: 10% 流量（验证稳定性）
|
||
- S2-B: 30% 流量（优化性能）
|
||
- S2-C: 50% 流量（功能完善）
|
||
3. **技术准备**：
|
||
- 提前 2 个月启动 Router Core 原型开发
|
||
- 建立性能基准测试
|
||
- 准备完整回滚方案
|
||
|
||
**风险评级**：🔴 P0
|
||
|
||
---
|
||
|
||
#### 问题 A-02：subapi 耦合风险
|
||
|
||
**发现**：
|
||
当前方案依赖 subapi 作为核心能力，存在供应商锁定风险：
|
||
|
||
**耦合点分析**：
|
||
| 耦合项 | 风险 | 影响 |
|
||
|--------|------|------|
|
||
| API 协议 | 中 | subapi 升级可能破坏兼容 |
|
||
| 错误码映射 | 高 | 需要维护映射表 |
|
||
| Usage 格式 | 中 | 计费可能出错 |
|
||
| 认证机制 | 高 | 安全漏洞无法自行修复 |
|
||
|
||
**建议**：
|
||
1. **接口抽象层**：
|
||
```python
|
||
# 定义抽象接口
|
||
class ProviderAdapter(ABC):
|
||
@abstractmethod
|
||
def chat_completion(self, request: Request) -> Response:
|
||
pass
|
||
|
||
@abstractmethod
|
||
def get_usage(self, response: Response) -> Usage:
|
||
pass
|
||
|
||
@abstractmethod
|
||
def map_error(self, error: Exception) -> ErrorCode:
|
||
pass
|
||
|
||
# subapi 适配器
|
||
class SubapiAdapter(ProviderAdapter):
|
||
def __init__(self, subapi_client):
|
||
self.client = subapi_client
|
||
|
||
# 自研 Router Core 适配器
|
||
class RouterCoreAdapter(ProviderAdapter):
|
||
def __init__(self, router_client):
|
||
self.client = router_client
|
||
```
|
||
|
||
2. **契约测试**：为每个适配器建立契约测试
|
||
3. **双轨运行**：确保随时可以切换
|
||
|
||
**风险评级**：🔴 P0
|
||
|
||
---
|
||
|
||
#### 问题 A-03：数据一致性风险
|
||
|
||
**发现**：
|
||
计费系统涉及资金，需要强一致性，但当前设计可能存在风险：
|
||
|
||
**问题分析**：
|
||
```
|
||
当前设计：
|
||
┌─────────────┐ ┌─────────────┐
|
||
│ 请求处理 │ ──▶ │ 计费收集器 │
|
||
│ (实时) │ │ (异步) │
|
||
└─────────────┘ └─────────────┘
|
||
│
|
||
▼
|
||
┌─────────────┐
|
||
│ Usage表 │
|
||
│ (最终一致) │
|
||
└─────────────┘
|
||
```
|
||
|
||
**风险场景**：
|
||
1. 异步写入失败 → 计费丢失
|
||
2. 进程崩溃 → 计费未落库
|
||
3. 分布式事务未处理 → 数据不一致
|
||
|
||
**建议**：
|
||
1. **同步预扣**：
|
||
```python
|
||
async def handle_request(request: Request):
|
||
# 1. 同步预扣额度
|
||
await billing.reserve(request.user_id, request.estimated_cost)
|
||
|
||
# 2. 处理请求
|
||
response = await router.route(request)
|
||
|
||
# 3. 同步扣减实际额度
|
||
actual_cost = calculate_actual_cost(response)
|
||
await billing.charge(request.user_id, actual_cost)
|
||
```
|
||
|
||
2. **对账机制**：
|
||
- 实时对账：请求级别
|
||
- 定期对账：小时级别
|
||
- 差异追踪：分钟级别告警
|
||
|
||
3. **补偿事务**：
|
||
- 失败重试
|
||
- 异常队列
|
||
- 人工干预
|
||
|
||
**风险评级**：🔴 P0
|
||
|
||
---
|
||
|
||
### 3.2 高风险问题（High）
|
||
|
||
#### 问题 A-04：缺乏容量规划
|
||
|
||
**发现**：
|
||
当前规划未明确容量相关数字：
|
||
|
||
**缺失信息**：
|
||
| 指标 | 当前 | 行业参考 |
|
||
|------|------|----------|
|
||
| 单实例 QPS | 未明确 | 1k-5k |
|
||
| 集群最大实例 | 未明确 | 10-100 |
|
||
| Redis 容量 | 未明确 | 10GB/月 |
|
||
| 数据库连接 | 未明确 | 100-500 |
|
||
|
||
**建议**：
|
||
1. **基线测试**：确定单实例性能基线
|
||
2. **扩展公式**：
|
||
```
|
||
实例数 = 峰值QPS / 单实例QPS * 冗余系数
|
||
```
|
||
3. **容量模型**：
|
||
```python
|
||
def calculate_capacity(peak_qps, p99_latency):
|
||
instances = ceil(peak_qps * p99_latency / 1000)
|
||
return {
|
||
'instances': instances * 2, # 高可用
|
||
'redis_gb': estimate_redis(peak_qps),
|
||
'db_connections': instances * 10
|
||
}
|
||
```
|
||
|
||
**风险评级**：🟡 P1
|
||
|
||
---
|
||
|
||
#### 问题 A-05：故障隔离不完善
|
||
|
||
**发现**：
|
||
当前架构缺乏故障隔离设计：
|
||
|
||
**问题场景**：
|
||
```
|
||
1. 供应商故障
|
||
- OpenAI 故障 → 所有用户受影响
|
||
- 应该有降级到其他供应商的能力
|
||
|
||
2. 租户故障
|
||
- 某个租户耗尽配额 → 影响其他租户
|
||
- 应该有限流和隔离
|
||
|
||
3. 内部服务故障
|
||
- 计费服务故障 → 请求处理受影响
|
||
- 应该有熔断和降级
|
||
```
|
||
|
||
**建议**：
|
||
1. **租户级隔离**：
|
||
- 独立连接池
|
||
- 独立队列
|
||
- 独立限流
|
||
|
||
2. **服务级熔断**：
|
||
- 快速失败
|
||
- 降级策略
|
||
- 恢复重试
|
||
|
||
3. **多供应商路由**：
|
||
- 主供应商 + 备用供应商
|
||
- 自动故障转移
|
||
- 成本感知路由
|
||
|
||
**风险评级**：🟡 P1
|
||
|
||
---
|
||
|
||
#### 问题 A-06：可观测性不足
|
||
|
||
**发现**：
|
||
当前只提到"可观测数据聚合"，但缺乏具体设计：
|
||
|
||
**缺失指标**：
|
||
| 类别 | 指标 | 重要性 |
|
||
|------|------|--------|
|
||
| 业务 | 请求成功率 | P0 |
|
||
| 业务 | 计费准确率 | P0 |
|
||
| 性能 | P99 延迟 | P0 |
|
||
| 性能 | 吞吐量 | P1 |
|
||
| 稳定性 | 错误率 | P0 |
|
||
| 稳定性 | 供应商可用性 | P1 |
|
||
|
||
**建议**：
|
||
1. **指标体系**（SLI）：
|
||
```yaml
|
||
slis:
|
||
- name: request_success_rate
|
||
objective: 99.9%
|
||
method: sum(rate(requests_total{service="router"}[5m])) / sum(rate(requests_total[5m]))
|
||
|
||
- name: billing_accuracy
|
||
objective: 99.99%
|
||
method: 1 - (billing_discrepancies / total_billing_records)
|
||
```
|
||
|
||
2. **SLA 设定**：
|
||
```
|
||
- 可用性: 99.95% (月级)
|
||
- 延迟: P99 < 200ms
|
||
- 准确性: 99.99%
|
||
```
|
||
|
||
3. **告警规则**：
|
||
```
|
||
- 可用性 < 99.9% → P1
|
||
- 可用性 < 99% → P0
|
||
- 延迟 P99 > 500ms → P1
|
||
- 计费差异 > 0.1% → P0
|
||
```
|
||
|
||
**风险评级**：🟡 P1
|
||
|
||
---
|
||
|
||
### 3.3 中等风险问题（Medium）
|
||
|
||
| 问题编号 | 问题 | 建议 | 风险等级 |
|
||
|----------|------|------|----------|
|
||
| A-07 | 技术选型未明确 | 明确Go版本、框架 | 🟢 P2 |
|
||
| A-08 | 部署架构未设计 | 设计多区域部署 | 🟢 P2 |
|
||
| A-09 | 监控告警不具体 | 明确告警阈值 | 🟢 P2 |
|
||
| A-10 | 灾备方案缺失 | 设计数据备份 | 🟢 P2 |
|
||
|
||
---
|
||
|
||
## 4. 技术决策评估
|
||
|
||
### 4.1 控制面 + 数据面分离
|
||
|
||
**评估**：✅ 合理
|
||
```
|
||
优点：
|
||
- 控制面可以独立扩展
|
||
- 数据面可以高性能
|
||
- 故障隔离
|
||
|
||
注意事项：
|
||
- 需要可靠的内网通信
|
||
- 需要协调两个面的部署
|
||
- 增加运维复杂度
|
||
```
|
||
|
||
### 4.2 使用 subapi 作为集成底座
|
||
|
||
**评估**：⚠️ 有风险但可行
|
||
```
|
||
优点：
|
||
- 快速上线
|
||
- 社区验证
|
||
- 功能丰富
|
||
|
||
缺点：
|
||
- 供应商锁定
|
||
- 定制困难
|
||
- 升级风险
|
||
|
||
建议：
|
||
- 建立抽象层
|
||
- 准备自研替代
|
||
- 监控版本变化
|
||
```
|
||
|
||
### 4.3 渐进式接管策略
|
||
|
||
**评估**：✅ 合理
|
||
```
|
||
优点：
|
||
- 降低风险
|
||
- 逐步验证
|
||
- 可回滚
|
||
|
||
注意事项：
|
||
- 双轨运维复杂度
|
||
- 需要精确的流量控制
|
||
- 回滚需要快速
|
||
```
|
||
|
||
---
|
||
|
||
## 5. 扩展性分析
|
||
|
||
### 5.1 水平扩展能力
|
||
|
||
| 组件 | 扩展方式 | |当前状态 |
|
||
|------|----------|---------|
|
||
| API Gateway | 无状态 | ✅ | 需评估 |
|
||
| Router Core | 无状态 | ✅ | 需设计 |
|
||
| Provider Adapter | 有状态 | ⚠️ | 需优化 |
|
||
| Redis | 分片 | ✅ | 需规划 |
|
||
| PostgreSQL | 分片/读写分离 | ✅ | 需规划 |
|
||
|
||
### 5.2 容量规划建议
|
||
|
||
```
|
||
阶段 QPS 实例 Redis DB
|
||
------------------------------------------------
|
||
S0 (MVP) 100 2 2GB 10GB
|
||
S1 (上线) 500 4 10GB 50GB
|
||
S2 (增长) 2000 8-10 50GB 200GB
|
||
S3 (规模) 10000 20+ 200GB 1TB
|
||
```
|
||
|
||
---
|
||
|
||
## 6. 总结
|
||
|
||
### 6.1 架构评分
|
||
|
||
| 维度 | 评分 | 说明 |
|
||
|------|------|------|
|
||
| 模块化 | 7/10 | 控制面/数据面分离清晰 |
|
||
| 可扩展性 | 6/10 | 水平扩展能力需验证 |
|
||
| 可用性 | 7/10 | 故障隔离机制需完善 |
|
||
| 性能 | 7/10 | 60ms目标可达 |
|
||
| 可维护性 | 6/10 | subapi耦合需解耦 |
|
||
| 安全性 | 6/10 | 详见安全评审 |
|
||
|
||
**架构综合评分：6.5/10**
|
||
|
||
### 6.2 关键行动项
|
||
|
||
| 优先级 | 行动项 |
|
||
|--------|--------|
|
||
| 🔴 P0 | Router Core 降低首年预期至 30-40% |
|
||
| 🔴 P0 | 建立 Provider Adapter 抽象层 |
|
||
| 🔴 P0 | 设计同步预扣 + 异步确认的计费流程 |
|
||
| 🟡 P1 | 完成容量规划（单实例基线测试） |
|
||
| 🟡 P1 | 设计完整的故障隔离机制 |
|
||
| 🟡 P1 | 建立完整的 SLI/SLO 体系 |
|
||
| 🟢 P2 | 明确技术选型（Go版本、框架） |
|
||
| 🟢 P2 | 设计多区域部署架构 |
|
||
|
||
---
|
||
|
||
## 7. 附录：行业对标
|
||
|
||
### 7.1 竞品架构对比
|
||
|
||
| 产品 | 架构 | 日处理请求 | 特点 |
|
||
|------|------|------------|------|
|
||
| Litellm | 微服务 | 10亿+/月 | 开源、社区活跃 |
|
||
| OpenRouter | 分布式 | 10亿+/月 | 多供应商聚合 |
|
||
| 我们的方案 | 双平面 | 目标1亿+/月 | 控制面自研 |
|
||
|
||
### 7.2 技术指标参考
|
||
|
||
| 指标 | 行业水平 | 我们的目标 |
|
||
|------|----------|------------|
|
||
| 可用性 | 99.9-99.99% | 99.95% |
|
||
| P99延迟 | 50-200ms | <200ms |
|
||
| 计费准确性 | 99.99% | 99.99% |
|
||
|
||
---
|
||
|
||
**评审完成时间**：2026-03-18
|
||
**下次评审**：架构设计细化后
|