上云还是下云：章文嵩博士解读真正的云原生 Kafka 十倍降本方案！

今天，我们看到云计算带来了两个趋势，一个是“上云的趋势”，另一个是“下云的趋势”，相信大家都关注到了最近 X（原 Twitter） 全力“下云”，成本降低了 60%。“上云”亦或是“下云”，到底谁在节约成本，谁在增加成本，这其中的差异可能三言两语很难讲清楚，但就 AutoMQ 核心团队在阿里云多年的工作经历来看，头部云厂商一直是以“让算力普惠、释放技术红利”为使命的，那到底为什么“上云”会给企业一种更贵的感受呢？

AutoMQ 团队认为这其中最主要的差异在于云原生（Cloud Native）和云托管（Cloud Hosted）的差异。以云托管的姿势上云，最终会发现云上成本比自建机房还高，将传统的软件架构 Rehost 到云上，其本质是将 IDC 架构平移上云，是无法发挥出云基础设施的规模化优势，也享受不到成本红利。只有以云原生的姿势上云，充分利用云的弹性能力，服务化的产品和自动化的 API，才能做出云上最优的成本解决方案。

在引出 AutoMQ 为 Kafka 打造的云原生架构之前，我们先来看一下云的基础设施已经进化到什么程度了，有哪些能力和优势是跟成本息息相关的，而且是传统的 IDC 架构无法充分利用起来的。

云计算技术迭代的路线可以总结为：云先用软件定义硬件，再把软件变成了服务。所以，我们今天看到网络环境变成了 VPC，存储介质变成了云盘，物理主机变成了虚拟的云主机 ECS。

这些云提供的基础产品在今天已经蜕变成了服务，服务一定是具备生产可用的 SLA，比如阿里云单个 ECS 实例的可用性达 99.975%，这意味着一个单节点的微服务也可以是生产可用的，这在 IDC 环境是无法想象的事情。再例如云盘 EBS，相对于物理存储介质，EBS 天然具备 3 副本，提供 5 个 9 ～ 9 个 9 的数据可靠性，同时具备可用区内和区域内的容灾能力。

所以，我们今天做云原生架构，第一个共识就是需要意识到，基于云的架构设计已经从依赖软硬件，变为依赖云服务了，真正的云原生架构一定要充分发挥出云产品的服务化能力。

弹性可以说是云最大的优势，云积累了大规模的算力，给了单个租户无限计算资源的视图，云原生的架构完全可以假设，在云上一切资源都是无限的，都是唾手可得的。

对于 IDC 环境，因为机器资源至少月级的交付时间，传统的软件架构并不会面向弹性能力进行设计，一般都会假设保有一定的机器资源来提供软件服务。这也意味着，当传统的软件 Rehost 到云上后，也是以预留资源的形式使用云资源，一方面存在资源的极大浪费，另一方面也无法享受到云的弹性能力。

不难发现，弹性能力的来源并不是资源交付时间变快了，完全是因为云厂商通过预留大量资源实现了租户级无限的弹性的能力，所以说“世上本没有真正的弹性，都是云厂商在负重前行”。正因为这样，云厂商各个地域都有大量的闲置资源，云厂商为了尽可能将闲置的资源转换为营收，推出了 Spot 计算实例，Spot 类型的实例相较于正价的 ECS 实例，至多有 90% 的成本节约。如何充分发挥出 Spot 实例的成本优势，也是云原生架构需要重点考虑的地方。

云计算所有的能力都是通过 API 来进行描述的，比如用 API 创建一台 ECS，用 API 重新挂载一块云盘，用 API 去调整云服务的 Quota 和 Limitation。

正因为此，云原生的软件有机会利用 API 去编排资源，去实现 Auto Scaling，实现容灾的切换。通过利用云的 API 完成软件核心的能力建设，甚至容灾能力的建设，这也是传统的软件架构无法办到的事情。

云厂商提供了数百种的全托管云服务，但这些云服务成熟度完全不一样，不少小的云服务研发团队仅仅有个位数的人力投入。所以，我们在进行云原生架构设计时，需要谨慎进行云服务依赖选型，我们总结了两个原则：

• 选择云厂商投入最大、规模最大的云服务，这类服务成熟度往往是最高的，不能单纯看云厂商承诺的 SLA。

• 选择标准化的云服务以避免厂商锁定，我们设计的云原生架构必须是所有云的原生架构，而不能单纯是某朵云的原生架构。

