高手问答云计算时代下，云厂商帮我们解决了计算和存储资源的维护与拓展问题，但用户也面临被厂商绑定的问题。
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 高手问答一贯的风格，不欢迎任何与主题无关的讨论和喷子。
下面欢迎大家就编程语言设计与开发相关的问题向施继成老师提问，直接回帖提问既可。
高手问答第 296 期 —— 天空计算到底是不是云计算的未来？
@某人gmgn3 @osc_32324621 @pyboy58 @屮殖 @zerolemon
恭喜以上5位网友分别获得《Rust 实战》书籍一本。
请于02月16日12：00前登陆账号， 私信@OSC哒哒 告知快递信息（格式：姓名+电话+地址），逾期视为自动放弃哦~
@达坦科技DatenLord Rust 和 天空计算 都是我关注的内容。没想到今天可以放到一起。不过我有点可能杞人忧天的担心：就是国内“分联网”，国外“给你断网”的这种操作下，是否会带来跨运营商实际操作的难度？各个厂商对天空计算的支持态度如何？以及，我层设想的，将发布后台数据量少但是要求算力大的计算放在自建的廉价本地机房以避免干线机房的大额费用的思路，是否还有多少必要性？或者有没有其它更好的解决方案？
@达坦科技DatenLord 请问云原生是什么意思吗？
@达坦科技DatenLord 1.Rust语言如何入门开发?
2.天空计算相较于云计算的优势, 这种混合云的开发, 例如华为云,腾讯云,或者私有云的类的自己不是也可以开发吗?
3.Xline 如何做到低时延跨云数据交互? Rust的Xline 相当于JAVA的什么??
@达坦科技DatenLord 你好，请问你们在选择分布式协议的时候，比如我们知道有Paxos算法，Raft算法以及其他实现像zookeeper的zab这么多实现，你们最后选用的是哪个，还是自研的，又是怎样的考虑呢？
如果你们选用了raft，又是怎么克服它自身的缺点的呢？比如性能问题
谢谢
@达坦科技DatenLord 我们一直有做云平台的设备数据存储和计算功能，但是面对海量设备数据状态信息时，经常考虑的是使用数据库优化的方案，以及简化接口传输内容，进行优化。
在程序运行方面，rust或者云计算，能否提供对应的类似微服务的功能业务
@达坦科技DatenLord
1. 请问前面的回答中提到了“在无冲突情况下(fast path)，Curp 协议能比 Raft 协议或者 Paxos 协议节省 1 个 RTT。在有冲突的情况下（slow path），Xline 中的 Curp 能够退化为 Raft 协议，恢复到 2 个 RTT”。怎么理解这里提到的冲突？
2. 软件行业没有银弹。fast path 能够比 slow path 节省 1 个 RTT，那它是怎么做取舍的？
@达坦科技DatenLord
1. 请问前面的回答中提到了
怎么理解这里提到的冲突？
2. 软件行业没有银弹。fast path 能够比 slow path 节省 1 个 RTT，那它是怎么做取舍的？
@达坦科技DatenLord 我想问一下使用 Rust 开发的跨云 KV 数据库的优势是什么？
引用来自“osc_32324621”的评论
@达坦科技DatenLord
1. 请问前面的回答中提到了
怎么理解这里提到的冲突？
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 的复杂度等）：