# 云原生迁移方案（基础设施篇 · 初稿）

> 基于当前源码与日志方案（见 Log.md）并结合业务架构撰写，面向 ACK-Pro + MSE + ASM（Istio）统一落地。

---

## 一. 结果导向（迁移后的目标）

- 统一北向入口与服务治理：ALB → API Gateway → Nacos 服务发现 → Dubbo RPC → 内部服务（各大模块）
- 数据与中间件云原生化：Redis / MySQL / RabbitMQ / MongoDB / Seata（AT/TCC）由云托管或托管版运维
- 服务网格：引入 ASM（Istio），启用 `istiod` 控制面，Sidecar 注入实现 mTLS、灰度、熔断、可观测性
- 自动弹性：基于 HPA/AHPA，按核心业务指标（QPS/订单/延迟）进行 Pod 自动扩缩容
- 日志与监控一体化：应用统一输出 JSON，采集 Vector → 存储 Loki → 指标 Prometheus → 展示 Grafana

### 业务访问关系（示意图）

```mermaid
flowchart LR
  User[用户/客户端] --> ALB[ALB 负载均衡]
  ALB --> GW[API Gateway]
  subgraph Mesh[ASM/Istio Mesh]
    GW -->|Nacos 注册/发现| Nacos[(Nacos/MSE)]
    GW --> Dubbo[Dubbo RPC]
    Dubbo --> SvcA[订单中心]
    Dubbo --> SvcB[支付中心]
    Dubbo --> SvcC[商户中心]
    Dubbo --> SvcD[营销中心]
    Dubbo --> SvcE[网关搜索]
  end

  subgraph Data[数据与中间件]
    Redis[(Redis)]
    MySQL[(MySQL)]
    MQ[(RabbitMQ)]
    Mongo[(MongoDB)]
    Seata[(Seata)]
  end

  SvcA--读写-->MySQL
  SvcA--缓存-->Redis
  SvcA--消息-->MQ
  SvcB--读写-->MySQL
  SvcB--缓存-->Redis
  SvcB--消息-->MQ
  SvcC--读写-->Mongo
  SvcC--缓存-->Redis
  SvcA--事务协调-->Seata

  subgraph Ops[运维调度]
    Cron[K8s CronJob]
    Istiod[istiod 控制面]
  end
  Cron --> SvcA
  Cron --> SvcB
  Istiod -.sidecar注入.-> SvcA
  Istiod -.mTLS/路由.-> SvcB
```

- 内部服务（大模块）可映射至当前目录中的核心仓库：订单中心、支付中心、商户中心、营销中心、网关/搜索、统计报表等（参考 workspace 子目录）。

---

## 二. 日志与监控

### 1) 业务导向与指标（监控重心上移）

- 关键指标：
  - QPS：按 `uri_group` 与服务维度
  - ORDER：订单成功率/失败率/异常原因
  - DURATION：请求延时分布 p50/p95/p99（毫秒）

### 2) 日志与监控架构（Vector → Loki → Prometheus → Grafana）

```mermaid
flowchart LR
  subgraph App[应用微服务]
    Log[Logback Async JSON]
    Act[Spring Actuator/Prometheus]
  end
  Log --> Vec[Vector Agent]
  Vec --> Loki[Loki 日志]
  Vec --> Prom[Prometheus 指标]
  Prom --> Graf[Grafana 仪表盘/告警]
  Act --> Prom

  note[说明: 统一在 Filter/MDC 输出 JSON, Vector 解析为 Loki 标签与 Prom 指标]
```

- 应用层：零侵入输出单行 JSON（详见 Log.md），集中设置 MDC 字段：`traceId/uri/uri_group/event_class/duration/status`。
- 采集层：Vector 做解析与标签抽取，低基数上标签，高基数留 JSON；导出 Prometheus 指标（QPS/订单/延迟）
- 指标与展示：Prometheus 存储，Grafana 展示与告警；对接云监控或自建均可

### 3) 云监控 vs 自建（价格与功能对比要点）

- 自建（Loki/Prometheus/Grafana/Vector）：
  - 优点：可定制、可控成本、无供应商锁定；资源随集群即可
  - 成本项：ECS/ACK 节点资源、持久化（OSS/S3）与运维人力
- 云监控（阿里云 ARMS/云监控/日志服务）：
  - 优点：开箱即用、自动伸缩、SLA；与 ACK/ASM 深度集成
  - 成本项：按数据量/实例规格计费；功能随套餐变化
- 结论：生产建议“混合”——核心链路自建保障可控性，非核心场景可接云产品降低维护成本。

> 现网 Log.md 已提供 Vector/Loki/Prometheus 的落地配置与性能对标：本方案延迟 <2s，CPU 8-15%，内存 80-100MB（对比全文）。

---

## 三. HPA/AHPA 建设

### 1) 原理与功能

- HPA（Horizontal Pod Autoscaler）：依据资源指标（CPU/内存）或自定义/外部指标，在目标平均值上下自动扩缩容。
- AHPA（ACK 增强 HPA）：在 ACK 上支持基于 Prometheus 查询的复杂指标、预测性扩容、最小/最大副本、冷启动优化等。

### 2) 示例：按业务 QPS 指标做自动扩缩容

- 标准 HPA（CPU 指标示例）：
```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-center-hpa
  namespace: shop-recycle
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-center
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
```

