是时候基于云重新设计 Kafka 了！AutoMQ 如何实现 Kafka 十倍的降本增效

Kafka 和 RocketMQ 在众多企业中得到了广泛的应用，但也面临着巨大的技术挑战。这些挑战包括如何确保超大规模集群的可用性，如何避免运维操作中的故障，以及云服务提供商如何为数万家企业提供云上消息服务。早期，我们依靠手动参数调整来解决这些问题，后来逐渐积累了各种工具来实现自动化运维，但是距离大家畅想的终态仍有距离。

另一方面，技术不断在发展。2014 年，AWS 推出了 Lambda 服务，让开发者可以彻底摆脱服务器的运维，2018 年，Google 推出了 Cloud run，极大拓展了 Serverless 的场景，可以让任何基于 HTTP 的服务都能被 Google Cloud 托管。Apache RocketMQ 的作者王小瑞，以及 Apache RocketMQ 联合创始⼈周新宇，曾在阿里巴巴负责了十年以上的消息中间件研发工作，他们于 2018 年开始推进阿里巴巴内部核心业务的云原生 Serverless 化，目标是如何让成千上万个应用不用关心线上机器容量，做到扩缩容全自动，甚至一分钟就能创建一个生产级可用的面向互联网的分布式应用。这也为他们带来了启发：RocketMQ 和 Kafka 是否也有机会做到这样，像一个 Lambda 函数一样，不需要关心服务器运维。于是章文嵩博士和他们共同成立了一家新的公司，安托盟丘（杭州）科技有限公司（以下简称 AutoMQ），专门致力于打造云原生的消息队列。

AutoMQ 公司为 Kafka 和 RocketMQ 设计了全新架构，完全构建在云厂商的对象存储之上，带来了 10 倍的云账单节约，更是将最复杂的数据存储卸载到了云服务。据 AutoMQ 联合创始人章文嵩博士介绍，Snowflake 是第一个将数仓完全构建在对象存储之上，带来了巨大的成本优势和每个用户独占计算资源的多租户隔离效果。而 MQ 这个领域是一个典型的分布式存储系统，越来越多的企业将 MQ 用在了核心业务的关键链路上，但是目前市面上还没有一款 MQ 产品像 Snowflake 一样彻底构建在云上，相信完全基于云设计的 MQ 会带来巨大的技术优势。

最近，由 AutoMQ 和 InfoQ 共同主办的《Apache Kafka × RocketMQ 云原生创新论坛》将于 11 月 4 日在杭州举行。为此，InfoQ 采访了 AutoMQ 的核心团队，以了解他们在 Apache Kafka 和 Apache RocketMQ 领域的最新见解以及最前沿的架构设计理念。

AutoMQ 团队：对企业来说，成本和效率是首要考虑的因素。此外，如果涉及到闭源软件，可能会引发厂商锁定的问题。在当今，架构师通常更倾向于选择开源项目作为基础软件的首选。

总拥有成本 TCO 是用户选择的关键，这个产品自建需要的机器成本和人员维护成本以及对软件深入度不够带来的宕机风险综合成本决定了客户的选择，如果托管方案明显优于开源自建，那么用户选择托管方案是最合适的。

如果用户的业务非常关键，那么也不建议自行搭建，因为完全掌握一个开源软件达到满足业务匹配的可用性要求，付出的人员成本和时间成本都是非常高的。

开源软件永远无法达到终态，绝大部分开源软件开源的是核心代码，核心代码距离生产环境高可用的服务还有巨大的差距，这里需要大量的周边工具配套以及专业工程师的持续维护。而托管方案可以非常高效的完成这个工作。

AutoMQ 团队：最大的差异是：彻底的云原生化。

我们理想中的云原生 Kafka 应该能做到计算、存储、网络按量付费，并且理论成本最优，系统可以随着业务负载自动调整机器数，整个过程对上下游完全透明。

要做到计算实例的按量付费，就必须从传统的使用 Reserved 实例变为 Spot 实例，这样才会真正达到按量付费的效果。

AutoMQ 将对象存储作为了主存储来使用，而非 Tiered Storage，这样整个存储的复杂度就彻底卸载到了云厂商，几乎让 Kafka 集群，RocketMQ 集群做到了无状态，即使使用 Spot 实例来部署 Broker，也能在 Spot 实例被回收之前所有状态数据同步到对象存储，这样整个计算实例销毁无需数据再平衡，其他节点自动从对象存储接管宕机节点的分区，做到分区秒级被接管，扩缩容同理，分区数不因为增加节点而变化，数据不因为扩缩容产生热点，系统全自动在数秒钟达到最优状态。

