高手问答第 296 期 —— 天空计算到底是不是云计算的未来?

OSC哒哒 发布于 2023/01/31 14:30
阅读 14K+
收藏 6

阅读《2024 中国开源开发者报告》赢大奖,扫码申请享特权

云计算时代下,云厂商帮我们解决了计算和存储资源的维护与拓展问题,但用户也面临被厂商绑定的问题。

2021年UCBerkeley 提出了Sky Computing(“天空计算”)的概念,其目标是允许应用跨多个云厂商运行,实现多云之间的互操作性。 算力和数据在多云之间的迁移是天空计算需要解决的两个基本问题。随着虚拟化技术的发展,算力迁移正在逐渐得到解决,无状态计算密集型任务可以在各个云厂商无差别运行。但安全快速地进行跨云数据迁移和同步仍存在较大挑战。

云计算背景下的分布式系统大多运行在同一数据中心的多台服务器上,其间网络延迟低,可靠性高。跨云则意味着服务器间物理距离的增加,导致网络延迟增加和可靠性降低,服务器间的一致性维护,共识的建立都更加困难。 Xline是使用Rust开发的跨云KV数据库,兼容Etcd的metadata存储接口。Xline基于CURP协议实现,在跨云部署情况下相较基于Raft的Etcd有更好的性能,实验表明理想情况下延迟低一倍。使用Xline可实现数据跨数据中心共享访问,并且保证数据的一致性,方便业务系统实现多地多活部署。

OSCHINA 本期高手问答 (2 月 1 日 - 2 月 7 日) 我们请来了施继成老师和大家一起探讨关于“天空计算”相关的问题。

可讨论的问题包括但不限于:

  • 天空计算相较于云计算的优势
  • 跨云存储面临的技术挑战
  • Xline如何做到低时延跨云数据交互
  • 分布式一致性协议原理与选型
  • 如何打造低耦合可复用的协议框架
  • Rust开发的优势与劣势

有其他相关问题,也欢迎大家积极提问!

嘉宾介绍

施继成,DatenLord 联合创始人兼 CTO,曾就职于谷歌、微软、阿里巴巴等互联网公司,多年操作系统和分布式系统研究和开发经验。

为了鼓励踊跃提问,我们会在问答结束后从提问者中抽取幸运会员赠予《Rust 实战》书籍一本。

 

OSChina 高手问答一贯的风格,不欢迎任何与主题无关的讨论和喷子。

下面欢迎大家就编程语言设计与开发相关的问题向施继成老师提问,直接回帖提问既可。

加载中
0
OSC哒哒
OSC哒哒

高手问答第 296 期 —— 天空计算到底是不是云计算的未来?

@某人gmgn3  @osc_32324621 @pyboy58  @屮殖  @zerolemon

恭喜以上5位网友分别获得《Rust 实战》书籍一本

请于02月16日12:00前登陆账号, 私信@OSC哒哒    告知快递信息(格式:姓名+电话+地址),逾期视为自动放弃哦~

osc_566335
osc_566335
感谢!快递地址已私信发送,麻烦查收。
0
osc_566335
osc_566335

@达坦科技DatenLord Rust 和 天空计算 都是我关注的内容。没想到今天可以放到一起。不过我有点可能杞人忧天的担心:就是国内“分联网”,国外“给你断网”的这种操作下,是否会带来跨运营商实际操作的难度?各个厂商对天空计算的支持态度如何?以及,我层设想的,将发布后台数据量少但是要求算力大的计算放在自建的廉价本地机房以避免干线机房的大额费用的思路,是否还有多少必要性?或者有没有其它更好的解决方案?

