SpringCloud服务部署到腾讯云K8S完整实战

一、TKE vs 自建 K8s：架构选型的第一道分水岭

1.1 托管 vs 自建的责任划分矩阵

把 K8s 拆成"控制面"和"数据面"两层是看托管服务的关键视角。控制面（API Server、etcd、Scheduler、Controller Manager）由云厂商托管 vs 自建，决定了 70% 的运维工作量归属。下表是按组件维度的责任划分：

组件	自建 K8s	腾讯云 TKE	责任归属
etcd 集群	自建（3/5 节点）	腾讯云托管	控制面高可用 + 备份
API Server	自建 + LB	腾讯云托管	证书 / 鉴权 / 审计
Scheduler / Controller	自建	腾讯云托管	调度策略可配置
Node（kubelet / 容器运行时）	自建 CVM	腾讯云 CVM 节点池	OS 升级 / 内核补丁
CNI / 网络插件	自选 + 维护	集成 VPC-CNI	网络策略
存储插件	自选 CSI	集成 CBS / CFS	数据持久化

关键判断点：你的团队有没有 3 个以上 SRE 专职运维 K8s？如果没有，TKE 的全托管控制面至少帮你省下 2 个 FTE。这是"决策矩阵"背后真正的成本账。

1.2 TCO 模型：3 年总拥有成本对比

架构选型不能只看资源单价，要把"控制面运维"和"故障停机损失"算进去。下面是 3 年期 TCO 模型（按 50 节点规模估算）：

flowchart LR subgraph 自建["自建 K8s · 3年TCO"] A1[控制面 3 节点
≈18万] --> A2[数据面 50 节点
≈180万] A2 --> A3[SRE 2 FTE × 3年
≈180万] A3 --> A4[故障停机损失
≈30万] A4 --> AT[总计 ≈408万] end subgraph TKE["腾讯云 TKE · 3年TCO"] B1[TKE 集群费
≈36万] --> B2[数据面 50 节点
≈180万] B2 --> B3[SRE 0.5 FTE × 3年
≈45万] B3 --> B4[SLA 99.95% 损失
≈10万] B4 --> BT[总计 ≈271万] end style AT fill:#2d1f3d,stroke:#a855f7,color:#fff style BT fill:#1f3d2d,stroke:#22c55e,color:#fff

TKE 节省 137 万的核心来源：控制面免运维 + SRE 编制减半。但要注意：TKE 集群费按"集群管理费 + 节点费"双轨计费，规模超过 100 节点时边际成本会重新平衡 —— 这是临界点决策。

二、跨 AZ 高可用拓扑：把鸡蛋放在腾讯云的几个篮子里

2.1 三 AZ 拓扑：故障域隔离的第一性原理

高可用不是"多部署几份"这么简单。本质是故障域隔离 + 流量自动切换。腾讯云 TKE 的节点池支持跨 AZ 调度，下面是三 AZ 拓扑视图：

flowchart TB User([用户流量]) --> CLB[腾讯云 CLB
anycast IP] subgraph VPC["VPC: 10.0.0.0/16"] CLB --> Ingress1[Ingress Gateway
广州一区] CLB --> Ingress2[Ingress Gateway
广州二区] CLB --> Ingress3[Ingress Gateway
广州三区] subgraph AZ1["可用区 A"] Ingress1 --> PodA1[业务 Pod × N] PodA1 --> SvcA[ClusterIP Service] end subgraph AZ2["可用区 B"] Ingress2 --> PodA2[业务 Pod × N] PodA2 --> SvcA end subgraph AZ3["可用区 C"] Ingress3 --> PodA3[业务 Pod × N] PodA3 --> SvcA end SvcA -.DNS 轮询.-> PodA1 SvcA -.DNS 轮询.-> PodA2 SvcA -.DNS 轮询.-> PodA3 end style AZ1 fill:#1f2d3d,stroke:#3b82f6,color:#fff style AZ2 fill:#1f2d3d,stroke:#3b82f6,color:#fff style AZ3 fill:#1f2d3d,stroke:#3b82f6,color:#fff

