TSF + TKE 混合部署：Java 微服务在腾讯云的容灾与弹性实战

TSF + TKE 混合部署：Java 微服务在腾讯云的容灾与弹性实战

作者：[你的名字]｜Java 工程师｜专注云原生微服务架构 关键词：Spring Cloud、TSF、TKE、服务治理、K8s HPA、跨可用区容灾

一、缘起：当“高可用”不再只是口号

在真实的金融业务场景中，SLA 99.99% 不是PPT上的数字，而是每次发布、每次扩容、每次网络抖动的生死考验。我们的核心风控系统原本部署在自建IDC，迁移至腾讯云后，我们面临三个硬骨头：

• 注册中心震荡：网络分区导致 Eureka 出现脑裂，服务调用失败率飙升至 15%；
• 弹性滞后：大促期间手工扩容 10+ 节点需要 8 分钟，错过流量峰值；
• 发布风险：金丝雀发布依赖人工切流，回滚耗时超过 3 分钟。

本次实战选用 TSF（腾讯微服务平台） 治理注册与配置，TKE（容器服务） 承载计算节点，利用 跨可用区（AZ） 部署实现机房级容灾。

二、总体架构设计

┌─────────────────────────────────────────────────────┐
│                    CLB (公网/内网)                   │
└─────────────────┬───────────────────────────────────┘
                  │
      ┌───────────┼───────────┐
      │           │           │
┌─────▼─────┐ ┌───▼─────┐ ┌──▼─────┐
│ API网关   │ │ 风控核心 │ │ 数据中台│
│ (Spring  │ │ (Java)   │ │ (Java)  │
│  Cloud)   │ │         │ │         │
└─────┬─────┘ └───┬─────┘ └──┬─────┘
      │           │           │
      └───────────┼───────────┘
                  │
         ┌────────▼────────┐
         │  TSF 注册中心   │
         │ (Polaris 内核)  │
         └────────┬────────┘
                  │
         ┌────────▼────────┐
         │  TKE 集群       │
         │ (3 AZ × 2 节点) │
         └─────────────────┘

关键设计决策：

• 注册中心：TSF 托管的 Polaris（兼容 Nacos/Eureka 协议），避免自建 ZK 的运维负担；
• 配置管理：TSF 应用配置 + 全局配置，支持动态刷新；
• 存储层：腾讯云 CBS 持久卷 + CRS（Redis）做缓存，CBS 通过标签绑定 AZ 实现本地读。

三、TSF 服务治理深度实践

3.1 注册发现：从 Eureka 到 Polaris 的平滑迁移

TSF 的 Spring Cloud Tencent 组件提供了 零代码侵入 的接入方式：

<!-- 替换原有 spring-cloud-starter-netflix-eureka-client -->
<dependency>
    <groupId>com.tencent.cloud</groupId>
    <artifactId>spring-cloud-starter-tencent-polaris-discovery</artifactId>
    <version>1.12.0-2022.0.5</version>
</dependency>

迁移踩坑：旧服务使用了 Eureka 的 eureka.instance.lease-renewal-interval-in-seconds 自定义心跳，迁移后需改为 Polaris 的 spring.cloud.polaris.discovery.heartbeat-interval。TSF 控制台提供 服务治理迁移工具，可灰度切流。

3.2 路由与容灾：基于元数据的 AZ 亲和路由

为避免跨 AZ 调用带来的延迟和费用，我们在 TSF 中定义 路由规则：

1. 为每个服务实例打标：az: ap-guangzhou-3 / az: ap-guangzhou-4；
2. 创建 就近路由 规则：优先调用同 AZ 实例，同 AZ 不可用时降级到其他 AZ。

# TSF 路由规则（YAML 描述）
- name: "az-first-route"
  conditions:
    - type: "metadata"
      key: "az"
      operator: "=="
      value: "${local.az}"
  weight: 100
  fallback: true

通过 TSF 的 全链路灰度 能力，我们还能按 userId 哈希将测试流量路由到灰度版本，实现 细粒度发布。

3.3 熔断与限流：防止雪崩的最后一公里

TSF 集成了 Sentinel，我们在网关层配置了 QPS 限流（阈值 5000）和 慢调用熔断（RT > 500ms 且比例 > 30% 则熔断 10s）。关键代码：