达坦科技DatenLord
达坦科技DatenLord
确实有难度,但只要用户有跨云的需求就值得克服困难去做。这是前期的技术积累,各个厂商也在跟进,从他们发布的技术就可以看出。以国内的阿里云为例,其主导的Serverless Devs(https://www.serverless-devs.com/)就是在做避免厂商锁定的多云工具链。Xline(https://github.com/datenlord/Xline)主要解决的是跨云元数据管理问题。
达坦科技DatenLord
达坦科技DatenLord
各厂商云原生产品都在提供相互兼容的应用打包格式和API,以对象存储为例,无论是阿里云的OSS还是腾讯云COS都兼容AWS S3接口,可以无缝切换。 所以厂商态度是比较明确的。至于解决方案的问题,需要结合具体需求做调研和计算。云上计算资源的付费方式有包月、按需、竞价等多种方式,机房地点,时段和付费方式不同可能导致价格有几倍的差别。如需要持续大量的计算而对可用性等指标无特别要求,混合部署可能有价格优势
0
开源中国首席路人王
开源中国首席路人王

@达坦科技DatenLord 请问云原生是什么意思吗?

达坦科技DatenLord
达坦科技DatenLord
云原生基金会对其定义如下: 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
达坦科技DatenLord
达坦科技DatenLord
通俗来讲就是借助容器等技术,面向云开发的,充分利用云上资源以提高应用的开发和维护效率的行为都可以被称为云原生的。Xline就是一个云原生案例,可以容器化部署,弹性拓展等。也可以对照本地单机应用开发和维护流程的反面进行理解。
0
达坦科技DatenLord
达坦科技DatenLord

引用来自“osc_32324621”的评论

@达坦科技DatenLord

1. 请问前面的回答中提到了

在无冲突情况下(fast path),Curp 协议能比 Raft 协议或者 Paxos 协议节省 1 个 RTT。在有冲突的情况下(slow path),Xline 中的 Curp 能够退化为 Raft 协议,恢复到 2 个 RTT。

怎么理解这里提到的冲突?

2. 软件行业没有银弹。fast path 能够比 slow path 节省 1 个 RTT,那它是怎么做取舍的?

1. 以 Xline 的 KV 操作为例,如果 client 并发地读写不同的 key,那么这两个操作是可以相互交换的,例如 client A 发起了 PUT X = 1 的请求,而 Client B 发起了 PUT Y = 2 的请求,那么这两个请求在 CURP 看来谁先执行谁后执行都不影响状态机的最终状态,我们称这两个操作为 commutative(可交换的)。如果两个 client 操作同一个 key,那么则需要看情况,如果两个请求都是只读请求,则依然满足 commutative 原则。而这两个请求如果其中包含了至少一个写请求,则不满足 commutative,因为对于读写操作,先读后写会读到旧值,而先写后读会读到新值,而对于写写操作,后写会覆盖先写的结果。如果在 fast path 中,接收到的所有操作都满足 commutative 原则,则成为无冲突;反之,在 fast path 中,接收到的若干个请求中,包含了至少一个不满足 commutative 原则的操作,则认为有冲突,fast path 会 fallback 到 slow path,需要 2 个 RTT 来达成共识。

2. Raft 算法之所以需要 2 个 RTT,主要是因为它必须同时满足持久化存储(过半数的副本)和有序这两个前提。client 只能和 master 通信,master 接收到请求后要执行 AppendEntries 操作,此时满足有序前提,请求会以 log index 的形式确定好唯一的顺序,再由 master 将这个顺序和命令一同复制到集群中的过半数节点,这就导致 2 个 RTT。CURP 弱化了假设,将有序和持久化存储分开到两个角色中,即 master 和 witness 中,其中 master 来确定命令的唯一执行顺序,而 witness 负责持久化(witness 中持久化的请求的执行顺序是无保证的)。它带来了一些取舍(架构设计上的复杂度,包括集群角色的增加,client 的请求发送方式,master retire 的复杂度等):

  1. Client 需要将请求发送给集群中的所有节点,包括了 master 和 witness,并且必须收到 f + 1 + ( f/ 2) 个成功请求,才能认为该命令成功被执行。client 需要发送的请求虽然增加了,但达成共识的 RTT 数缩小了
  2. Recovery 带来了一些额外的复杂性。对于已经完成同步的 master,crash 后的 recovery 和 raft 没有什么不同,只需要从副本处同步日志即可,但对于还没有完成同步的 master,crash 后的 recovery 除了同步日志外,必须要 replay 所有 witness 节点中持久化下来的非冲突请求
  3. Master demote 成为 follower 时,需要解决已执行但尚未持久化的请求的影响,因为这些影响可能会导致新 follower 上的日志副本与其他 follower 节点上的副本不一致。
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部