ACK + Spring Cloud Alibaba 实战：云原生微服务从0到1的全链路搭建

摘要：单体应用 QPS 天花板 200，大促直接雪崩——拆分为 8 个微服务部署到 ACK 后，单服务 QPS 提升 10 倍，整体系统可用性从 99.5% 提升到 99.99%。本文以一个真实的中型电商平台为案例，完整演示从单体到云原生微服务的全链路搭建：ACK 集群规划、Spring Cloud Alibaba 全家桶集成（Nacos + Sentinel + Seata + Gateway + OpenFeign）、K8s 部署实战（Helm + HPA + 金丝雀发布）、可观测性建设（ARMS + SLS + Prometheus），以及 5 个生产级踩坑实录和最佳实践。

1. 场景：单体崩了，微服务来救

2025 年初，我负责的一个中型电商平台（日均订单 10 万+）在年货节大促时遭遇了严重故障。系统是一个典型的 Spring Boot 单体应用，所有业务模块打包在一个 JAR 里部署到 4 台 ECS。

大促当天流量飙升 8 倍，单体应用 QPS 天花板只有 200，数据库连接池瞬间耗尽，线程阻塞导致服务雪崩，全站不可用 47 分钟，直接损失超过 80 万。

痛定思痛，我们决定将系统拆分为 8 个微服务，部署到阿里云 ACK（容器服务 Kubernetes 版），并引入 Spring Cloud Alibaba 全家桶实现服务治理。改造后的成果：

下面我把这次从 0 到 1 的全链路搭建过程完整分享出来。

2. 架构全景

2.1 整体架构

2.2 技术选型清单

3. ACK 集群搭建

3.1 托管版 vs 专有版

为什么选托管版？因为我们的团队只有 2 个运维，不想花精力维护 Master 节点。托管版 Master 由阿里云托管，我们只需关注 Worker 节点。

我们的选择：托管版，3 个 Worker 节点起步。

3.2 节点池规划

为什么分节点池？因为不同服务对资源的需求差异大，混部会导致资源浪费和互相干扰。

# 节点池规划 — 按服务类型分离
nodePools:
  - name: core-pool          # 核心服务池
    instanceType: ecs.c6.2xlarge    # 8核16G
    count: 3
    labels:
      service-type: core
    taints: [ ]

  - name: search-pool        # 搜索服务池（内存密集）
    instanceType: ecs.r6.2xlarge    # 8核64G
    count: 2
    labels:
      service-type: search
    taints:
      - key: dedicated
        value: search
        effect: NoSchedule

  - name: worker-pool        # 后台任务池
    instanceType: ecs.g6.xlarge     # 4核16G
    count: 2
    labels:
      service-type: worker

3.3 网络方案：Flannel vs Terway

Terway 是阿里云容器网络 CNI，Pod 直接使用 VPC IP，网络性能更优。

我们的选择：Terway，支持 NetworkPolicy，网络性能更优。

3.4 存储类选择

# StorageClass — 按场景选择存储
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alicloud-disk-ssd
provisioner: disk.csi.alibabacloud.com
parameters:
  type: cloud_ssd
  regionId: cn-hangzhou
reclaimPolicy: Retain     # 生产环境必须 Retain
allowVolumeExpansion: true

4. Spring Cloud Alibaba 全链路集成

4.1 版本兼容矩阵

Spring Cloud Alibaba 的版本兼容是第一个坑，版本不匹配会出现各种莫名其妙的报错。

我们的选择：Spring Boot 3.2.x + Spring Cloud 2023.0.x + Spring Cloud Alibaba 2023.0.1.0。

4.2 Nacos：服务注册 + 配置中心

命名空间 / Group / DataId 规划

为什么做三级隔离？因为多环境 + 多服务 + 多配置类型，不做隔离配置会混乱不堪。

# Nacos 命名空间规划
namespaces:
  - id: dev
    name: 开发环境
  - id: test
    name: 测试环境
  - id: staging
    name: 预发环境
  - id: prod
    name: 生产环境

服务注册配置

