引言
得物作为全球领先的潮流网购社区，日益增长的用户和数据带来了巨大的技术挑战。当前，得物的可观测性平台每天生成数PB级Trace数据和数万亿条Span记录，要求平台具备高效的实时处理能力和低成本的数据存储解决方案。
传统的存算一体架构将计算与存储资源绑定，随着数据规模的扩大，暴露出了以下问题：
-
扩展性受限：存算资源无法独立扩展，导致计算和存储的扩容必须同步，进而提升了成本。
-
资源利用率低：计算与存储资源无法按需动态调整，造成闲置资源浪费。
-
运维复杂性高：集群扩展和缩容涉及复杂的资源迁移，增加了运维难度。
为了有效解决这些问题，得物可观测性平台采用了存算分离架构，结合AutoMQ和Kafka以及ClickHouse存储技术，实现了高效的资源管理和性能优化。
Apache Kafka在大规模数据下的挑战
Apache Kafka处于得物观测业务的核心数据链路中
在得物的可观测性平台中，Apache Kafka被广泛用于数据收集、加工和分发。然而，随着业务数据量的不断增长，Kafka的架构暴露出以下问题：
-
存储成本高：Kafka的存储部分占据了大部分（计算与存储成本比例为1:3）云资源开销，为了控制成本，得物调整了Kafka的数据TTL和副本配置，但存储成本仍居高不下。
-
冷读效率低：冷读场景下，磁盘吞吐量常达到上限，导致性能瓶颈。
得物 Kafka 磁盘高危报警
- 运维复杂性高：随着集群规模的扩大，Kafka集群的扩缩容操作变得更加复杂，面临较高的运维风险。
这些问题源于Kafka原生架构的局限性，特别是其面向IDC环境的Shared-Nothing架构，难以充分发挥云计算时代对弹性和扩展性的要求。
为什么选择AutoMQ
AutoMQ云原生架构
为了解决Kafka在大规模数据处理中的问题，得物可观测性平台选择了AutoMQ作为替代方案。AutoMQ的优势包括：
-
100%兼容Kafka协议：AutoMQ完全兼容Kafka客户端和生态工具，迁移过程顺畅，避免了大规模改造。
-
存算分离架构：存储与计算解耦，AutoMQ基于对象存储和EBS存储研发了共享流存储库S3Stream[1]，并通过S3Stream替换了Apache Kafka的整个存储层，大幅降低存储成本，同时支持存储与计算的独立扩展。
-
弹性扩缩容能力：支持动态资源调整，无需数据迁移或停机，提升资源利用率。
-
未来扩展性：支持大规模数据量增长，能够与现代存储和计算工具无缝集成，满足长期需求。
AutoMQ面向冷读场景的性能优化
在冷读场景下，Apache Kafka的性能问题十分明显。KAFKA-7504[2]问题导致冷读操作影响实时写入，严重时会降低整个集群的吞吐量。AutoMQ通过以下方式优化了这一问题：
-
对象存储与计算分离：存储与计算的彻底分离避免了冷读对写入性能的影响。
-
高效查询性能：AutoMQ对查询操作进行了优化，即使在高并发场景下，冷读性能保持稳定。
Apache Kafka的读写 IO链路
Apache Kafka的读写链路引入了两个关键的技术：Page Cache[3]和零拷贝SendFile[4]系统调用。
-
Page Cache极大地简化了Kafka内存管理的负担，完全由内核来负责。但存在冷热无法分离的问题，如果有业务持续在冷读，会跟热数据互相争抢内存资源，导致追尾读能力持续下降。
-
SendFile是Kafka零拷贝的关键技术，但该调用行为发生在Kafka的网络线程池，如果执行SendFile时需要从磁盘上拷贝数据（冷读场景），会在一定程度上阻塞该线程池。又因为该线程池是处理Kafka请求的入口，包括写请求，SendFile的阻塞行为将导致Kafka的写入受到巨大的影响。
在相同负载和机型下相比Kafka，AutoMQ冷读时可以保证不影响写入吞吐和延迟的情况下，拥有和Kafka相同水准的冷读性能[5]。
在冷读场景下，AutoMQ显著提升了性能，与Kafka相比，冷读效率提升了约5倍，且对实时写入没有任何影响。
AutoMQ基于共享存储架构的快速弹性能力
得物可观测性平台的业务流量呈现明显的峰谷波动，AutoMQ通过存算分离架构实现了卓越的弹性扩缩容能力：
-
快速扩容：在业务高峰期，能够迅速扩展存储或计算资源，保障系统性能。
-
智能缩容：高峰过后，快速回收闲置资源，避免浪费并降低运维负担。
AutoMQ的扩缩容依赖秒级分区迁移技术[6]。在扩容时，借助弹性伸缩组（ASG）[7]或Kubernetes HPA，分区可以批量迁移到新节点，确保流量快速平衡，通常在十秒内完成。缩容时，待下线节点的分区会迅速迁移至其他节点，完成秒级下线。与Apache Kafka需要通过复制数据进行扩缩容不同，AutoMQ利用共享存储架构避免了数据复制，显著提高了扩缩容效率，避免了数据重平衡[9]，跟Apache Kafka的实现有巨大的区别。
AutoMQ自动流量重平衡 vs. Apache Kafka手动迁移
案例
AutoMQ通过监控集群流量和CPU等指标，自动进行扩缩容。当流量达到扩容阈值时，系统会自动增加Broker节点；当流量下降至缩容阈值时，系统会优雅地将即将下线的Broker上的分区以Round-Robin方式秒级迁移至其他Broker，完成流量平衡。
AutoMQ落地效果：千核资源替换，成本下降50%
AutoMQ在得物可观测性平台上线半年以来，逐步替换了整个可观测性架构对Apache Kafka的依赖，基于AutoMQ的整体可观测架构如下图所示，AutoMQ集群承担了所有微服务业务的产生的观测数据，并基于ClickHouse进一步提供点查和观测数据分析的能力。
得物基于AutoMQ的可观测架构
AutoMQ也为得物可观测性平台带来了以下显著的成效：
-
云账单成本同比**下降50%**以上，同时运维效率大幅度提升。
-
完成近千核计算资源替换，总体吞吐高达数十GiB/s。
AutoMQ落地效果：平稳支撑得物双十一期间100%流量
除了成本大幅度降低之外，今年通过AutoMQ的架构支撑得物双十一，避免了过往双十一前繁重的容量评估工作，以及提前扩容的运维成本。AutoMQ集群上线以来，以及双十一期间全程保持高可用，零宕机 ，支撑了双十一期间**100%**的流量，且高峰期负载平稳，无性能抖动。如下图是得物可观测性平台AutoMQ集群中其中一个GiB级吞吐的集群。
得物其中的一个AutoMQ GiB级集群
总结
得物通过引入AutoMQ，成功解决了Apache Kafka在大规模数据处理中的诸多挑战。在实际应用中，AutoMQ在得物可观测性平台表现出了显著的优势，不仅降低了系统的存储和计算成本，而且大幅度提升了资源利用率和运维效率。得物可观测性平台借助AutoMQ的存算分离架构，克服了Kafka在扩展性、存储成本和运维复杂性上的局限性，实现了动态资源调整和高效的冷读优化。在双十一高峰期，AutoMQ的卓越性能和弹性扩缩容能力保证了系统的高可用性和稳定性，无需额外进行繁重的容量评估和提前扩容操作。这一技术实践为得物带来了显著的成本节约和性能提升，成为其面对未来数据爆发增长的坚实基础。同时也为其他企业在高效资源管理和性能优化方面提供了宝贵的经验与解决方案。
引用
[1]AutoMQ基于S3的共享流存储库：https://docs.automq.com/zh/automq/architecture/s3stream-shared-streaming-storage/overview
[2]Kafka冷读性能问题来源：https://issues.apache.org/jira/browse/KAFKA-7504
[3]Linux Page Cache: https://en.wikipedia.org/wiki/Page\_cache
[4]Linux SendFile: https://man7.org/linux/man-pages/man2/sendfile.2.html
[5]AutoMQ性能白皮书：https://docs.automq.com/zh/automq/benchmarks/benchmark-automq-vs-apache-kafka
[6]AutoMQ秒级分区迁移：https://docs.automq.com/zh/automq/architecture/technical-advantage/partition-reassignment-in-seconds
[7]AWS Auto Scaling Groups: https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html
[8]Kubernetes用于扩容的 HPA 组件：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
[9]AutoMQ持续数据自平衡：https://docs.automq.com/zh/automq/architecture/technical-advantage/continuous-self-balancing