在本次技术深度分享中，将围绕AutoMQ关于云原生设计的理念、AutoMQ的云原生架构、AutoMQ相对于原生的Apache、Kafka在技术和产品上的优势及基于云存储技术、产品的创新展望四个板块进行介绍，揭秘AutoMQ是如何基于阿里云Regional ESSD构建十倍降本的云原生Kafka。

1. AutoMQ 云原生架构理念

首先，我们对云服务做了四个成熟度的划分，包括云托管、云优化、云原生和多云原生。其中，在云原生阶段中，产品完全面向云原生设计，才能够发挥出云原生的全部优势，云原生的云服务至少有以下特征：第一，真正的按量计费。因为云是完全弹性的，我们不能按照传统的思维，按规格使用云服务，而应按量付费；第二，考虑到公有云巨大的规模化优势，云原生的云服务需要提供无限的容量，至少单一的客户不用再进行任何的容量评估；第三，既然是新跨时代的云服务，一定要能够实现十倍的成本优势，要有数量级的差异。 而AutoMQ这类的独立SaaS厂商有机会达到多云原生阶段，该阶段除了拥有云原生阶段的按量付费、无限容量等优势外，其设计基于主流云厂商的标准化能力，是云厂商中立的架构，支持部署到主流的云厂商之上，能够有多云的移植性和互操作性。

另外我们也观察到，目前开源社区大量的基础软件正在基于云的能力完全重写，这也是当今云原生发展的趋势。如可观测性领域Grafana的日志、Treason和Matrix全家桶都是基于云存储来构建的。包括数TP/AP数据库数仓、湖仓类软件，甚至是消息和流存储领域的软件都逐渐在被基于云原生的方式再重写，云托管的云服务将逐渐被淘汰。AutoMQ云原生技术路线也因此进行了运维思路的转变和架构设计的调整。

2. AutoMQ 云原生架构

AutoMQ遵循架构设计思路，设计了云原生技术架构图：

如图所示，可以将存储完全分离到云存储，AutoMQ创新性地基于阿里云的Regional ESSD和OSS构建了流存储库S3Stream，将两种存储介质的优势完全结合。对象存储的优势是高吞吐、低成本、容量无限，但其缺点也很明显，每一次的IO耗时都较长，会达到百毫秒级别延迟，不擅长IPOS类型数据密集型的应用。相反，ESSD具备非常高的性能，具备亚毫秒级别的延迟，但其成本较高。AutoMQ创新性地将两个存储介质结合成流存储库，而非服务。

实现计算无状态，充分利用了Spot实例，对Apache Kafka的Broker节点做了改造，实现存算分离，将Broker节点中基于log segment存储层完全替换成了S3Stream。通过这一层替换，我们将Broker改造成了无状态的节点。当Broker完全无状态后，会有以下优势：首先，状态完全卸载过后，原先Broker上的分区可以做到秒级迁移,运维成本能够大大降低；同时因为Broker的完全无状态化，我们可以利用云厂商的竞价实例，如图中所示，Broker混布在spot实例on-demand池中，当Broker完全无状态后,可以将Broker部署在竞价实例中，相对于正价的实例至少可以降本70%。所有的应用都有潮汐的特征，我们并不需要按峰值为应用准备资源，因此在Broker完全无状态后，我们可以很容易地实现serverless的弹性架构。根据以往的运维经验，当业务完全弹性过后，可以节约40%-60%的资源成本。

在共享存储层和无状态计算层之上，我们也构建了控制面，其包括两大核心能力：其一，持续的流量重平衡组件Auto Balancing组件。当Kafka的分区分散在Broker上后，随着业务的变化，每个分区的流量也会变化，不可避免会出现流量热点。此时，依赖持续性流量重平衡组件Auto Balancing组件将流量进行调频，这也是得益于共享存储带来优势。其二，Auto Scaling组件，通过matrix collector将每个Broker节点的matrix进行收集，用于指导自动扩缩容来达到serverless化的产品形态。

