跳转到主要内容
在云原生时代，借助云厂商提供的节点弹性能力，我们已经能够很好的对一个线上集群完成节点级别的扩缩容，如 AWS 的 Auto Scaling Groups[1]、阿里云的 ESS 弹性伸缩组[2]，但是由于涉及到业务流量的迁移，Apache Kafka 集群往往无法直接应用云厂商提供的弹性能力，而需要运维人员介入手动进行流量的腾挪，耗时通常在小时级别，这对于流量频繁变化的线上集群来说，几乎不可能做到按需扩缩容，为了保障集群的稳定性，运维人员只能选择提前按照最大容量部署，避免流量峰值来临时临时扩容不及时产生的风险，而这也导致了大量的资源浪费。

​
AutoMQ 如何实现秒级的平滑扩缩容

AutoMQ 秒级扩缩容的特性依赖一个原子能力，即秒级分区迁移（参考秒级分区迁移▸）。 当借助弹性伸缩组 ASG 或者 Kubernetes 的 HPA[3] 完成了节点的扩容后，这时仅需要将集群中的部分分区批量地迁移至新节点，即可完成流量的重平衡（参考持续数据自平衡▸），这往往能在十秒级完成。

​
触发扩容

以 AWS Auto Scaling Groups (ASG) 为例，通过配置流量阈值监控，当集群流量触及扩容阈值时，自动拉起新的 Broker 节点，此时 Controller 检测到流量存在不均衡，自动将分区移动至新创建的 Broker，完成流量的重新负载。 下图展示了一个 AutoMQ Kafka 集群的 Broker 数量随流量上涨发生的变化，可以看到随着流量的线性上升，Broker 被动态创建并加入集群平衡负载。 下图展示了流量上涨过程中，各 Broker 节点的流量变化，可以看到新创建的 Broker 均在十秒级完成了流量的重新负载。

​
触发缩容

仍以 AWS Auto Scaling Groups 为例，当集群流量触及缩容阈值时，对即将缩容的 Broker 节点进行下线操作，此时该 Broker 上的分区将以 Round-Robin 方式在秒级内迁移至剩余 Broker 上，完成 Broker 的优雅下线及流量转移。 下图展示了一个 AutoMQ Kafka 集群的 Broker 数量随流量下降发生的变化，可以看到随着流量的线性下降，Broker 被动态下线节约资源。 下图展示了流量下降过程中，各 Broker 节点的流量变化，可以看到下线中的 Broker 的负载被转移到其余 Broker 上（每当 Broker 下线时，可观察到其余 Broker 流量有显著上升）。
在上述示例中，为便于观察，人为增加了 ASG 的节点扩缩容冷却时间，并增加了进程启动和销毁延迟

​
自动扩缩容的优势

AutoMQ 的共享存储架构，天然支持快速自动扩缩容，也是实现 Serverless 的基础。AutoMQ 支持自动扩缩容后至少带来以下几个优势：
  • 成本优势，无需按峰值准备资源，根据业务流量自动伸缩，有效应对潮汐型和突发型业务，按使用面积付费，无闲置资源浪费。
  • 稳定性优势，扩容无损，不会对集群产生额外的流量压力，可以在高水位的状态下进行无损扩容。相反，Apache Kafka 的扩容是一个高风险操作，只能在低水位的情况下进行扩容。
  • 多租户优势，具备自动扩缩容能力的集群，不在需要通过将业务混部来提高资源的利用率，完全可以为每个业务配置一个独立的集群。每个独立的集群根据自身的流量模型独立扩展即可。既保障了成本优势，又避免了某个业务出问题时带来全局的影响。

​
引用

[1]. AWS Auto Scaling Groups: https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html [2]. 阿里云 ESS 弹性伸缩组：https://www.aliyun.com/product/ecs/ess [3]. Kubernetes 用于扩容的 HPA 组件：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
⌘I