三个关键设计原则：(1) Ingress Gateway 每个 AZ 至少 2 副本抗单点；(2) 业务 Pod 用 topologySpreadConstraints 强制跨 AZ 打散；(3) ClusterIP Service 跨 AZ 提供统一访问入口，D 由 CoreDNS 轮询。

2.2 节点池分层：核心 vs 边缘的物理隔离

把所有 Pod 混在一个节点池里是高可用的大忌 —— 一个低优先级的离线任务可能挤占在线服务的 CPU。TKE 支持自定义节点池标签 + Pod 节点选择器，实现物理隔离：

flowchart LR subgraph Critical["critical-pool · 在线核心"] C1[Gateway × 3] C2[Auth × 3] C3[Order × 6] end subgraph Normal["normal-pool · 普通业务"] N1[Product × 3] N2[User × 3] end subgraph Batch["batch-pool · 离线任务"] B1[报表计算 × 2] B2[日志压缩 × 1] end style Critical fill:#2d1f3d,stroke:#a855f7,color:#fff style Normal fill:#1f3d2d,stroke:#22c55e,color:#fff style Batch fill:#3d2d1f,stroke:#f59e0b,color:#fff

节点池分层的决策依据：业务优先级 × 资源需求 × 弹性策略 三维度。critical-pool 用包年包月实例保 SLA，batch-pool 用竞价实例降本 60%。

三、服务注册发现的演进：Eureka → Nacos → K8s Service

3.1 三种服务发现方案的架构对比

SpringCloud 体系下服务发现经历了三代演进，核心矛盾是"应用层注册中心"和"基础设施层 DNS"的边界：

每代演进的驱动力：Eureka 心跳+拉取解决"服务怎么找到对方"，Nacos 引入配置中心解决"配置怎么动态管理"，K8s Service + CoreDNS把服务发现下沉到基础设施层 —— 这意味着你不需要在应用层维护 Eureka/Nacos Server 的高可用。

3.2 时序图：服务调用链的完整路径

下面是 SpringCloud 服务在 TKE 上完成一次调用的全链路时序：

sequenceDiagram participant U as 客户端 participant G as Gateway Pod participant D as CoreDNS participant A as Auth Service Pod participant O as Order Service Pod participant M as MySQL Pod U->>G: HTTPS 请求 G->>D: 解析 auth-service.svc.cluster.local D-->>G: ClusterIP 10.96.1.10 G->>A: HTTP POST /verify A->>D: 解析 order-service.svc.cluster.local D-->>A: ClusterIP 10.96.2.20 A->>O: HTTP GET /orders/{id} O->>M: TCP 3306 M-->>O: rows O-->>A: 200 OK A-->>G: 200 OK G-->>U: 200 OK

关键观察：每次跨服务调用都经过 CoreDNS 解析，而 CoreDNS 在大规模集群（>500 服务）下会成为瓶颈 —— 这是后面"配置中心选型"和"Service Mesh 引入"决策的伏笔。

四、配置中心选型与灰度发布：Apollo/Nacos/原生 ConfigMap 的三角博弈

4.1 三种方案的能力对比矩阵

配置中心选型本质是"功能完备性 × 运维成本 × 业务侵入度"的三角博弈。下表是 TKE 场景下的横向对比：

维度	原生 ConfigMap	Nacos	Apollo
动态推送	需 Reload	长轮询	长轮询+WebSocket
版本管理	Git 托管	内置	内置 + 历史回滚
灰度发布	不支持	Beta 发布	灰度规则（IP/Label）
权限模型	K8s RBAC	弱	强（部门/项目/环境）
运维成本	低	中（自建集群）	中（Portal + Admin + Config）
业务侵入度	中（FileSource）	低	低