现在，我来介绍下流存储库S3Stream。S3Stream是一款基于ESSD和OSS构建的流存储库，具有高性能、低成本、无限容量的特点，且在该流存储库中，ESSD和OSS的职责略有差异。OSS作为主存，用于存储所有的流数据，ESSD用于WAL存储，仅用于灾难场景的recovery。在数据的写入链路中先由生产者将消息以批量的形式发往Broker，Broker会持久化地写入到WAL中，在这一层，AutoMQ去掉了Kafka云原生基于SR机制的复制逻辑，不在应用层复制，而是依赖ESSD内部的多副本机制提供足够高的数据持久性。当数据持久化地写入到ESSD写中后，异步地将数据上传到ESSD中，整个上传是一种即实时的上传，停留在ESSD上的数据很少。在数据的读取链路中，Kafka的读取的模式分为两种，一种是热读，即Tailing部分数据的读取，它会直接从自建的message Cache中读取，而不会消耗任何的存储资源；一种是冷读，即catch-up read，当部分分区的数据被catch驱逐后，数据需要从OSS中读取，可以通过预读机制加速OSS的读取。实际上OSS可以提供足够高的吞吐，但是会有一定的延迟，第一次的拉取操作时首字节可能会有百毫秒级别延迟，但在冷读场景下，数据可能已经失去了时效性，首字节100毫米延迟对业务而言影响基本可以忽略不计。写入WAL采用的是类似于running buffer的机制循环写入。每一次写入都通过IO的方式写穿到磁盘中，以裸设备的方式写入也绕过了文件系统层面的开销，将性能优化到极致。

同时，WAL盘的大小可以采用云厂商最低规格，如配置10 GB的WAL足够。在阿里云上，最低规格的WAL能够提供大概100M左右的吞吐以及接近2000的IOPS。对于单节点的broker也完全足够，如需要更高的WAL性能，可以扩展WAL容量或者组合多块ESSD的券来达到更高性能的WAL，且成本也相对较低。

另外，在OSS上的对象布局有两种。一种是stream object，一种是stream set object。对于数据量特别大的partition，在其上传到OSS时，就直接以stream object的方式上传。stream object中只包含partition的数据，而有些业务场景有很多分区，每个分区中存储的数据量都较少，如果将这类分区的数据也以单独的stream object上传，则会消耗大量的OSS API成本。因此，在这种业务场景下，可以将小分区打包作为stream set object上传。随着时间的推移，小的分区逐渐积累了大量的数据，再对这些stream set object进行compaction，将小的object合并成大的extremists object，简化冷读带来的读放大问题。

前面提到，数据并不同步上传到OSS，如果在EBS上停留的少量数据出现灾难场景如何恢复？基于ESSD的多重挂载能力，可以将ESSD从单机视图变成共享视图，以图中为例，两个Broker中的每个Broker有两块WAL盘数据。首先，数据先写入WAL中，然后异步上传到OSS。在某一时刻，如果ctrl节点判定Broker A出现故障，此时组件会将Broker A的WAL A盘以多重挂载的形式挂载到Broker B。Broker B接管在这块WAL盘过后，首先会对这个盘进行Fencing，阻止Broker A持续写入到WAL盘，因为此时WAL A可能同时被Broker A及Broker B发现。如果Broker A出现的故障类型是网络分区或假死的状态，则有可能持续写入WAL A。当Broker B对WAL A Fencing后，Broker A则无法写入这个盘，则可以理解为WAL A被Broker B独占，然后Broker B会将WAL A中少量的未上传到OSS上的数据上传，当WAL A的数据完全卸载到对象存储上后，Broker A的状态完成转移，此时ctrl节点则会将原先属于Broker A所有分区重新调度给剩余的Broker，剩余的Broker将这些分区依次打开，完成转移。

以上是基于ESSD设计的容灾流程。对于EBS而言，目前它的容灾能力基本会被所有的云厂商支持可用区内的容灾，即可以将EBS在可用区不同的ECS上做挂载、漂移。但目前头部的云厂商，如asher、GCP以及阿里云发布的Regional ESSD，都能够支持将ESSD背后的多副本分散在多个AZ，使之成为支持多AZ容灾的方案，这是将ESSD研发成为高可用共享或存储的技术方案。

接下来，我们来看下Shared Storage VS Kafka Tiered Storage VS Shared Nothing三者的区别。

• Kafka Shared Nothing架构

