chore: initial snapshot for gitea/github upload

docs/technical_architecture_optimized_v2_2026-03-18.md

@@ -0,0 +1,122 @@
+# 优化技术架构设计（最小可运营栈 + 触发式扩容）
+
+- 版本：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. 完成一次“升级 + 灰度 + 自动回滚”全链路演练。