决策口诀：简单业务用 ConfigMap + Reload；中规模用 Nacos；金融/复杂灰度用 Apollo。我们的项目落在第二档，所以下文以 Nacos 为例。

4.2 灰度发布五阶段状态机

配置变更的灰度发布不是"打个标签就完了"，而是五阶段闭环：

stateDiagram-v2 [*] --> 草稿: 创建灰度分支草稿 --> 灰度生效: 配置灰度规则灰度生效 --> 灰度验证: 自动健康检查灰度生效 --> 灰度回滚: 验证失败灰度验证 --> 灰度全量: 人工确认灰度验证 --> 灰度回滚: 指标异常灰度全量 --> [*] 灰度回滚 --> 草稿

五阶段的核心价值：把"配置变更"从"一刀切"变成"渐进式"，任何阶段失败都能 30 秒内回滚 —— 这是金融级系统对配置变更的硬要求。

五、中间件部署策略：StatefulSet 背后的"为什么"

5.1 MySQL 读写分离拓扑

MySQL 在 K8s 上的部署不只是"换个 YAML 模板"。核心决策点是读写分离如何在 K8s Service 层表达：

flowchart TB App[业务 Pod] --> RW[ClusterIP: mysql-rw] App --> RO[ClusterIP: mysql-ro] subgraph Stateful["StatefulSet: mysql"] RW --> M1[(mysql-0
主库)] RO --> M2[(mysql-1
从库)] RO --> M3[(mysql-2
从库)] M1 -->|binlog| M2 M1 -->|binlog| M3 end subgraph Storage["持久化层"] M1 --> PVC1[PVC: cbs-100g] M2 --> PVC2[PVC: cbs-200g] M3 --> PVC3[PVC: cbs-200g] end style Stateful fill:#1f2d3d,stroke:#3b82f6,color:#fff style Storage fill:#2d1f3d,stroke:#a855f7,color:#fff

两个核心设计：(1) 用两个独立 ClusterIP Service（mysql-rw / mysql-ro）暴露读写入口，避免应用层判断"这是主还是从"；(2) PVC 与 Pod 一一绑定（StatefulSet 的核心特性），保证数据持久化与 Pod 生命周期的解耦。

5.2 Redis Cluster 槽位分配的拓扑

Redis Cluster 在 K8s 上的拓扑核心是槽位（slot）分配 + 节点间通信：

flowchart LR App[业务 Pod] --> CProxy[ClusterIP: redis-cluster] subgraph Cluster["Redis Cluster · 6 节点"] CProxy --> M1[redis-0
slots 0-5460] CProxy --> M2[redis-1
slots 5461-10922] CProxy --> M3[redis-2
slots 10923-16383] M1 <-.gossip.-> M2 M2 <-.gossip.-> M3 M1 <-.gossip.-> M3 end subgraph Replica["从节点"] M1 --> R1[redis-3] M2 --> R2[redis-4] M3 --> R3[redis-5] end

关键点：16384 个槽位均匀分布到 3 主 3 从，保证单节点故障不影响集群可用性。K8s 上需要用 StatefulSet 保证节点标识稳定（redis-0/1/2/3/4/5），否则重启后槽位映射会错乱。

5.3 RabbitMQ 镜像队列策略

RabbitMQ 的高可用核心是镜像队列（Mirrored Queue）：

flowchart TB P[生产者] --> HProxy[HAProxy] HProxy --> N1[rabbit-0] HProxy --> N2[rabbit-1] HProxy --> N3[rabbit-2] subgraph Queue["Queue: order.events (镜像策略: all)"] N1 --> Q1[Queue Master] N2 --> Q2[Queue Mirror] N3 --> Q3[Queue Mirror] Q1 <-.同步.-> Q2 Q1 <-.同步.-> Q3 end C[消费者] --> HProxy