基于sr机制的多副本技术，图中有3个Broker，它们组成了三副本集群，在数据写入到主Broker后，会被复制到另外两个节点。一般情况下，Shared Nothing架构选取的磁盘都是本地盘，当然也可以选择云存储如ESSD，但成本较高，因为ESSD内部已经自带三个副本，如果Kafka的Shared Nothing架构上继续构建三副本，则会有九副本的数据冗余，会对存储资源造成很大的浪费，所以一般情况下会选择本地磁盘。当然，本次磁盘会有一定的坏盘率，运维成本较高。

• Kafka Tiered Storage架构

很多用户在部署经典的Kafka架构中通过云存储进行构建，成本过高的问题无法避免，为了降低成本，Kafka推出了分层存储，即Tiered Storage 架构。该架构的核心是将本地盘上的数据在log segment rolling时上传到对象存储OSS之上。该架构可以有效降低一级存储的存储成本，但并未完全解决问题，在多级存储架构中，一级存储依然存在，而在一级存储当中依然需要进行复制。

Kafka的架构是将每个partition的数据写入单独的log文件中，因此partition对应的物理文件可能有多个，在一级存储中会遗留很多小文件。如果每个partition都有少量数据，当partition数量过多时，一级存储的空间消耗很大，且这个空间不是固定的，如在Shared Nothing架构中需要为每个Broker配置一块1 GB的磁盘，则在Tiered Storage架构中至少需要配置500 GB的磁盘。这是Tiered Storage架构对Shared Nothing架构的改进，但还有一些问题未被解决，如仅对Kafka的分区迁移、扩缩容的痛点进行了缓解，在Shared Nothing架构中移动分区可能要数十个小时，在Tiered Storage中仅能降低到几小时等。

• AutoMQ Shared Storage架构

AutoMQ推出的Shared Storage架构是完整的共享存储架构，创新性地将ESSD变成了共享存储的架构，即数据完全是存在共享存储中，无需进行复制，极大地降低了计算和存储的资源成本。在这个共享存储架构中，所有的状态都完全共享，所以分区迁移、扩缩容可以轻松实现。

3. AutoMQ 架构优势

AutoMQ Shared Storage架构相比较Apache Kafka，能够带来10倍的成本优化。AutoMQ共享存储架构的优势来源于计算和存储两个维度，首先，在存储方面，AutoMQ的数据主要放在对象存储中，Apache Kafka主要通过本地盘或通过EBS做三副本的复制。EBS的成本约为对象存储的7-8倍。如果不需要进行数据复制，则可以降低90%左右的存储成本，实现存储的优化。其次，在计算层面，计算的降本是多维度的降本，第一，由于不需要做三副本的复制，可以节省了三分之二的计算资源，换言之，在Apache Kafka的架构中需要通过三个节点承担100MB的带宽写入，在AutoMQ架构下，仅需要一个节点，可以节省三分之二的计算成本；第二，由于AutoMQ无状态的Broker设计，可以使用Spot实例，相对于竞价的ECS实例，可以节约70%左右的成本。第三，由于可以做到计算的完全Serverless，故可以支持按面积计费，则可以节约40%-60%的成本。综合所有的降本手段，可以实现计算和存储分别10倍的成本优化。

AutoMQ Shared Storage架构能够带来百倍的弹性效率提升，这得益于AutoMQ共享存储的架构，在迁移分区时仅修改元素即可，因此可以做到秒级的分区无损迁移，而Apache Kafaka移动分区需要复制数据，以100 MB/秒的带宽存储30天的典型workload举例，移动一个分区需约3小时，另外，在流量重平衡阶段，对Kafka集群做扩容时，扩出的节点不承担任何流量，需要对集群做分区的重平衡来达到扩容的目的，对于AutoMQ，扩容一个节点到达到流量重平衡仅需按批次迁移一部分分区，因为迁移分区是秒级迁移的，即使迁移大量分区也能在一分钟内按照批次迁移到AutoMQ的扩容节点，达到流量重平衡。大流量场景中也可以通过批量扩容，快速支持GB级的分区扩容，对于Apache Kafka，扩容需要复制大量的分区数据，因此扩容耗时很久，以工作负载为例，扩容一个节点约需40个小时。同时，由于扩容时需要复制大量的数据，所以扩容的时机对于Apache Kafka十分重要。不能在水位告警的情况下扩容，因为此时会对原集群带来更大的流量冲击，因此需要谨慎评估容量，对Apache Kafka集群做提前扩容，如集群需要扩容时无法扩容，则会导致业务受损。