# application.yml — Nacos 服务注册
spring:
  application:
    name: order-service
  cloud:
    nacos:
      discovery:
        server-addr: mse-xxxxx-nacos.mse.aliyuncs.com:8848
        namespace: prod
        group: TRADE_GROUP
        cluster-name: HZ           # 同机房优先
        weight: 1                  # 权重
        metadata: # 自定义元数据
          version: v2
          region: cn-hangzhou
      config:
        server-addr: ${
   spring.cloud.nacos.discovery.server-addr}
        namespace: ${
   spring.cloud.nacos.discovery.namespace}
        group: ${
   spring.cloud.nacos.discovery.group}
        file-extension: yaml
        shared-configs: # 共享配置
          - data-id: common-db.yaml
            group: SHARED_GROUP
            refresh: true
          - data-id: common-redis.yaml
            group: SHARED_GROUP
            refresh: true

灰度发布配置

为什么用元数据做灰度？因为 Nacos 原生不支持灰度路由，需要结合元数据 + Ribbon/LoadBalancer 实现流量染色。

# Nacos 配置中心 — 灰度规则配置
# DataId: gray-rule.yaml
# Group: TRADE_GROUP
gray:
  enabled: true
  rules:
    - service: order-service
      gray-version: v2
      match:
        header:
          X-Gray-Tag: gray-v2     # 请求头携带灰度标
      weight: 10                   # 10% 流量到 v2

4.3 Gateway：路由 + 限流 + 熔断

为什么用 Spring Cloud Gateway 而不是 Zuul？因为 Gateway 基于 WebFlux 响应式模型，吞吐量是 Zuul 的 1.5 倍，且与 Sentinel 原生集成。

路由配置