AWS 的 S3 背后有数百名工程师经过数年的不断优化，目前已经是世界上最便宜的存储之一，并且能保证超高可用性，同时跨 AZ 网络流量是免费的。其他云厂商的对象存储也同样投入巨大，我们相信彻底基于云厂商先进的 IaaS 架构重新设计的 Kafka 和 RocketMQ 能带来无与伦比的技术优势。

AutoMQ 团队：我们了解到，基于当前的开源 Kafka 等技术架构，大部分企业进行降本增效的有效手段是进行取舍，比如牺牲数据存储时长来降低存储成本，或降低存储的副本数来优化整个 IaaS 层的成本。这些手段要么牺牲了业务的灵活性，要么牺牲了可用性或者可靠性，对业务的挑战是巨大的。

现在，AutoMQ 通过寻找云上的最佳实践，来重新设计 Kafka 的架构，期望的目标是将成本做到「云上理论最优」，要完成这个目标我们主要的方案分为两个步骤。

第一步是「面向云的计费项」去重新设计整个分布式的架构，开源的 Apache Kafka 在生产环境的成本结构大致为「网络：存储：计算 = 5:3:2」，对于这三类计费资源 AutoMQ for Kafka 的降本方案为：

• 网络：主要是在 Kafka 多副本且跨可用区场景带来的流量费，AutoMQ 将数据可靠性问题转移给自带 3 副本的 EBS 和可靠性达 11 个 9 的 S3，同时通过共享存储来解决可用性问题，避免引入多副本机制，通过云带来的技术红利解决可靠性和可用性问题。这一方案可以在消除复制带来流量费的同时，会同步节省存储和计算费用。

• 存储：将存储的每一个计费项参与到架构设计当中，以 S3 为主存，同时优化 S3 的 API 调用将存储成本降低一个数量级；以 EBS 为 WAL，优化 EBS 的空间到 10G 内，完全的顺序写将 IOPS 优化至数百。

• 计算：将存算分离架构发挥到极致，将存储的复杂度卸载到云，将计算优化至「无状态」，从而能够最大程度地将 Spot 实例的成本优势发挥出来。

在面向计费项重新设计整个架构后，下一步是要兑现云最核心的优势「按量付费」，这要求整个架构是完全弹性的，通过极低成本完成 Scale Out 和 Scale In，对于 EC2 和 EBS 要最小化保有时间。这对于开源的 Kafka 来说是极为困难的，因为扩容意味着需要流量快速重平衡，缩容意味着要求数据能快速完成迁移，这些都是开源 Kafka 很难完成的任务。AutoMQ 弹性的分布式架构能够将「按量付费」的技术红利充分释放给 Kafka 的用户，具体的架构详情将在 11 月 4 日的会议上进行分享。

AutoMQ 团队：基本上，一个分布式的系统其对资源的消耗和数据规模是呈线性关系的，所以物理资源上的成本基本上是集中在计算、存储和网络上。

但除了资源成本，另一项无法忽视的成本是运维成本，它跟规模的关系将变得更加复杂，大规模的数据场景下，将会带来更多的运维挑战，比如识别性能瓶颈、快速解决容量问题、大规模的集群和数据治理、稳定性治理等。以我们了解到的情况来看，PB 级别的数据量，一般需要一个 5 到 10 人的专业研发和运维团队来提供技术支持。在 TB 级别的系统上，人员成本占比会更高。

AutoMQ 团队：Serverless 模式最直观的好处就是成本优势，Serverless 架构能够将计费资源转换成按量付费的模式，最小化计费粒度，比如将流存储依赖的计费资源全部变成 Serverless 模式后，成本至少下降一个数量级。

另一方面，Serverless 模式将会加速技术的成熟，特别是流计算相对于批计算来讲，批计算因为是周期性地进行批处理，实际上是一种按量使用的模式，比如每天申请一批资源完成特定的计算任务，所以批计算相比流计算天然就具备成本优势。流计算是一种实时计算，需要时刻保有计算和存储资源，如果流计算依赖的技术栈完全是 Serverless 的，带来的成本优势将加速流计算的普及和成熟。

AutoMQ 团队：Serverless 从来就不是一件容易的事情，AutoMQ 团队除了有丰富的云计算商业化经验以外，也负责了阿里巴巴的在线业务 Serverless 化，这其中有几个主要的挑战为：

