一直以来,存储软件都基于复制来提高数据的可靠性和系统的可用性,复制的方式有很多种,各个模式间可能还有交集:
因为有了多个副本,一方面能够容忍部分副本的数据损坏,也能在部分节点不可用时,通过冗余的副本选出新的 Leader 节点来提高系统的可用性。
在面向 IDC 环境,这样的架构没有任何问题,但今天将这些存储系统 Rehost 到云上后,第一个暴露出来的问题就是成本。
我们都知道,云存储已经提供了极高的可靠性和可用性,以块存储 EBS 和对象存储 S3 为例:
当然,不同的云厂商有 SLA 差异,不过可以看出云存储已经通过多副本或 EC 技术提供了很高的 SLA 了,如果应用层还要基于云存储去做 3 副本复制,数据最多可能会冗余 9 个副本。
基于这个背景,想找大家讨论下,如果要面向云做一款真正云原生的存储软件,Raft 这类算法还有必要性吗?
我目前的答案是完全没有必要了,云原生的软件一定是要深度用云,把复杂度卸载至云,让应用层变得更轻量,更弹性,更低成本,基于这些思考,我们( AutoMQ )面向云原生重新设计了 Kafka ,充分撬动云计算带来的技术和规模化红利,感兴趣的可以移步我们的开源项目: https://github.com/AutoMQ/automq-for-kafka
不知道 V2EX 的开发者们怎么看待这个问题,欢迎大家发表下看法。
1
cyifei2023 302 天前
automq 这个方案相比不用云存储的 Apache kafka 具体哪些方面有优势呢?有数据吗?
|
2
XDMonkey 302 天前
基于云盘再去构建多副本一定是重复建设,问题是如何相信云厂商的 SLA 。。
|
3
wan0573 302 天前
@XDMonkey 这个本质是云信任的问题。云也是在发展中的,长远来看云厂商的 SLA 肯定是比自建更高的。只不过国内现在每次云厂商出问题都上新闻,好多自建的出事没上新闻,让大家感觉好像自建 SLA 更好一样,其实不然。我们可以参照云发展更加先进的美国,他们很多银行也都是直接使用的公有云。这个 google 下可以搜到很多新闻: https://ir.usbank.com/news-releases/news-release-details/us-bank-partners-microsoft-accelerate-future-banking-cloud
|
4
zhouxinyu OP @cyifei2023 我们因为基于 S3 构建了一层共享存储,实际上是一个 Shared Everything 的架构,Apache Kafka 是一个传统的 IDC 架构,走的是 Shared Nothing 路线,所以每个 Broker 都会绑定一块磁盘。存储完全共享后,我们获得了这些优势:
1. 弹性,S3 的大规模,对于单个租户,可以认为是无限容量的,再也不需要做容量评估了。 2. 因为有了共享存储,困扰 Kafka 已久的分区迁移和扩缩容问题都迎刃而解。 3. 最重要的是成本,不需要复制,省了大量的存储和计算成本。 4. 存储卸载至云,Kafka Broker 变得无状态,云厂商的竞价实例都可以用起来。 我们发表过一篇技术文章,讲解我们的云原生架构,可以看一下:[上云还是下云:章文嵩博士解读真正的云原生 Kafka 十倍降本方案!]( https://www.infoq.cn/article/f4hJdZqtKAQdJvCKQYq7) |
5
zhouxinyu OP @XDMonkey 请相信云厂商提供的块存储、对象存储这类服务,背后有数百人的团队,一定比企业自建更稳定。另外,在云上,最大的稳定性风险实际上是来自于软件故障,因为云上所有的资源生命周期都是通过 API 来管理的,我们架构上很容易通过「可编程」的理念来应对这些故障,比如 ECS 、EBS 、S3 任意一个资源出故障,我们都可以通过 API 创建替换资源用于容灾。
|
6
isno 258 天前
原来是 RocketMQ 的大佬。
没仔细看过 AutoMQ ,AutoMQ 是把底层的存储、可用性交给云对吧? 上云托管,将底层系统的复杂度交给云基础设施,技术美好,商业上应该能趟出一条路。 |
8
isno 251 天前
@zhouxinyu 我在想一个反向的问题:云上的资源虽好,但贵。而且还绑定服务商不好迁移。
如果方向是“云上之云”,只利用云 IaaS 层最基本的资源(网络、存储、计算),做私有化的 PaaS 方案。一键就能在 ECS 安装高可用的 RDS 、MQ 、存储、K8S 、分布式的 GPU 等等服务。架构做到易用,自由迁移( ali 到 azure 、azure 到 aws ,甚至到自建机房),享受无限的云上资源。 这个想法怎么样? 能锤下我么? |