@PostConstruct
public void initFlowRule() {
    FlowRule rule = new FlowRule();
    rule.setResource("gateway_api");
    rule.setGrade(RuleConstant.FLOW_GRADE_QPS);
    rule.setCount(5000);
    FlowRuleManager.loadRules(Collections.singletonList(rule));
}

四、TKE 弹性伸缩：从 HPA 到 CronHPA 的混合策略

4.1 普通 HPA：基于 CPU 的快速扩容

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: risk-engine-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: risk-engine
  minReplicas: 3
  maxReplicas: 15
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

4.2 CronHPA：定时预置应对“脉冲式”流量

金融业务有明显的早高峰（9:00-10:00）和月末结算（20:00-22:00）。我们使用 TKE 的 CronHPA 提前 5 分钟扩容：

apiVersion: autoscaling.tencent.com/v1
kind: CronHPA
metadata:
  name: risk-engine-cron
spec:
  scaleTarget:
    apiVersion: apps/v1
    kind: Deployment
    name: risk-engine
  crons:
    - schedule: "0 8 * * *"   # 每天8:00扩容
      targetReplicas: 10
    - schedule: "0 19 * * *"  # 每天19:00扩容
      targetReplicas: 12

注意：CronHPA 与 HPA 同时使用时，TKE 会取 较大值，避免互相覆盖。

4.3 冷启动优化：让扩容真正“快”起来

Java 应用在 TKE 上扩容慢的主要原因是 JVM 启动和类加载。我们做了三处优化：

1. 基础镜像：使用腾讯云 Tlinux + OpenJDK 11，预置常用类库；
2. JVM 参数：-XX:+UseContainerSupport -XX:InitialRAMPercentage=70.0 -XX:MaxRAMPercentage=80.0；
3. Polaris 服务注册预热：在 @PostConstruct 中提前执行 2 次健康检查接口，使注册中心缓存生效。

扩容时间从 8 分钟缩短至 2.5 分钟。

五、跨可用区容灾：从理论到代码

5.1 集群拓扑

• TKE 节点：3 个 AZ（广州三/四/五区），每个 AZ 至少 2 个节点；
• Pod 分布：使用 topologySpreadConstraints 强制跨 AZ 打散；

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      app: risk-engine

5.2 故障模拟演练

我们通过 TKE 的 节点封锁 模拟 AZ 故障：

1. 封锁广州三区所有节点；
2. 观察 Pod 是否在 5 分钟内漂移至其他 AZ；
3. 检查 TSF 注册中心是否剔除故障实例（默认心跳超时 15s）。

结果：服务调用失败率 0.2%，仅出现少量重试，RTO（恢复时间）约 110 秒。

5.3 持久化数据容灾

使用 CBS 时需注意：CBS 不支持跨 AZ 挂载。因此我们：

• 为每个 AZ 创建独立的 StorageClass，并通过 节点亲和性 绑定；
• 关键数据使用 CRS（Redis）跨 AZ 主从同步，写入主（广州三区），读从（广州四区）。

六、可观测性：TAM + Prometheus 双栈监控

TSF 集成了 腾讯云应用性能观测（TAM），无需额外埋点即可采集调用链。我们自定义了三个核心指标：

• risk_engine_qps：按接口维度；
• risk_engine_rt：P99 延迟；
• risk_engine_error_rate：业务异常率。

告警规则：当 error_rate > 1% 且持续 2 分钟，触发企业微信 + 短信告警。同时我们利用 TSF 的 事件中心 联动 SCF（云函数） 自动扩容。

七、踩坑与经验总结

八、未来演进方向

1. 混沌工程：通过腾讯云 Chaos Mesh 服务定期注入故障，验证自愈能力；
2. Serverless 化：将部分计算密集型任务迁移至 SCF，降低常驻成本；
3. GitOps：结合 CODING 实现配置即代码，TKE 集群声明式管理。

结语

本次实践证明了 TSF + TKE 的组合在 Java 微服务场景下，既能提供企业级的服务治理能力，又能充分利用 K8s 的弹性与容灾特性。技术选型没有银弹，但腾讯云提供的 云原生套件 让我们少走了许多弯路。

给后来者的建议：先做好服务拆分与接口契约，再上治理平台；优先用 TSF 的托管组件，把精力放在业务逻辑上。

所有配置均已脱敏，完整代码和 Terraform 脚本已上传至 [GitHub - 你的仓库]（示例链接）。