镜像队列的代价是写性能下降 30%-50%，但换来"任意节点宕机消息不丢"。决策点：核心业务队列用镜像，监控/日志队列用普通队列。

六、滚动 vs 蓝绿 vs 金丝雀：发布模式的架构权衡

6.1 三种发布模式的状态机对比

发布模式不是技术问题，是风险控制策略。下面是三种主流模式的状态机视图：

stateDiagram-v2 direction LR state "滚动发布" as Rolling { [*] --> V1: 初始 V1 全量 V1 --> V1V2: 滚动替换 N/N+M V1V2 --> V2: 全部替换完成 V2 --> [*] } state "蓝绿发布" as BlueGreen { [*] --> BlueV1: 蓝=V1 绿=Idle BlueV1 --> Switch: 切流量到绿 Switch --> GreenV2: 绿=V2 GreenV2 --> [*] } state "金丝雀发布" as Canary { [*] --> V1Main: V1 95% V1Main --> V1Canary: V2 灰度 5% V1Canary --> V1V2Mix: 逐步放量 25%→50%→100% V1V2Mix --> V2: 灰度完成 V2 --> [*] }

6.2 三种模式的决策矩阵

维度	滚动发布	蓝绿发布	金丝雀发布
回滚速度	慢（需反向滚动）	秒级（切流量）	秒级（缩容灰度）
资源消耗	1×	2×（双倍容量）	1.x×
风险粒度	粗（整批）	粗（瞬间切换）	细（5% 流量验证）
适用场景	无状态服务	数据库迁移、大版本	高频迭代的核心服务

决策口诀：普通业务用滚动，重大变更用蓝绿，核心高频用金丝雀。我们的项目三套都用 —— CI/CD 流水线根据发布类型自动选择。

6.3 回滚链路设计

金丝雀发布最关键的不是"如何发布"，而是"如何回滚"。下面是回滚链路的状态机：

stateDiagram-v2 [*] --> 监控中监控中 --> 告警触发: 错误率 > 1% 或 P99 > SLA 告警触发 --> 自动回滚: 30s 内自动回滚 --> 缩容V2: kubectl scale --replicas=0 缩容V2 --> V1承接: V1 自动扩到 100% V1承接 --> 根因分析根因分析 --> [*] 监控中 --> 灰度通过: 5min 指标正常灰度通过 --> [*]

回滚链路的 SLA：从告警触发到 V2 缩容完成必须在 30 秒内。这要求 kubectl 命令 + 监控告警 + 自动化脚本形成闭环 —— 不能依赖人工判断。

七、可观测性体系：Metrics/Logs/Traces 三支柱在 TKE 上的落地

7.1 三支柱采集拓扑

可观测性的"三大支柱"（指标/日志/链路追踪）在 K8s 上需要统一的采集层。下面是完整采集拓扑：

flowchart TB subgraph Pods["业务 Pod"] App1[App 1
/actuator/prometheus] App2[App 2
OTel SDK] end subgraph Collect["采集层"] Prom[Prometheus
DaemonSet] OTel[OpenTelemetry Collector
DaemonSet] Loki[Loki Agent
DaemonSet] end subgraph Store["存储层"] Prom --> PromDB[(Prometheus TSDB)] OTel --> Tempo[(Tempo · Trace)] OTel --> PromDB Loki --> LokiDB[(Loki · Log)] end subgraph Show["展示层"] PromDB --> Grafana[Grafana] Tempo --> Grafana LokiDB --> Grafana Grafana --> Alert[AlertManager] end App1 -->|metrics| Prom App2 -->|traces| OTel App1 -->|stdout/stderr| Loki App2 -->|stdout/stderr| Loki style Collect fill:#1f2d3d,stroke:#3b82f6,color:#fff style Store fill:#2d1f3d,stroke:#a855f7,color:#fff style Show fill:#1f3d2d,stroke:#22c55e,color:#fff