• 用户负载的不可预测性：理想情况下，将集群水位控制在 100% 是最经济的方案，但在实践过程中，往往需要预留充足的水位来应对不可预测的流量。AutoMQ 解决这个挑战的方案为充分利用基础云产品提供的 Burstable 的能力，比如 EC2、EBS 和网络，都会提供 10x 左右的 Burst 能力，虽然持续时间短，但会为弹性扩容提供宝贵的时间。甚至，对于 EBS，完全可以通过一个 API 修改 IOPS 和吞吐上限即可完成扩容。

• 资源的碎片化：衡量一个调度和弹性平台的一个重要指标就是「资源的碎片化」，一个显而易见的事实是，一个集群成员的规格越大，整体产生的碎片化越严重，规格越小，越容易消除碎片。AutoMQ 面向小规格进行设计，比如 2C 的机器单元，将 CPU、内存、存储带宽、网络带宽都充分利用起来，非常有助于在各类弹性平台中大幅度减轻资源碎片化问题。

• 快速的冷启动：我们在解决阿里巴巴在线业务的 Serverless 问题当中，发现一个复杂的应用，启动时间可能是 10 分钟级，在如此慢的冷启动的前提下，Serverless 难度将进一步被加大，不能快速 Scale Out，也就不敢随意地 Scale In。彼时，我们的解决方式是「快照 - 恢复」方法，通过对进程进行内存快照，在 Scale Out 时快速 Restore 出来，大家可以发现，近两年业界很多函数计算平台比如 Lambda，华为云的 FunctionGraph 都陆陆续续采取了类似的方案。但对于 RocketMQ 和 Kafka 这类存储软件来讲，最耗时的过程还是扩容后，流量能否快速迁移过来达到负载均衡的状态，对于 Kafka，迁移分区是小时级别的。为了解决这个问题，AutoMQ 的方案是从 Shared Nothing 架构走向 Shared Storage 架构，当存储变得共享后，移动一个分区是秒级的，也意味着扩容时可以快速达到流量重平衡，缩容前可以快速将分区迁移走，极大地降低了 Serverless 实现的难度。

综上，AutoMQ 通过充分利用云的 Burst 能力，云产品的 API 能力，小规格的部署能力，共享的存储能力来达到高效、经济地利用云资源的效果。

AutoMQ 团队：云的普及和发展不仅为技术架构的变革提供了契机，同样也为产品创新提供了新的土壤和空间。众多产品思考和创新逐渐从不可能变成可能。

AutoMQ 作为新一代云原生消息队列技术服务商，我们持续专注于挖掘云基础设施的技术红利，为客户提供低成本、高性能、高可靠的消息队列和流存储解决方案。

在未来，我们将关注以下几个方面：

• 成本经济性：正如上面降本增效的话题所述，AutoMQ 会持续挖掘云基础设施的技术红利，结合云资源计费项粒度的技术架构调优，在架构弹性、资源调度、请求优化等方面继续突破，为企业客户提供极具成本竞争力的产品方案，帮助企业科学降本。

• 数据集成和价值挖掘：AutoMQ 提供的新一代 RocketMQ、Kafka 消息流存储服务，使用对象存储作为主存储，所有业务数据原生存储在对象存储中，可以完美地和当下主流的数据湖、数据仓库等方案进行集成整合。这一天然优势可以消除传统数据流 ETL 的架构复杂度和运维成本问题。

• 多云一致输出：多云和混合云架构在企业中越来越受欢迎。AutoMQ Cloud 从第一天设计开始就坚持 Cloud Anywhere 的理念，将云厂商底层基础设施的差异性屏蔽，为企业用户提供多云一致的消息队列和流存储服务，方便企业在多云、混合云场景下构建一致的容灾和数据集成架构。

• 专家经验产品化输出：AutoMQ 研发团队积累了十多年的消息队列生产运维经验，我们一直在探索如何将消息队列的生产运维经验以产品化工具和服务的形态普惠开发者。近期发布的 AutoMQ Copilot 产品就是这样的一款工具产品，未来我们会面向更多的开源消息队列产品提供类似的工具和服务。

在云原生技术的浪潮中，我们如何更好地理解和应用 Apache Kafka 和 Apache RocketMQ 的实际案例和最佳实践？11 月 4 日，我们邀请你来参加“Apache Kafka x RocketMQ 云原生创新论坛 ”，本次云原生创新论坛将重点探讨它们在不同行业和领域的应用案例，以及如何充分利用这些技术来解决复杂的业务挑战，同时也会有基于云彻底重新设计的 Kafka 和 RocketMQ 技术方案分享。可点击阅读原文或扫描图片中的二维码报名参加~