秒级平滑扩缩容
在云原生时代，借助云厂商提供的节点弹性能力，我们已经能够很好的对一个线上集群完成节点级别的扩缩容，如 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/