云原生迁移方案 - 基础设施篇（重构版）

1. 目标与结果

业务连续性：迁移期间零感知，RTO < 15 分钟，RPO = 0（有状态组件托管化）。
弹性与韧性：流量高峰 5 分钟内可横向扩 2 倍；灰度/回滚 < 5 分钟。
可观测性：QPS、订单成功率、p95 延时、错误率全链路可见；异常 5 分钟内告警。
成本可控：新增月度核心支出可控在 ¥500 内（不含业务流量费）；按需扩缩避免常驻浪费。

2. 目标架构（流量路径）

graph TD
    User((用户/客户端)) --> ALB[ALB 负载均衡]
    ALB --> Gateway[MSE 云原生网关]
    Gateway --> Nacos[Nacos / 配置]

    subgraph "ACK 集群"
        Nacos --> DubboConsumer[Dubbo 消费者]
        DubboConsumer -- RPC (Dubbo/gRPC) --> DubboProvider[内部服务/大模块]
        DubboProvider --> Istiod[ASM/Istio 控制面]
        DubboProvider --> Cron[K8s CronJob]
    end

    DubboProvider --> Redis[(Redis)]
    DubboProvider --> MySQL[(MySQL)]
    DubboProvider --> RabbitMQ[(RabbitMQ)]
    DubboProvider --> MongoDB[(MongoDB)]
    DubboProvider --> Seata[Seata 分布式事务]

访问关系说明

外部流量：ALB 终止 TLS，转发至 MSE 网关；网关基于 Nacos 实现服务路由与灰度。
东西向流量：Dubbo 服务通过 ASM 提供的 Sidecar 统一做流量治理、熔断与可观测性注入。
调度：业务定时任务迁移为 K8s CronJob，与应用镜像同生命周期、同发布节奏。
数据层：所有状态型组件优先托管化，降运维面风险；Seata 负责分布式事务。

3. 日志与监控

3.1 监控重心（业务优先）

核心 KPI：QPS、订单成功率/失败率、p50/p95/p99 延时、错误率。
系统健康：JVM/GC、线程池、连接池、水位、节点资源（CPU/Mem/FD）。

3.2 采集与展现路径

flowchart LR
    subgraph Pod
        App[业务应用]
        App -- Actuator/Exporter --> PromExp[Prom Exporter]
        App -- Stdout JSON --> Vector
    end
    Vector --> Loki[(Loki)]
    Vector --> Prom[(Prometheus)]
    PromExp --> Prom
    Prom --> Grafana
    Loki --> Grafana

日志侧：应用输出单行 JSON，Vector 解析+降噪，落 Loki；查询/告警用 LogQL。
指标侧：Actuator/Exporter 暴露 JVM/线程池/HTTP histogram，自定义业务指标写入 Prometheus；Grafana 汇总看板+告警。
云监控对比：
- 流量小、快速落地：ARMS/云监控开箱即用，少运维；
- 流量大、需定制度：自建 Loki+Prom 更低成本、可扩展，建议后期切换。

4. 弹性伸缩（HPA/AHPA）

AHPA 原理：基于历史数据做预测，结合自定义业务指标提前预热，避免原生 HPA 滞后。
示例策略：
- 触发条件：order_success_rate < 95% 或 http_server_requests_p95 > 500ms；
- 扩容动作：副本数在 2~10 间自动调节，步长 50%；
- 回落条件：指标连续 10 分钟恢复后缩容。

（示例 YAML 片段，供落地时调整）

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Pods
      pods:
        metric:
          name: http_p95_latency_ms
        target:
          type: AverageValue
          averageValue: 500m # 500ms

5. 成本增量（估算）

资源	预估单价/月	价值/能力	备注
ALB (基础型)	~¥50+流量	7 层转发、TLS 卸载	按流量计费为主
MSE 网关	~¥150	动态路由、灰度、限流	含网关能力
MSE/Nacos/Dubbo 注册	~¥100	托管注册/配置，减运维	可与网关套餐绑定
ASM (Istio)	~¥0-300	东西向治理、可观测性注入	标准版起收
Redis/Mongo/RabbitMQ	按需计费	高可用托管，免自运维	选按量计费起步
HPA/AHPA 隐形成本	弹性节点费用	用多少付多少，较常驻节省 ~30%	需监控缩容时机
备份与存储	~¥30-80	日志/快照存储	随容量浮动

核心新增固定费控制在 ~¥500/月；大头来自业务流量与数据存储的按量计费。

6. 资源申请与迁移计划

6.1 资源清单

计算：现有 3 台 ECS 加入 ACK-PRO（托管费 ~¥35/月）。
中间件：申请 MSE（含 Nacos/Dubbo/Gateway）、Redis/Mongo/RabbitMQ 托管版、ASM 基础/标准版。
观测：部署 Loki + Prometheus + Grafana（可先用云监控，后期自建）。

6.2 里程碑（示例 2 周）

D1-D2：ACK、MSE、ASM 基础设施落地；网络/安全组/证书准备。
D3-D5：日志与监控链路打通（Vector -> Loki/Prom，Actuator -> Prom）。
D6-D8：非核心 Dubbo 服务与 CronJob 迁入；验证路由、配置、密钥。
D9-D10：压测与 AHPA 策略验证；观察缩扩容曲线。
D11-D12：灰度切流（ALB 权重/网关路由）；回滚预案演练。

6.3 风险与回滚

配置漂移：使用 GitOps/Helm 管控，禁止手改；发现异常可直接回滚 Chart 版本。
流量突刺：保留原机房降级开关；Prometheus 告警触发时可临时提升副本上限。
数据一致性：切换前对接 Seata/事务补偿；核心写流量先双写、比对再切换。

