阿里云存储技术的演进，以及云服务用例最佳实践

问题导读

1.云计算对客户最大的价值是什么？
2.为什么阿里云（包括其他大型公共云平台）要选择自己从头开发整个底层软件?
3.阿里云存储在发展过程中遭遇过哪些坑？是如何解决的？

2013年4月的QCon北京会场上，阿里云计算产品总监倪浩带来了主题为《阿里云计算的实践》的分享。在分享中，倪浩介绍了阿里云的服务体系，技术路线的选择，着重介绍了弹性计算和存储技术的演进，并且在最后介绍了使用阿里云服务的一些最佳实践。

InfoQ编辑从本次分享中获取到一些有意思的信息如下：

云计算对客户最大的价值是什么？

成本不是关键。事实上，使用云计算有时候反而要比较贵，但是盯着省钱不如盯着赚钱。灵活性（可快速变化）和简单性（易于操作）使得云计算能够更好的为客户交付更多的价值，这才是云计算最大的价值。

为什么阿里云（包括其他大型公共云平台）要选择自己从头开发整个底层软件，而没有在现成的OpenStack、CloudStack、Eucalyptus、Hadoop、MongoDB等开源软件的基础上构建？

对于阿里云这样规模的业务而言，如果采用各种开源技术拼凑起来的方案，会缺乏主线的控制力，而且拼凑的过程一点都不简单。同时，各种软件几乎不可能共享集群的资源。

阿里云存储在发展过程中遭遇过哪些坑？是如何解决的？

云存储系统的业务特点在于大量的随机IO，擦写十分频繁。

阿里云的存储系统，到目前经历过三个阶段。

第一个阶段是最原始的：所有的VM访问基于RAID的共享存储。RAID本身并不是为了这种大量随机读写的情景设计的，同时因为RAID的数据都在本地，一旦宕机是无法迁移的。

第二个阶段采用了异步同步的思路：VM过来的运行时读写先进入本地存储，同时以扇区为单位，异步向KVEngine做同步，KVEngine挂在（append）阿里的分布式文件存储系统（盘古）上。这样做的好处是可以取巧的利用（不支持随机读写的）飞天盘古的数据冗余，万一本地宕机可以通过KVEngine中的数据在另一台机器上恢复；但是，KVEngine异步同步数据仍然有丢失的可能。

第三个阶段是：支持随机IO的分布式存储系统。跟之前的append-only不同，这是基于盘古实现的Random Access File（RAF）。其实现的思路是：

• Master-slave，Master负责元数据管理，Slave（Chunk Server）负责读写
• 基于Paxos协议的多Master架构
• 分片（文件切成chunk存入Chunk Server），冗余（每个chunk存三个副本）
  

整个方案最大的挑战在于：如何保持数据一致性。这是所有分布式存储系统面临的最大问题，从理论到实现都非常复杂。

阿里云的服务类型很多，如何选择才能效果最优？

优化云服务用例的根本原则在于：知道每个服务都被设计好做一件事情。

因此，每个服务都有自己的优势，也有自己的陷阱。

比如，阿里云目前提供了不同的存储服务：

• 开发存储服务(OSS)
• 开放结构化数据服务(OTS)
• 关系型数据库服务(RDS)
  

未来还会提供Cache/Queue/CDN等。当然，云服务器（ECS）本身也带有存储。

• 使用ECS的存储当然可以，但如果你的读写很重，把压力转移到OSS、OTS或RDS上才是正途。
• OSS相当于一个带宽不受限、空间不受限、并发不受限的在线存储
• OTS适合不需要关系型操作的结构化数据
• RDS具备优越的读写性能（FusionIO），但总数据量要小于1TB
  

网络方面，负载均衡（SLB）提供HTTP和TCP，分别在不同的层面，需要考虑好自己的业务适合在哪一层做。同时，按月购买的服务器的带宽限制是完全的上行带宽（从服务器流出的带宽），下行带宽（流入服务器的带宽）是千兆规格，相当于没有限制。

这个很有必要了解下  多谢分享！~

不错的，了解了。