在前面几期，我们介绍的存储，都在块存储的范畴。
让我们先做一个简短的小结：
所谓的块存储，就是挂载到操作系统上，在操作系统看来，它是一个独立的磁盘，操作系统可以自建文件系统，或者以RAW Volume的方式提供给一些数据库软件(如万恶的Oracle)使用，有着和本地硬盘差不多的延迟，以及极高的可用性和数据持久性。
最初的块存储设备是FC SAN存储。在互联网与云计算时代，由于FC SAN存储在性能、扩展性和成本方面的局限性，基于x86标准存储节点和以太网/TCP-IP的分布式存储成为了企业级与运营级云存储的主流。
以Ceph为代表的开源分布式存储系统较好地解决了以下三个问题：
1、数据应当写入哪个节点的哪个磁盘；
2、单磁盘或单节点故障的时候应当如何保证数据不丢失，并恢复数据；
3、节点和磁盘数量扩容时，整个集群的IOPS与吞吐等性能关键指标大致随节点/磁盘数量而线性提升；
因此，Ceph成为了开源分布式存储的事实标准。
但由于Ceph难以解决以下三个问题：
1、如何提供99.9%以上的业务可用性；
2、如何充分利用分布式集群中所有磁盘的有效容量；
3、如何保证集群扩容时不增加集群分裂的概率；
因此，在企业级关键业务与运营级的块存储系统中，出现了以AWS EBS(Elastic Block Storage)，腾讯云CBS(Cloud Block Storage)为代表的脱离Ceph自行研发的块存储系统，能够提供更高的可用性、数据持久性和关键业务性能，可以用于虚拟机系统盘、核心数据库存储等场景。
以上小结了分布式块存储的实现和优势。
但，正如人无完人，年薪百万的程序媛有可能找不到对象，块存储也有着明显的劣势。
首先是成本。所有的分布式块存储，都至少基于三副本机制构建。(极少数不良云厂商为了节约成本，为客户提供基于纠删码的块存储，甚至在为客户私有化部署的专有云方案中提供这一实现，这是出于自身KPI考虑，对用户实施的PUA，本质上是对用户业务质量的极端不负责任，应当受到业界的共同谴责）这样一来，1PB的块存储需要3.3PB的裸磁盘。这对于部分非关键业务属于一种浪费。
其次是部署条件。虽然FC SAN存储需要购买昂贵的FC Switch已经即将成为历史，但无论是iSCSI还是通过QEMU的驱动直接挂载分布式块，都对网络时延与丢包有着很高的要求。这是由于，无论Linux还是Windows，所有的块/磁盘IO操作都是同步阻塞操作。如果前一个操作没有返回完成，QEMU的驱动会一直等待(俗称IO Hang)，甚至被视为挂死并触发看门狗重启。因此，如果期望使用网络远端的资源，是不能通过块存储的方式访问的。
此外，还有数据的版本管理问题。我们知道，无论是分布式块存储，还是早起的FC SAN块存储，都可以利用COW/ROW等技术，支持卷(LUN)的快照功能，但快照的颗粒度较大，是针对整个云盘的，而非单个文件或数据块，也不可能实现有效的版本管理。对于网页需要的图片、视频等非结构化数据难以有效的组织。
让我们举一个栗子。
子虚在方老师的辅导下成功入职某互联网大厂前端开发岗，年薪百万。
子虚发现，网页前端需要的一些图片、模板及视频等静态资源，如果放到CBS云硬盘上，那么，当这些静态资源需要跨AZ同步的时候，就非常麻烦了。
子虚的发际线开始疯狂后移……
在深圳，子虚这样年薪百万的程序媛们很多，她们找不到对象的原因主要有三点：
1、忙于研究如何克服块存储的这些劣势，没有时间找对象
2、头发掉得太厉害，快要秃了
3、觉得对象不如搞钱
怎么样能克服块存储的劣势，对于一些非关键应用，能够提供低成本，随处可访问，并且能够对数据版本进行有效管理的存储方案，帮助程序媛们解决时间问题和变秃问题，开心地找到对象呢？
当然是引入对象存储啦！
对象存储可以低成本地存储海量的对象，只要在网络可达的地方就可以随时从任意偏移量开始访问，还能对数据进行有效的版本管理，以及控制访问权限。有了对象存储，程序媛们就不愁没有时间找对象了！
我们推开了一扇通往新世界的大门，从下期起，我们将好好看看这个美丽的新世界……