本稿为重构版，聚焦“业务优先、弹性可控、成本透明”的最小落地路径，可按实际规模调整容量与价格。# 云原生迁移方案 - 基础设施篇 (初稿)

一、结果导向：最终状态架构

1.1 最终目标架构图 (ASCII)

graph TD
    User((用户/客户端)) --> ALB[阿里云 ALB 负载均衡]
    
    subgraph "阿里云 ACK 集群 (K8s)"
        ALB --> Gateway[MSE 云原生网关]
        Gateway --> Nacos[Nacos 注册中心/配置中心]
        
        subgraph "Service Mesh (Istio/ASM)"
            Nacos --> DubboConsumer[Dubbo 服务消费者]
            DubboConsumer -- RPC (gRPC/Dubbo) --> DubboProvider[DUBBO 内部服务/大模块]
            DubboProvider --> IstioSidecar[Istiod 控制面]
        end

        subgraph "持久化与中间件 (云原生托管)"
            DubboProvider --> Redis[(Redis)]
            DubboProvider --> MySQL[(MySQL)]
            DubboProvider --> RabbitMQ[(RabbitMQ)]
            DubboProvider --> MongoDB[(MongoDB)]
            DubboProvider --> Seata[Seata 分布式事务]
        end
        
        subgraph "定时任务"
            K8sCron[K8s CronJob]
        end
    end

1.2 业务访问关系说明

外部访问：流量经 ALB 卸载 SSL 证书后转发至集群内的 MSE 云原生网关。
服务发现：网关通过 MSE Nacos 发现 Service，实现南北向流量管理。
内部通信：大模块间通过 Dubbo RPC 通信，并由 ASM (Service Mesh) 实现东西向流量治理（灰度、熔断、链路追踪）。
任务调度：原生业务定时逻辑迁移至 K8s CronJob，确保与应用生命周期一致。

二、日志与监控

2.1 监控重心上移

我们不再只关注宿主机负载，而是聚焦于业务健康度。

关键性能指标 (KPI)：QPS (吞吐)、ORDER (业务成功率/量)、DURATION (响应延时)。

2.2 日志与监控架构图

flowchart LR
    subgraph "应用 Pod"
        App[业务应用] --> Stdout[Log Stdout]
        App -- Actuator --> PromExp[Prometheus Exporter]
    end

    subgraph "采集层"
        Stdout --> Vector[Vector Agent]
    end

    subgraph "数据中台"
        Vector --> Loki[(Loki 日志库)]
        Vector --> Prom[(Prometheus 时序库)]
        PromExp --> Prom
    end

    subgraph "展示层"
        Loki --> Grafana[Grafana Dashboard]
        Prom --> Grafana
    end

2.3 自建与云监控对比

维度	自建监控 (Loki + Prom)	阿里云云监控/ARMS	结论
价格	低 (主要为存储成本)	高 (按指标量计费)	流量大时自建性价比极高
配置	需要运维维护配置文件	开箱即用，全图形化	早期推荐 ARMS，后期转自建
扩展性	插件丰富，自定义逻辑强	受限于平台功能	业务逻辑复杂推荐自建

三、 HPA 建设：自动伸缩演进

3.1 阿里云 AHPA (Advanced HPA) 原理

AHPA 基于预测算法和业务指标，解决了原生 HPA 扩容滞后的痛点。通过集成 Prometheus 自定义指标，可以在高峰期到来前自动完成 Pod 预热。

3.2 实现示例

假设针对“订单处理成功率”进行 HPA：

指标定义：从 Prometheus 提取 order_success_rate < 95%。
扩容逻辑：
- 当探测到处理速度低于阈值时，ACK 自动请求扩容 50% 的 Pod。
- 触发条件：avg(order_duration) > 500ms。
结果：在高并发大促场景下，系统在 2 分钟内完成吞吐量翻倍。

四、成本增量分析 (估算)

资源名称	预估单价	获得的功能与价值
ALB (基础型)	约 ¥50/月起 (含流量)	替代传统 SLB，支持更复杂的转发规则 (Header/Cookie)
MSE 网关	约 ¥150/月	统一网关、限流降级、服务发现，节省自建 Nginx/Zuul 成本
RabbitMQ/Redis/Mongo	云托管按需付费	极致稳定性，免去 DB 层运维痛苦
ASM (基础版/标准版)	约 ¥0-300/月	获得全链路治理能力，无侵入式服务监控
HPA 隐性成本	动态 ECS 扩容费	关键点：用完即销毁，比常驻包年包月 ECS 节省约 30% 支出

五、资源申请与迁移计划

5.1 资源配置

计算资源：3 台现网现有 ECS 作为节点，加入 ACK-PRO 托管版 集群（满足高可用 SLA）。
托管服务：申请 云原生 MSE（配置 2 节点高可用型）。
预估成本：
- ACK-PRO 托管费：约 ¥35/月。
- ECS 节点：作为现网原有扩容，不产生额外“迁云”溢价费用。
- 总计可控：初期核心纯新增支出 < ¥500/月。

5.2 迁移时间线

Day 1-2: 基础设施搭建（ACK + MSE + 基础网络设置）。
Day 3-5: 日志/监控系统测试（Vector 采集路径打通）。
Day 6-10: 分批迁移 CronJob 与 Dubbo 非核心模块。
Day 11: 灰度切流测试（ALB 权重灰度）。

注：本方案旨在利用托管服务降低运维压力，同时控制核心成本。

Cloud-Native-Migration-Plan.md 11 KB 文件歷史 原始文件