AutoMQ能够 100%与Apache Kafka兼容。业界有很多Kafka厂商采取了API兼容的方式，而以API兼容的方式实现云原生Kafka的代价很大，因为Kafka发展至今已有十余年，其有数十个API，每个API又有数十个版本，想要完全从API程度兼容所有的Kafka能力是特别困难，且容易遗漏。AutoMQ的存算分离架构将Kafka的存储层完全替换成共享的流存储，保留了Kafka所有的计算层代码，与Kafka实现完全兼容，同时也让AutoMQ非常容易地跟进Apache Kafka上游社区的所有变更。

综上所述，AutoMQ相对于Kafka Shared Nothing或Kafka Tiered Storage架构，在无状态、分区迁移、按量付费以及高可用等各个维度上都有非常充分的优势。

AutoMQ BYOC是AutoMQ在阿里云市场上的一种产品化的形态，全称是Bring Your Own Cloud，即支持将AutoMQ整套软件部署到用户VPC中。BYOC这种产品形态目前也是SaaS服务新的趋势，基本上独立的SaaS厂商都会支持BYOC形态，该形态的最大的优势在于没有数据的主权担忧，因为数据没有走出用户的VPC，所有的计算存储资源完全停留在用户的VPC中。当前，AutoMQ的BYOC形态也已通过计算巢的方式交付到阿里云市场，用户可以一键开通试用，同时，计算巢可以帮助打通跟用户VPC的运维通道，也能够将BYOC巢形态做成全托管的形态。

4. AutoMQ 未来展望

AutoMQ 基于共享存储有进一步的创新规划，其中包括技术创新和产品创新，主要是以下四点内容：

• 灾难恢复

由于数据完全在对象存储上，可以基于对象存储上的数据随时重新打开集群，当集群出现任何故障（软件故障、机房故障）时，可以结合一定的快照机制，将整个集群回放到过去的某时间点，如基于一分钟之前的数据状态重新打开集群，这是集群灾难恢复的技术。相对于传统的基于复制的技术而言，基于共享存储做的灾难恢复技术架构简单，成本低。

• 跨地域的容灾

阿里云OSS支持跨地域的数据复制，可以将某地域的AutoMQ集群OSS中的数据近乎实时地复制到另外地域，当某地域出现地域级故障时，可以在另外地域以提取灾难恢复的技术将整个集群重新打开。

• 共享只读副本

Kafka有一类业务场景是高删除业务类场景，其读写比可以达到一比几十的比例，而partition固定在Broker上，所以某个单结点很难承担如此高的读取流量，理论上基于共享存储每个分区的数据在任何节点都可读，所以可以考虑基于共享存储提供共享只读副本的能力，某个分区可以在单节点写入，在多节点被读取，来提高算术能力。

• Zero ETL

Kafka在大数据生态中有很重要的生态地位，因此社区也诞生了一大批source connector及think connector与Kafka做数据的连接，这些连接器会消耗大量的存储和计算资源，当所有的数据都通过共享存储存储并池后，如果数据的格式在所有的系统通用，就可以真正做到Zero ETL，无需通过连接器进行加载、使用Kafka中的数据，只要通过对象存储的API直接使用即可。

另外，现代数据技术栈是通过OSS等数据湖来构建现代的数据数仓系统，流式数据作为大数据重要的一环，AutoMQ 希望通过将流式数据入湖来构建流表一体化的架构，即可完成现代数据技术栈的最后一块拼图。

以自然规律来看，数据在产生时是以流式数据产生的，所以数据的第一站以流式存储完全合理，并且流式存储具有高时效性的特点，这意味着它有非常高的实时价值，所以通过Kafka的实时能力以及flink的实时计算能力，能够充分地挖掘实时数据的价值。而且当数据实时性降低时，还可以将流式数据通过转表的形式在OSS上直接展开为表格式存储，如转换为Iceberg形式存储，此时，现代的数据栈就可以直接加载Iceberg中的表格式数据来做进一步的大规模离线分析。

以上是本次分享的全部内容。

分享人：周新宇  AutoMQ 联合创始人 & CTO