在这两个原则的约束下的云服务，也是云厂商真正释放云原生能力的出口，它们往往有以下几个特征：

• 真正的按量计费，以最小的资源粒度按使用量进行计费，比如 Lambda 按调用次数计费，没有任何保有成本。将实例规格包装成按时间进行计费不是真正的按量计费。

• 无限的容量，给单个租户的视图一定是无限的容量，无限的存储和计算资源，业务再也不需要进行容量评估了。

• 低成本，真正地通过技术而不是通过亏损，通过规模去优化成本，比如对象存储 S3 是业界最便宜的存储产品之一。

选择性地依赖云服务，可以让我们的云原生架构更加灵活，充分享受到云的红利，多云原生的灵活度，更高的稳定性保障。

AutoMQ 将消息和流存储最流行的两款开源软件 Kafka 和 RocketMQ 基于云重新设计，将这两款面向 IDC 进行架构的软件带向云原生领域。Kafka 和 RocketMQ 的核心分别是流存储和消息存储，对于存储类型的软件，要完全把云的能力用起来并不是一件容易的事情。

AutoMQ 在进行 Kafka 和 RocketMQ 重新设计之初，就定义了几个设计目标：

• 尽可能发挥出云的弹性能力，将弹性作为核心能力去设计，根据负载变化系统能进行弹性伸缩。

• 尽可能使用 Spot 实例，Spot 实例有随时被中断的风险，能否实现存储软件的“无状态”是能否利用 Spot 实例的关键。

• 尽可能将数据全放在对象存储上，S3 极具成本优势，存储系统降本的关键一定在于能否将 S3 的能力发挥到极致。

• 尽可能利用 EBS 的低延时和高性价比，解决业务对数据写入的低延时需求，通过 EBS 和 S3 组合出高可用能力即可提供低成本、高可用和高可靠的存储服务。结合云已经有的能力，以及我们对流存储和消息存储软件的理解，我们设计了一套真正的云原生架构，同时满足了以上几个设计目标。

该架构主要包含三个核心设计思想。

存算分离拥有状态卸载、弹性等好处，这已经是行业共识，但如何实现存算分离没有统一的方案，我们今天认为存算分离的核心是将存储分离至服务而不是软件。如果，我们为了存算分离将存算一体架构的存储部分，分离出一套分布式存储软件，这会带来额外的部署、运维以及治理的复杂度。

RocketMQ 早期的架构是完全零依赖，正因为架构极简，让它在生产系统的实际可用性非常高，今天存算分离的优势已经被众多开发者所喜爱，但是任何一个软件的可用性是由软件本身和后台运维的工程师组成，如果这个软件还依赖其他软件，那么它就类似一个串联电路，任何一个环节出问题，就会影响最终用户，尤其是依赖一个无人运维的存储系统，更是会让整个系统的复杂度和可用性失控。而云厂商的对象存储、块存储等大规模使用的系统背后有全世界最优秀的工程师在运维，理论上这样的系统一定是可用性最高的。

另外一点就是存储能否做到完全卸载，有些观点认为多级存储也是存算分离，实际上业界大部分多级存储方案都有很重的一级存储，一级存储包含了大量的存储状态。如果无法做到存储的完全分离，也就无法将存算分离的弹性优势发挥到极致。

我们对存算分离理念的实践都体现在 S3 Stream 这一基于 S3 的流存储库之上，S3 Stream 组合 EBS 和 S3 的能力，实现了低成本、高可用、高可靠以及无限容量的流存储能力，更多的技术细节详见我们的文档（https://docs.automq.com/）。

Shared Storage 和 Shared Nothing 架构各有优劣，但今天在云上，存储已经变得弹性，容量近乎于“无限”，我们认为共享存储是一个更优的架构。

通过将存储单元进行共享，状态可以快速转移，分区迁移、节点扩缩容将变得非常简单。共享存储也是云原生架构能否充分利用 Spot 实例的关键。

回到 Kafka 和 RocketMQ 的核心能力上，这两款软件都自带多副本机制，目前分布式架构不管是 Raft 共识算法还是其他变种的副本机制，都是通过副本的冗余，一方面实现数据的高可靠，另一方面多余的副本可以快速提供故障转移的能力，从而实现高可用。