# application.yml — Gateway 路由规则
spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service     # lb:// 表示从 Nacos 获取实例
          predicates:
            - Path=/api/order/**
          filters:
            - StripPrefix=1
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 100
                redis-rate-limiter.burstCapacity: 200
                key-resolver: "#{@userKeyResolver}"

        - id: product-service
          uri: lb://product-service
          predicates:
            - Path=/api/product/**
          filters:
            - StripPrefix=1

Sentinel 集成限流

// GatewaySentinelConfig.java — 自定义限流降级处理
@Configuration
public class GatewaySentinelConfig {
   

    @PostConstruct
    public void init() {
   
        // 自定义限流降级响应
        GatewayCallbackManager.setBlockHandler((exchange, t) -> {
   
            Map<String, Object> result = new HashMap<>();
            result.put("code", 429);
            result.put("message", "系统繁忙，请稍后重试");
            return ServerResponse.status(HttpStatus.TOO_MANY_REQUESTS)
                    .contentType(MediaType.APPLICATION_JSON)
                    .body(BodyInserters.fromValue(result));
        });
    }
}

4.4 Sentinel：流控 + 熔断 + 热点 + 系统保护

核心规则配置

// Sentinel 流控规则 — 推送到 Nacos 持久化
[
  {
   
    "resource": "POST:/api/order/create",
    "limitApp": "default",
    "grade": 1,
    "count": 500,
    "strategy": 0,
    "controlBehavior": 2,
    "clusterMode": false
  }
]

Nacos 规则持久化

为什么持久化？因为 Sentinel 默认规则在内存中，Pod 重启后规则丢失。推送到 Nacos 后，规则实时同步到所有实例。

# application.yml — Sentinel Nacos 数据源
spring:
  cloud:
    sentinel:
      datasource:
        flow:
          nacos:
            server-addr: ${
   spring.cloud.nacos.config.server-addr}
            namespace: ${
   spring.cloud.nacos.config.namespace}
            group-id: SENTINEL_GROUP
            data-id: ${
   spring.application.name}-flow-rules
            rule-type: flow
        degrade:
          nacos:
            server-addr: ${
   spring.cloud.nacos.config.server-addr}
            namespace: ${
   spring.cloud.nacos.config.namespace}
            group-id: SENTINEL_GROUP
            data-id: ${
   spring.application.name}-degrade-rules
            rule-type: degrade

4.5 Seata：分布式事务

AT 模式接入

为什么选 AT 模式？因为 AT 模式对业务代码侵入最小，只需要加 @GlobalTransactional 注解。相比 TCC 需要写三个方法（Try/Confirm/Cancel），AT 模式自动生成回滚 SQL。

// OrderServiceImpl.java — 下单分布式事务
@Service
public class OrderServiceImpl implements OrderService {
   

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private InventoryClient inventoryClient;

    @Autowired
    private AccountClient accountClient;

    @Override
    @GlobalTransactional(name = "create-order", rollbackFor = Exception.class)
    public OrderDTO createOrder(CreateOrderRequest request) {
   
        // 1. 创建订单
        Order order = new Order();
        order.setUserId(request.getUserId());
        order.setProductId(request.getProductId());
        order.setAmount(request.getAmount());
        order.setStatus(OrderStatus.INIT);
        orderMapper.insert(order);

        // 2. 扣减库存（远程调用）
        inventoryClient.deduct(request.getProductId(), request.getQuantity());

        // 3. 扣减余额（远程调用）
        accountClient.debit(request.getUserId(), request.getAmount());

        // 4. 更新订单状态
        order.setStatus(OrderStatus.CREATED);
        orderMapper.updateById(order);

        return OrderConverter.toDTO(order);
    }
}

Seata 全局锁与性能优化

全局锁是 AT 模式的核心机制，保证分支事务提交前，相关行数据不被其他全局事务修改。

# application.yml — Seata 性能调优配置
seata:
  client:
    undo:
      log-serialization: jackson    # undo log 序列化方式
      only-care-update-columns: true # 只记录变更列，减少 undo log 大小
    tm:
      commit-retry-count: 3         # 提交失败重试次数
      rollback-retry-count: 3       # 回滚失败重试次数
    rm:
      async-commit-buffer-limit: 10000  # 异步提交缓冲区
      report-retry-count: 5
      table-meta-check-enable: true
      report-success-enable: false  # 成功不上报，减少通信开销
      lock-retry-times: 30          # 全局锁重试次数
      lock-retry-interval: 10       # 全局锁重试间隔 ms

4.6 OpenFeign：服务间调用 + 熔断降级

// InventoryClient.java — Feign 客户端 + Sentinel 熔断
@FeignClient(
    name = "inventory-service",
    fallbackFactory = InventoryFallbackFactory.class
)
public interface InventoryClient {
   

    @PostMapping("/api/inventory/deduct")
    Result<Void> deduct(@RequestParam("productId") Long productId,
                        @RequestParam("quantity") Integer quantity);
}

// InventoryFallbackFactory.java — 降级工厂
@Component
@Slf4j
public class InventoryFallbackFactory implements FallbackFactory<InventoryClient> {
   

    @Override
    public InventoryClient create(Throwable cause) {
   
        log.error("库存服务调用失败，触发降级", cause);
        return (productId, quantity) -> {
   
            // 降级策略：记录扣减请求到本地表，后续补偿
            return Result.fail("库存服务暂时不可用，请稍后重试");
        };
    }
}

# application.yml — OpenFeign 超时与 Sentinel 集成
feign:
  sentinel:
    enabled: true                   # 启用 Sentinel 熔断
  client:
    config:
      default:
        connect-timeout: 3000       # 连接超时 3s
        read-timeout: 5000          # 读取超时 5s
      inventory-service: # 特定服务单独配置
        connect-timeout: 2000
        read-timeout: 3000          # 库存服务要求更快响应

4.7 Sleuth + ARMS：分布式链路追踪

为什么用 ARMS 而不自建 SkyWalking？因为 ARMS 在 ACK 上免安装 Agent，一条命令就能接入，省去了运维 SkyWalking 集群的精力。

# application.yml — Sleuth 采样配置
spring:
  sleuth:
    sampler:
      probability: 0.1              # 生产环境 10% 采样率
    web:
      skip-pattern: /actuator.*,/health

ARMS 接入方式：在 ACK 集群中安装 arms-prometheus 组件，Pod 自动注入探针。

# 安装 ARMS Prometheus 组件
aliyun cs GET /k8s/<cluster-id>/addons/arms-prometheus

5. K8s 部署实战

5.1 Dockerfile 多阶段构建

为什么用多阶段构建？因为直接用 Maven 镜像打出来的镜像有 600MB+，多阶段构建后只有 150MB 左右，启动更快、攻击面更小。

# Dockerfile — 多阶段构建
# 阶段一：构建
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -B          # 依赖缓存层
COPY src ./src
RUN mvn package -DskipTests -B

# 阶段二：运行
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar

# 安全：非 root 用户运行
RUN addgroup -S app && adduser -S app -G app
USER app

EXPOSE 8080
ENTRYPOINT ["java", \
    "-XX:+UseG1GC", \
    "-XX:MaxRAMPercentage=75.0", \
    "-jar", "app.jar"]

5.2 Helm Chart 模板化

为什么用 Helm？因为 8 个微服务的 K8s YAML 配置大量重复，Helm 模板化后一份 Chart 复用多环境。

# Chart.yaml
apiVersion: v2
name: order-service
description: 订单服务 Helm Chart
type: application
version: 1.0.0
appVersion: "2.0.0"

# templates/deployment.yaml — 关键部分
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {
    {
    include "order-service.fullname" . } }
  labels:
    {
    {
    - include "order-service.labels" . | nindent 4 } }
spec:
  replicas: {
    {
    .Values.replicaCount } }
  selector:
    matchLabels:
      {
    {
    - include "order-service.selectorLabels" . | nindent 6 } }
  template:
    metadata:
      labels:
        {
    {
    - include "order-service.selectorLabels" . | nindent 8 } }
    spec:
      containers:
        - name: {
    {
    .Chart.Name } }
          image: "{
   { .Values.image.repository }}:{
   { .Values.image.tag }}"
          ports:
            - containerPort: 8080
          resources:
            {
    {
    - toYaml .Values.resources | nindent 12 } }
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            initialDelaySeconds: 60
            periodSeconds: 15
          env:
            - name: NACOS_NAMESPACE
              value: {
    {
    .Values.nacos.namespace | quote } }
            - name: SPRING_PROFILES_ACTIVE
              value: {
    {
    .Values.spring.profiles | quote } }

# values-prod.yaml — 生产环境配置
replicaCount: 3

image:
  repository: registry-cn-hangzhou.ack.aliyuncs.com/ecommerce/order-service
  tag: "2.0.0"
  pullPolicy: IfNotPresent

resources:
  requests:
    cpu: "500m"
    memory: "1024Mi"
  limits:
    cpu: "2000m"
    memory: "2048Mi"

nacos:
  namespace: prod

spring:
  profiles: prod

autoscaling:
  enabled: true
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

5.3 HPA 弹性伸缩

为什么用 HPA？因为大促流量不可预测，手动扩容来不及。HPA 根据 CPU / 自定义指标自动扩缩容。

# hpa.yaml — CPU + 自定义指标双驱动
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3
  maxReplicas: 15
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "500"
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Pods
          value: 3
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

5.4 滚动更新 + 金丝雀发布

滚动更新配置

# deployment.yaml — 滚动更新策略
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1             # 每次多启动 1 个 Pod
      maxUnavailable: 0       # 不允许有 Pod 不可用

金丝雀发布（基于 Argo Rollouts）

为什么需要金丝雀？因为滚动更新是全量渐进，无法精准控制灰度比例。金丝雀发布可以将 5% 流量导入新版本，观察无异常后再逐步放量。

# rollout.yaml — Argo Rollouts 金丝雀发布
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: order-service
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        - setWeight: 5           # 5% 流量到新版本
        - pause: {
    duration: 5m } # 观察 5 分钟
        - setWeight: 20
        - pause: {
    duration: 5m }
        - setWeight: 50
        - pause: {
    duration: 3m }
        - setWeight: 100         # 全量发布
      canaryService: order-service-canary
      stableService: order-service-stable

5.5 ConfigMap / Secret 配置管理

# configmap.yaml — 非敏感配置
apiVersion: v1
kind: ConfigMap
metadata:
  name: order-service-config
data:
  NACOS_SERVER_ADDR: "mse-xxxxx-nacos.mse.aliyuncs.com:8848"
  NACOS_NAMESPACE: "prod"
  LOG_LEVEL: "INFO"
  JAVA_OPTS: "-XX:+UseG1GC -XX:MaxRAMPercentage=75.0"

# secret.yaml — 敏感配置（必须加密）
apiVersion: v1
kind: Secret
metadata:
  name: order-service-secret
type: Opaque
stringData:
  DB_PASSWORD: "xxxxxx"           # 生产环境用 ACK 加密密钥
  REDIS_PASSWORD: "xxxxxx"
  NACOS_ACCESS_KEY: "xxxxxx"

安全提醒：生产环境禁止将 Secret 明文提交到 Git，必须使用阿里云 KMS（密钥管理服务）加密，或通过 ACK 的加密配置功能管理。

6. 可观测性建设

6.1 可观测性架构

6.2 ARMS APM 接入

ARMS 应用监控在 ACK 上接入只需要两步：安装组件 + 添加注解。

# 步骤一：安装 ARMS Prometheus 组件
aliyun cs GET /k8s/<cluster-id>/addons/arms-prometheus

# 步骤二：在 Deployment 上添加注解

# 只需加一个注解，ARMS 自动注入 Agent
template:
  metadata:
    annotations:
      armsPilotAutoEnable: "on"
      armsPilotCreateAppName: "order-service"

6.3 SLS 日志采集

为什么用 iLogtail 而不是 Filebeat？因为 iLogtail 是阿里云自研的日志采集 Agent，在 ACK 上原生集成，资源占用是 Filebeat 的 1/5，采集延迟 < 3s。

# iLogtail 采集配置
apiVersion: log.alibabacloud.com/v1alpha1
kind: AliyunLogConfig
metadata:
  name: order-service-log
spec:
  project:
    name: ecom-prod-logs
  logstore:
    name: order-service
    ttl: 30                        # 日志保留 30 天
    shardCount: 3
  logtailConfig:
    inputType: file
    inputDetail:
      logType: common_reg_log
      logPath: /app/logs/
      filePattern: "*.log"
      regex: '^\[(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3})\]\s+\[(\w+)\]\s+\[(\w+)\]\s+(.*)$'
      timeFormat: "%Y-%m-%d %H:%M:%S"

6.4 Prometheus + Grafana 看板

关键监控指标和告警阈值：

7. 量化对比：单体 vs 微服务

7.1 测试环境

7.2 六维度对比数据

7.3 压测结果详情

8. 踩坑实录

坑 1：Nacos 注册中心雪崩

现象：大促期间，Nacos 控制台显示 8 个微服务全部下线，但实际进程正常。服务间调用报 No available server。

排查过程：

1. 查 Nacos 日志：大量 client disconnect 告警
2. 查应用日志：心跳线程阻塞在 HTTP 调用上
3. 定位根因：Nacos 1.x 使用 HTTP 短连接做心跳，高并发下连接池耗尽导致心跳超时

解决方案：

• 升级到 Nacos 2.x（gRPC 长连接，心跳性能提升 10 倍）
• 切换到 MSE Nacos 托管版，3 节点集群 + SLB
• 调整心跳超时参数

# 心跳超时参数调整
spring:
  cloud:
    nacos:
      discovery:
        heart-beat-interval: 5000     # 心跳间隔 5s
        heart-beat-timeout: 15000     # 心跳超时 15s
        ip-delete-timeout: 30000      # IP 删除超时 30s

坑 2：Seata 全局锁死锁

现象：下单接口偶发超时，ARMS 链路显示卡在 lock retry 阶段，耗时 20s+。

排查过程：

1. 查 Seata Server 日志：大量 global lock conflict 报错
2. 分析业务逻辑：下单和退款两个全局事务同时操作同一商品库存行
3. 定位根因：AT 模式全局锁粒度为行锁，并发操作同一行会互相等待

解决方案：

• 缩小事务范围：将库存扣减拆分为"预扣 + 确认"，预扣走 Redis，确认走数据库
• 调整全局锁重试策略

# 全局锁优化配置
seata:
  client:
    rm:
      lock-retry-times: 10          # 降低重试次数（原 30）
      lock-retry-interval: 5        # 缩短重试间隔（原 10ms）
      async-commit-buffer-limit: 5000

坑 3：Gateway 限流不生效

现象：配置了 Sentinel 限流规则，但压测时接口 QPS 远超阈值，限流完全没生效。

排查过程：

1. 查 Sentinel Dashboard：规则确实推送到 Gateway
2. 查 Gateway 日志：请求未经过 Sentinel Filter
3. 定位根因：Gateway 路由的 uri 写成了 http:// 而不是 lb://，请求绕过了 Sentinel Filter Chain

解决方案：

• 修正路由 URI 为 lb:// 协议
• 确认 spring-cloud-alibaba-sentinel-gateway 依赖正确引入

<!-- 必须引入 Gateway 专属 Sentinel 依赖 -->
<dependency>
  <groupId>com.alibaba.cloud</groupId>
  <artifactId>spring-cloud-alibaba-sentinel-gateway</artifactId>
</dependency>
  <!-- 注意：不能引入普通的 sentinel-web 依赖，会冲突 -->

坑 4：HPA 指标延迟导致扩容不及时

现象：大促流量突增时，HPA 扩容延迟 3-5 分钟，新 Pod 起来时流量已经回落。

排查过程：

1. 查看 HPA Events：the HPA was unable to compute the replica count
2. 查 Prometheus 指标：metrics-server 采集间隔 60s，指标延迟 90s
3. 定位根因：metrics-server 默认采集间隔太长 + Pod 启动耗时 40s

解决方案：

• 缩短 metrics-server 采集间隔
• 优化 Pod 启动速度（延迟初始化 + 并行加载）
• 增加缓冲副本数

# metrics-server 加速采集
apiVersion: apps/v1
kind: Deployment
metadata:
  name: metrics-server
spec:
  template:
    spec:
      containers:
        - name: metrics-server
          args:
            - --metric-resolution=15s       # 采集间隔从 60s 改为 15s
            - --kubelet-preferred-address-types=InternalIP

# HPA 增加缓冲
spec:
  minReplicas: 4               # 最低 4 副本（原 3），留 1 个缓冲
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0    # 扩容无需稳定窗口
      policies:
        - type: Percent
          value: 100                    # 一次性翻倍扩容
          periodSeconds: 30

坑 5：Pod 启动慢导致就绪探针超时

现象：新 Pod 启动后反复重启，Events 显示 Readiness probe failed。

排查过程：

1. 查看 Pod 日志：Spring Boot 启动耗时 55s
2. 分析启动瓶颈：Nacos 配置拉取 10s + Bean 初始化 30s + 数据库连接 15s
3. 定位根因：就绪探针 initialDelaySeconds 设为 30s，但实际启动需要 55s

解决方案：

• 优化启动速度：懒加载非核心 Bean
• 调整探针参数

# 优化后的探针配置
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  initialDelaySeconds: 10      # 缩短初始等待
  periodSeconds: 5             # 缩短检测间隔
  failureThreshold: 12         # 允许 60s（5s×12）启动时间
livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  initialDelaySeconds: 90      # 活性探针延迟长一些，避免误杀
  periodSeconds: 15
  failureThreshold: 3

// 懒加载非核心 Bean — 加速启动
@Configuration
public class LazyConfig {
   

    @Bean
    @Lazy                           // 非核心 Bean 懒加载
    public SomeHeavyService someHeavyService() {
   
        return new SomeHeavyService();
    }
}

9. 最佳实践

9.1 微服务拆分决策树

拆分三条铁律：

1. 团队规模不到 5 人，不要拆
2. 业务边界不清晰，不要拆
3. 没有明确的性能/发布瓶颈，不要拆

9.2 ACK 部署检查清单

9.3 Spring Cloud Alibaba 版本兼容速查表

版本选择原则：

• 新项目直接上 2023.0.x + Spring Boot 3.2.x
• 老项目升级先确认 Spring Boot 2.7.x → 3.x 的 Breaking Changes
• Nacos Client 版本必须与 Nacos Server 版本匹配（2.x Client 连 2.x Server）

10. 总结

从单体到云原生微服务，不仅仅是技术架构的升级，更是团队研发模式的变革。本文以一个真实的电商平台改造项目为线索，覆盖了从 ACK 集群搭建到 Spring Cloud Alibaba 全链路集成的完整路径。

三个核心建议：

1. 先拆好再上云：微服务拆分质量决定上云效果，业务边界不清的拆分会带来更多问题
2. 可观测性先行：没有 ARMS + SLS + Prometheus 的微服务就是黑盒，出问题连排查方向都没有
3. 弹性能力是核心：ACK + HPA 的弹性伸缩是云原生最大的红利，务必把指标体系和扩缩策略调好

📜 真实性声明

本文所有内容均基于作者在 2025 年期间参与的一个中型电商平台微服务改造项目中的真实经验。所有案例、数据、代码均来自生产环境或测试环境验证，经过实践检验。为保护商业机密，部分敏感信息已做脱敏处理，但技术细节保持完整和真实。

如有任何疑问，欢迎在评论区交流讨论。