微服务弹性伸缩实战：如何让系统自动应对流量波动

最近公司上线了一个促销活动，早上一开抢，系统直接卡死。运维同事急得满头大汗，后来才发现是某个微服务实例不够用，扛不住瞬间涌进来的请求。这种场景其实很常见，比如双十一大促、秒杀活动，甚至一个爆款文章突然被转发到朋友圈，都可能让服务崩掉。

后来我们上了弹性伸缩，情况立马好转。简单说，弹性伸缩就是系统能根据当前负载自动增减服务实例数量。平时跑两个实例就够了，流量一来，自动拉起五个、十个，等高峰期过了再缩回去，既省钱又稳定。

怎么实现弹性伸缩？

我们用的是 Kubernetes + Prometheus + Horizontal Pod Autoscaler（HPA）。K8s 负责管理容器，Prometheus 收集 CPU、内存、请求延迟这些指标，HPA 根据设定的阈值决定要不要扩容。

比如我们给订单服务设了个规则：CPU 使用率超过 70% 持续一分钟，就自动增加实例。配置文件长这样：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

上线之后，有次半夜用户突增，监控显示实例从2个自动扩到8个，早上一看日志，服务一点没挂，请求全处理完了。这种“无人值守”式的稳定性，真的省心不少。

别只盯着CPU

刚开始我们只看CPU，结果发现有些服务CPU不高，但请求队列积压严重。比如短信通知服务，处理的是异步任务，CPU占用低，但消息堆积时响应特别慢。后来改成了基于消息队列长度触发扩容。

用的是 KEDA（Kubernetes Event Driven Autoscaling），它支持从 RabbitMQ、Kafka 这些中间件读取消息数量，动态调整 Pod 数量。配置也不复杂：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sms-worker-scale
spec:
  scaleTargetRef:
    name: sms-worker
  triggers:
  - type: rabbitmq
    metadata:
      host: amqp://guest:guest@rabbitmq.default.svc.cluster.local/
      queueName: sms.queue
      mode: QueueLength
      value: '10'

意思是队列里每积压10条消息，就加一个实例。实测下来，短信发送延迟从几分钟降到几秒。

弹性伸缩不是一配就灵，得结合业务特点调参数。比如冷启动时间长的服务，扩容得提前一点；缩容也不能太激进，不然刚缩完又涨起来，来回震荡。我们还加了延迟缩容策略，高峰期过后等五分钟再逐步回收实例。

现在每次搞活动前，再也不用全员待命盯屏幕了。系统自己会“呼吸”，忙时扩张，闲时收缩。技术不就是为了让人更轻松吗？

微服务弹性伸缩：应对流量高峰的实战经验

怎么实现弹性伸缩？

别只盯着CPU