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

基于当前源码与日志方案（见 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

业务访问关系（示意图）

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）

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 无安装）：

# 在项目根目录执行
npx md-to-pdf .\docs\云原生迁移方案-基础设施篇.md --config-file .md-to-pdf.json

方案二（Pandoc）：

winget install Pandoc.Pandoc
# 若需 LaTeX：winget install MiKTeX.MiKTeX
pandoc .\docs\云原生迁移方案-基础设施篇.md -o .\docs\云原生迁移方案-基础设施篇.pdf

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

云原生迁移方案-基础设施篇.md 9.6 KB 文件歷史 原始文件

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

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

业务访问关系（示意图）

二. 日志与监控

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

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

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

三. HPA/AHPA 建设

1) 原理与功能

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

3) 实施建议

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

五. 资源申请与迁移计划

资源

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

可选落地脚本/命令

附：参考与对齐

PDF 导出（可选）

云原生迁移方案-基础设施篇.md 9.6 KB

文件歷史原始文件