- 使用 Prometheus Adapter 的“外部指标”示例（按每 Pod QPS）：
```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-center-hpa-qps
  namespace: shop-recycle
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-center
  minReplicas: 2
  maxReplicas: 50
  metrics:
  - type: External
    external:
      metric:
        name: shop_recycle_requests_per_pod
        selector:
          matchLabels:
            app: order-center
      target:
        type: AverageValue
        averageValue: "10"  # 目标每 Pod QPS
```
> 需接入 Prometheus Adapter 暴露自定义指标至 `external.metrics.k8s.io`。

- AHPA（概念示例）：在 ACK 中以 CRD 形式定义，允许直接引用 PromQL 表达式与更丰富的策略（请按实际 ACK/AHPA 文档配置 CRD 字段）。

### 3) 实施建议

- 指标分层：CPU 作为兜底，业务指标（QPS/订单失败率/延迟）作为主驱动
- 保护与上限：设置 `minReplicas`/`maxReplicas`，并结合队列限流与缓存保护防止雪崩
- 预热与冷却：`stabilizationWindowSeconds` 合理设置，避免抖动；订单高峰前手动加热

---

## 四. 成本增量（示例表格）

> 说明：价格以 2026 年估算为例，需以阿里云当期定价为准；以下为模板占位，请用实际规格（带宽/实例数/存储量）替换。

| 服务 | 计费方式（示例） | 估算月价(CNY) | 获得能力 | 备注 |
| --- | --- | ---: | --- | --- |
| ALB | 按带宽/实例数 | TBD | 北向入口、七层负载、WAF | 与网关联动 |
| MSE（Nacos/Dubbo） | 实例规格/连接数 | TBD | 注册发现、治理、限流 | 托管免自运维 |
| RabbitMQ（云） | 实例规格/存储 | TBD | 队列解耦、异步削峰 | 与订单/支付协作 |
| Redis（云） | 内存容量/连接数 | TBD | 高速缓存、会话 | AOF/备份成本 |
| MongoDB（云） | 存储容量/IOPS | TBD | 文档型存储 | 索引与备份 |
| ASM（Istio） | 节点数/功能套餐 | TBD | mTLS、灰度流量、Observability | 提升治理能力 |
| HPA/AHPA 隐形成本 | 节点资源/冷启动 | 0-小幅 | 额外副本/预热资源 | 需容量冗余 |
| ACK-Pro 托管费 | 固定 | 35 | ACK 集群托管 | 用户提供数据 |

> 建议：成本测算以 3 台 ECS（现网）+ ACK-Pro 托管起步，自建日志/指标存储，评估云代管与自建混合比例。

---

## 五. 资源申请与迁移计划

### 资源

- 计算：现网 3 台 ECS 作为 ACK-Pro 节点（不计额外费用），加入 VPC 同网段
- 集群：ACK-Pro（托管费约 35 元/月，按用户提供）
- 服务治理：云原生 MSE（Nacos/Dubbo）；ASM（Istio 控制面 `istiod`）
- 中间件：Redis/MongoDB/MySQL/RabbitMQ/Seata（优先托管版或运维托管）
- 采集与监控：Vector/Loki/Prometheus/Grafana（可自建）

### 迁移路线（低风险分阶段）

1) 基线准备（Week 0-1）
- 建 ACK-Pro 集群，接入 3 台 ECS；部署 Nacos/MSE 基础；开启 ASM 并完成 Sidecar 注入验证
- 部署 Vector/Loki/Prometheus/Grafana（或云监控对接），同步应用 Logback JSON 输出（按 Log.md）

2) 网关与服务治理（Week 2）
- ALB → API Gateway 联通；服务注册至 Nacos/MSE，Dubbo RPC 通路验证
- Mesh 试点：对订单中心与支付中心启用流量管理（灰度/熔断/重试），mTLS 验证

3) 数据层迁移（Week 3）
- Redis/MySQL/RabbitMQ/MongoDB 切换至托管版或托管运维，数据迁移与读写压测
- 引入 Seata（AT/TCC）做关键事务一致性，联调与回滚演练

4) 弹性与高峰（Week 4）
- 接入 HPA（CPU 兜底）与业务指标 Adapter，配置 AHPA（如使用 ACK 增强）
- 订单高峰前做预热与容量演练，设置 Grafana 告警门限

5) 上线与稳定（Week 5）
- Canary 10% → 50% → 全量，保留回滚脚本与双写（日志/指标）72h
- 完成 SRE 运维手册与 Oncall 告警确认

### 可选落地脚本/命令

- 回滚（示例）：
```bash
helm rollback vector -n logging
kubectl rollout undo deployment/order-center -n shop-recycle
```

---

## 附：参考与对齐

- 现网日志方案详见 Log.md：零侵入 MDC、Vector/Loki/Prometheus 架构、CI 基数门禁与告警模板
- 模块映射：workspace 下的 `shop-recycle-*` 目录代表内部服务（订单/支付/商户/营销/网关/统计等），迁移优先级按业务关键度排序
- 安全与合规：ASM mTLS、WAF/ALB 规则、敏感日志红线与脱敏；数据库访问最小权限

---

## PDF 导出（可选）

- 方案一（Node 无安装）：
```powershell
# 在项目根目录执行
npx md-to-pdf .\docs\云原生迁移方案-基础设施篇.md --config-file .md-to-pdf.json
```
- 方案二（Pandoc）：
```powershell
winget install Pandoc.Pandoc
# 若需 LaTeX：winget install MiKTeX.MiKTeX
pandoc .\docs\云原生迁移方案-基础设施篇.md -o .\docs\云原生迁移方案-基础设施篇.pdf
```

> 如需我生成 md-to-pdf 的配置文件或直接导出 PDF，请告知，我可补充 `md-to-pdf.json` 或执行转换。