niuniu/lijiaoqiao

Fork 0

Files

Your Name 0e5ecd930e chore: initial public snapshot for github upload

2026-03-26 20:06:14 +08:00

13 KiB

Raw Blame History

专业架构深度评审报告

评审日期：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年+ 商业化验证
我们的团队: 初次自研

建议：

降低预期：首年目标调整为 30-40%
分阶段：
- S2-A: 10% 流量（验证稳定性）
- S2-B: 30% 流量（优化性能）
- S2-C: 50% 流量（功能完善）
技术准备：
- 提前 2 个月启动 Router Core 原型开发
- 建立性能基准测试
- 准备完整回滚方案

风险评级：🔴 P0

问题 A-02：subapi 耦合风险

发现：当前方案依赖 subapi 作为核心能力，存在供应商锁定风险：

耦合点分析：

耦合项	风险	影响
API 协议	中	subapi 升级可能破坏兼容
错误码映射	高	需要维护映射表
Usage 格式	中	计费可能出错
认证机制	高	安全漏洞无法自行修复

建议：

接口抽象层：

# 定义抽象接口
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

契约测试：为每个适配器建立契约测试
双轨运行：确保随时可以切换

风险评级：🔴 P0

问题 A-03：数据一致性风险

发现：计费系统涉及资金，需要强一致性，但当前设计可能存在风险：

问题分析：

当前设计：
┌─────────────┐     ┌─────────────┐
│ 请求处理    │ ──▶ │ 计费收集器  │
│ (实时)      │     │ (异步)      │
└─────────────┘     └─────────────┘
                          │
                          ▼
                   ┌─────────────┐
                   │ Usage表    │
                   │ (最终一致)  │
                   └─────────────┘

风险场景：

异步写入失败 → 计费丢失
进程崩溃 → 计费未落库
分布式事务未处理 → 数据不一致

建议：

同步预扣：

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)

对账机制：
- 实时对账：请求级别
- 定期对账：小时级别
- 差异追踪：分钟级别告警
补偿事务：
- 失败重试
- 异常队列
- 人工干预

风险评级：🔴 P0

3.2 高风险问题（High）

问题 A-04：缺乏容量规划

发现：当前规划未明确容量相关数字：

缺失信息：

指标	当前	行业参考
单实例 QPS	未明确	1k-5k
集群最大实例	未明确	10-100
Redis 容量	未明确	10GB/月
数据库连接	未明确	100-500

建议：

基线测试：确定单实例性能基线

扩展公式：

实例数 = 峰值QPS / 单实例QPS * 冗余系数

容量模型：

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. 内部服务故障
   - 计费服务故障 → 请求处理受影响
   - 应该有熔断和降级

建议：

租户级隔离：
- 独立连接池
- 独立队列
- 独立限流
服务级熔断：
- 快速失败
- 降级策略
- 恢复重试
多供应商路由：
- 主供应商 + 备用供应商
- 自动故障转移
- 成本感知路由

风险评级：🟡 P1

问题 A-06：可观测性不足

发现：当前只提到"可观测数据聚合"，但缺乏具体设计：

缺失指标：

类别	指标	重要性
业务	请求成功率	P0
业务	计费准确率	P0
性能	P99 延迟	P0
性能	吞吐量	P1
稳定性	错误率	P0
稳定性	供应商可用性	P1

建议：

指标体系（SLI）：

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)

SLA 设定：

- 可用性: 99.95% (月级)
- 延迟: P99 < 200ms
- 准确性: 99.99%

告警规则：

- 可用性 < 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 下次评审：架构设计细化后

13 KiB Raw Blame History Unescape Escape

专业架构深度评审报告

1. 评审团队与方法

1.1 评审专家

1.2 评审框架

2. 架构整体评估

2.1 当前架构概述

2.2 架构评分

3. 深度问题分析

3.1 严重问题（Critical）

问题 A-01：Router Core 自研技术风险

问题 A-02：subapi 耦合风险

问题 A-03：数据一致性风险

3.2 高风险问题（High）

问题 A-04：缺乏容量规划

问题 A-05：故障隔离不完善

问题 A-06：可观测性不足

3.3 中等风险问题（Medium）

4. 技术决策评估

4.1 控制面 + 数据面分离

4.2 使用 subapi 作为集成底座

4.3 渐进式接管策略

5. 扩展性分析

5.1 水平扩展能力

5.2 容量规划建议

6. 总结

6.1 架构评分

6.2 关键行动项

7. 附录：行业对标

7.1 竞品架构对比

7.2 技术指标参考

13 KiB

Raw Blame History