# 优化技术架构设计（最小可运营栈 + 触发式扩容）

- 版本：v2.0
- 日期：2026-03-18
- 目标：降低 S0/S1 运维复杂度，同时保证 S2 替换目标可达。

---

## 1. 架构优化原则

1. 先跑通核心链路，再引入复杂中间件。
2. 每增加一个基础设施组件，必须有可量化触发条件。
3. 控制面集中、数据面可灰度、回滚可自动化。
4. 与主栈强一致：Go + PostgreSQL + Redis。

---

## 2. 分阶段目标架构

### 2.0 极简模式（S0/S1优先，推荐默认）

| 层 | 组件 | 说明 |
|---|---|---|
| 北向入口 | 云负载均衡（L4/L7） | 仅做 TLS 终止与基础转发 |
| 业务层 | Gateway Core（Go 单体） | 内含 Auth/RateLimit/Router/Billing/subapi connector |
| 数据层 | PostgreSQL 15 | 交易、计费、审计主存储 |
| 缓存层 | Redis 7 | 分布式限流、并发门控、短期状态 |
| 观测层 | Prometheus + 云日志（stdout） | 指标+日志最小闭环，不默认引入 Loki |
| 外部集成 | subapi（内网） | mTLS 双向认证，作为外部模块接入 |

默认不引入（极简模式）：
1. API 网关产品层（Kong/Traefik）作为必选组件。
2. Loki/ELK 独立日志平台。
3. Kafka、Istio、多集群服务治理。

极简模式退出条件（任一触发）：
1. 需要在入口层做复杂插件治理（统一 WAF/插件策略/多协议细粒度控制）。
2. 网关核心服务发布耦合导致两次以上周更失败。
3. 观测检索 SLA 无法满足（日志检索 < 1 分钟）且云日志能力不足。

### 2.1 S0/S1 最小可运营栈（必须）

| 层 | 组件 | 说明 |
|---|---|---|
| 北向入口 | 单一入口层（极简默认：云LB + Go；增强模式：Kong） | 统一鉴权、限流、协议归一 |
| 业务层 | Go 服务（模块化单体优先） | Router/Auth/Billing/Adapter 在同一部署单元 |
| 数据层 | PostgreSQL 15 | 交易、计费、审计主存储 |
| 缓存层 | Redis 7 | 限流、并发门控、短期状态 |
| 观测层 | Prometheus + Grafana（日志默认走云日志） | 指标/日志最小闭环 |
| 外部集成 | subapi（内网） | 通过 connector 接入，mTLS 双向认证 |

不引入项（S0/S1 禁止默认引入）：
1. 服务网格（Istio）。
2. Kafka 作为默认依赖。
3. ELK 全套日志平台。
4. Loki（仅在日志检索SLA不满足时引入）。

### 2.2 S2 目标架构（有条件增强）

1. Router Core 成为主路径执行引擎。
2. subapi 保留长尾协议与回退通道。
3. 按需引入异步事件总线，先从 PG outbox 开始，再评估 Kafka。

---

## 3. 触发式扩容条件（唯一准入）

| 组件 | 引入前替代方案 | 触发条件（任一满足） | 引入后验收 |
|---|---|---|---|
| Kafka | PostgreSQL Outbox + Worker | 异步事件持续 > 5k msg/s 且 backlog > 15min；或跨域消费者>=3类 | 消费延迟 P95 < 5s，消息丢失=0 |
| Istio | 网关 + 应用内 mTLS/熔断 | 服务数量 > 8 且跨服务调用路径 > 20；或多集群流量治理需求明确 | 变更可观测、故障域隔离验证通过 |
| ELK | Loki + 对象存储归档 | 日志检索需求超出 Loki 能力，且安全审计检索 SLA < 1min | 检索 SLA 达标，成本可控 |
| 服务拆分 | 模块化单体 | 单服务 CPU>70% 持续7天；发布耦合导致周更失败>=2次 | 拆分后发布失败率下降 >=50% |

---

## 4. 部署拓扑（简化且可靠）

```text
Internet
  -> Cloud LB (or Kong in enhanced mode)
    -> Gateway Core (Go)
      -> Router Core / subapi connector
        -> Providers
    -> PostgreSQL
    -> Redis
    -> Observability (Prometheus/Grafana + Cloud Logs)
```

可靠性要求：
1. 回滚：10分钟触发、30分钟恢复。
2. 灰度：5% -> 20% -> 50% -> 100%。
3. 故障域：按租户分批升波，避免全量冲击。

---

## 5. 运维简化设计

1. 单一控制面：路由、开关、灰度比例统一发布入口。
2. 单一门禁：发布必须通过唯一验收门禁表。
3. 标准 Runbook：告警 -> 判断 -> 操作 -> 验证。
4. 证据包制度：每次升波必须产出日志+指标+结论。

---

## 6. 与现有文档关系

1. 本文档替代 `technical_architecture_design_v1_2026-03-18.md` 中“默认重组件组合”的实现建议。
2. 本文档与以下文档共同构成实施基线：
   - `llm_gateway_subapi_evolution_plan_v4_2_2026-03-24.md`
   - `acceptance_gate_single_source_v1_2026-03-18.md`
   - `test_plan_go_aligned_v1_2026-03-18.md`

---

## 7. 首周落地动作

1. 冻结 S0/S1 最小栈，不引入 Istio/Kafka/ELK。
2. 默认采用极简模式（Cloud LB + Go Core），Kong/Loki按退出条件评审后引入。
3. 发布扩容触发条件评审模板（无触发条件不得引入组件）。
4. 将运维看板与门禁阈值绑定到唯一验收门禁表。
5. 完成一次“升级 + 灰度 + 自动回滚”全链路演练。