三支柱的核心关联：通过 traceId 把 metric / log / trace 串起来 —— Grafana 可以在看 P99 延迟时直接跳转到对应慢请求的 trace，再下钻到具体日志。这是 OpenTelemetry 标准带来的关键能力。

7.2 多集群 Grafana 视图

TKE 上多集群管理是常态（开发/预发/生产），Grafana 通过数据源切换实现统一视图：

flowchart LR G[Grafana] --> DS1[DataSource: prod-tke] G --> DS2[DataSource: staging-tke] G --> DS3[DataSource: dev-tke] DS1 --> P1[(Prometheus prod)] DS2 --> P2[(Prometheus staging)] DS3 --> P3[(Prometheus dev)]

关键设计：环境标签（env: prod/staging/dev）作为 Prometheus 的 label，配合 Grafana 变量 $env 实现下拉切换。这是降本提效的关键 —— 不用为每个环境单独搭一套监控。

八、CI/CD 流水线与变更门控：从代码到生产的全链路追踪

8.1 流水线状态机

CI/CD 不是工具链的拼接，而是状态机驱动的变更门控。下面是完整流水线：

stateDiagram-v2 [*] --> 代码提交代码提交 --> 单元测试: 触发 Pipeline 单元测试 --> 构建镜像: 测试通过单元测试 --> 失败: 阻断失败 --> [*] 构建镜像 --> 推送TCR: 构建成功推送TCR --> 部署Staging 部署Staging --> 集成测试集成测试 --> 部署Canary 部署Canary --> 5%灰度验证 5%灰度验证 --> 全量发布: 指标通过 5%灰度验证 --> 自动回滚: 指标异常自动回滚 --> 根因分析根因分析 --> [*] 全量发布 --> [*]

8.2 门控决策的三要素：阈值、责任方、阻断逻辑

金丝雀灰度的门控决策看似是一个技术问题，实质是三个核心要素的明确化：

flowchart LR T[阈值设定
错误率 < 1%
P99 达标] --> D[责任方明确
系统自动决策] D --> B[阻断逻辑
失败 → 缩容 V2
成功 → 扩到全量] B --> R[回滚能力
镜像/配置/代码
三层秒级回退]

三个要素的设计哲学：阈值是经验值（要随业务调整），责任方决定自动化层级（系统自动 vs 人工确认），阻断逻辑是硬约束（不允许带病发布）。把"门控"从"约定俗成"变成"机制保障"，是金融级发布系统的核心标志。

8.3 紧急回滚链路

当生产事故发生时，"从代码到生产"链路要能反向快速回滚：

flowchart LR A[生产事故] --> B[一键回滚] B --> C[Git Tag 锁定] B --> D[镜像回滚到 V1] B --> E[配置回滚到 N-1] C --> F[5min 内服务恢复] D --> F E --> F F --> G[根因复盘] G --> H[补充监控/门控]

回滚链路的核心要求：从事故确认到服务恢复必须 5 分钟内。这要求镜像仓库、配置中心、Git 仓库三者都保留近 7 天的历史版本 + 支持秒级回退。

8.4 决策点总结：从代码到生产的 6 道门控

门控	检查内容	阻断条件	责任方
1. 单元测试	代码覆盖率 > 80%	测试失败	开发
2. 镜像构建	无 CVE 高危漏洞	镜像扫描失败	DevOps
3. 集成测试	Staging 烟雾测试	关键接口失败	QA
4. 金丝雀灰度	错误率 < 1%, P99 达标	任一指标异常	系统自动
5. 全量发布	流量切换 100%	健康检查失败	系统自动
6. 持续观测	线上指标 1h 稳定	SLO 违约	SRE

六道门控的设计哲学：越往后自动化程度越高、越往后决策延迟越短。前 3 道人为介入（开发/QA 责任），后 3 道系统自动（SRE 兜底）。这是金融级发布系统的标准分层。

SpringCloud on 腾讯云 TKE：架构决策全景

📖 目录