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 Permalink 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 Permalink 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 Permalink Blame History