但在云上，云存储 EBS 已经自带 3 副本了，如果上层应用继续采用复制的方案，将带来 9 副本的数据冗余，以及多倍的存储和网络成本。所以，在 Kafka 和 RocketMQ 层面没有必要自己实现 3 副本。另外，EBS 是第二大存储系统，仅次于第一大存储系统 S3，云厂商对 EBS 进行深入的软硬一体优化，把 EBS 客户端卸载到神龙 CIPU（智能网卡）通过硬件来做，EBS 客户端跟 EBS 服务器的通讯针对数据中心内低延时低丢包率的特点实现自定义的传输协议而不是用 TCP，这些软硬一体优化带来的效果远远好于自己搭建的 3 副本高可靠系统。还有，在云上使用 EBS 来存储不消耗网络带宽，自建的 3 副本复制会大量消耗网络带宽。

鉴于此，AutoMQ 提出了服务的可靠性与可用性实现方案，依赖 EBS 的可靠性，可以采用单个写入计算节点，把数据先写入到存储在 EBS 裸设备的 WAL 中，若当前写入计算节点故障了，其他计算节点接管这个 EBS，从 WAL 中恢复数据。通过基于 EBS 的 Detach/Attach API 以及 NVMe 相关的 API 实现一次只有一个计算节点可以写入 EBS，确保 EBS 数据写入的一致性。

AutoMQ 团队将云原生架构的技术优势，兑现为成本优势和运维效率，为 Apache Kafka 带来的十倍的降本增效。

Kafka 运维有两个痛点，给运维人员带来了极大的运维成本：

• 分区迁移，Kafka 迁移分区需要进行数据复制，一方面额外的复制流量对生产环境会产生稳定性影响，另一方面复制耗时一般比较长，导致迁移分区的操作需要长时间进行观察，以确保系统达到终态。

• 扩容，当 Kafka 集群流量不足时，运维人员需要对集群进行扩容，但扩容后的节点无法承担任何流量，需要从其他节点移动分区过来，也就是说扩容需要移动大量的分区，才能达到流量的重平衡。扩容操作需要提前扩容，如果在业务高峰时进行扩容是无法缓解生产压力，反而会进一步将生产集群推向高风险状态。AutoMQ 的云原生架构得益于将存储状态卸载到共享存储上，移动一个 TB 级的分区能将时间从 3 小时缩减为 1.5 秒，扩容后流量重平衡时间从 43 小时缩减为 1 分钟，成功地将 Kafka 高风险的常规运维动作，变成了可自动化，基本无感的低风险运维操作，大幅度降低了运维人员的工作负担。

成本方面，我们提供了一个 80 MB/s ～ 1 GB/s 的弹性工作负载用于压测真实的云账单，在该负载下，AutoMQ 提供的云原生 Kafka 版本每月仅需 5632 元，相比于自建 Apache Kafka 承担该负载需要 62,431 元，AutoMQ 的云原生架构成功降本 11.09 倍。AutoMQ 获取成本优势的核心主要有几点：

• 充分利用对象存储和 EBS 的低成本特性，将存储成本降低了 90%。

• 通过无状态的架构设计，内置 Auto Balancing 组件，实现自动扩缩容能力，再充分利用 Spot 实例，能做到计算成本降低 11.09 倍。近期，我们发布了完整的成本分析报告，详情见 AutoMQ 的官方文档。

AutoMQ 团队通过对 Apache Kafka 进行全新的云原生架构设计，成功做到了 10 倍的降本增效，充分验证了真正的云原生架构是能充分发挥云的规模化优势的，能做到超出预期的、十倍的降本效果，能大幅度降低运维复杂度，真正做到共享云的一切优势。

云计算，开辟了一个新的时代，以云原生的姿势上云，是不会有下云的忧虑，我们坚信，所有的基础软件，都值得基于云重新设计，以发挥出云全部的优势。

章文嵩，AutoMQ 联合创始人 & 首席战略官，开源项⽬ LVS 创始⼈。

周新宇，AutoMQ 联合创始人 & CTO，Apache RocketMQ 联合创始⼈。

英特尔On技术创新大会中国站来啦！12月19日 09:00 正式上线：中国专家深度讲解最新一代增强AI能力的计算平台，支持开放、多架构的软件解决方案，塑造未来的技术和应用创新。从云到端，助力开发者，让AI无处不在！即刻点击【阅读原文】或扫码预约围观~