OSD节点（基于对象的存储设备）用于存储文件内容信息 。这里要注意，虽然OSD节点的底层和块存储底层一样都是依靠块I/O进行操作的，但是上层构造两者完全不同：OSD节点并非向块存储设备那样，通过块操作命令跳过本地文件系统直接进行物理块操作 。
随后的文章中我们将选择一款流行的对象存储系统，详细剖析对象存储系统，并且对分布式存储系统中三个核心概念和取舍进行说明（CAP）：一致性、扩展性和容错性 。
数据库存储
这篇文章已经写了很多存储层的概要描述了，所以我们熟悉或者不熟悉的数据库存储技术的概述就不在这里介绍了 。
后续的文章我将使用Mysql讲解几个常用的架构方案和性能优化点，当然也会讲到Mysql中，诸如Innodb这样的核心数据引擎的工作方式 。这些架构方案主要解决的是Mysql的单机I/O瓶颈、机房内数据容灾、数据库稳定性、跨机房数据容灾等核心问题 。
后续的文章我还会选取目前流行的数据缓存系统，讲解其工作原理、核心算法和架构方案 。以便读者们根据自己的业务情况设计符合业务的存储集群 。当然还有非关系型数据库Cassandra、HBase、MongoDB的深入介绍 。
评价架构的特性我们如何来评价一个服务系统的顶层设计是否优秀呢？抛开八股文式的扩展性、稳定性、健壮性、安全性这样的套话不说 。我从实际工作中为大家总结了一下几个评价要点 。
建设成本
任何系统架构在进行生产环境实施的时候，都是需要付出建设成本的 。显然各个公司/组织对成本的承受度是不一样的（这些成本包括：设计成本、资产采购成本、运维成本、第三方服务成本），所以如何利用有限的成本建设出符合业务需求、适应访问规模的系统，就是一个复杂的问题 。另外，这种要求下架构师是不能进行过度设计的 。
扩展/规划水平
根据业务的发展，整个系统是需要进行升级的（这包括已有模块的功能升级、合并已有的模块、加入新的业务模块或者在模块功能不变的情况下提高数据吞吐量） 。那么如何尽量不影响原业务的工作，以最快的速度、最小的工作量来进行系统的横向、纵向扩展，也就是一个复杂的问题了 。好的系统架构是可以在用户无任何感觉的情况下进行升级的，或者只需要在某些关键子系统升级时才需要短暂的停止服务 。
抗攻击水平
对系统的攻击肯定是瞄准整个系统最薄弱的环节进行的，攻击可能来自于外部（例如Dos/DDoS攻击）也可能来自于内部（口令入侵） 。好架构的系统不是“绝对不能攻破”的系统，而是“预防很好”的系统 。所谓预防，就是预防可能的攻击，分阶段对可能遇到的各种攻击进行模拟；所谓隐藏，就是利用各种手段对整个系统的关键信息进行涉密管理，ROOT权限、物理位置、防火墙参数、用户身份 。
容灾恢复等级
好的架构应该考虑不同等级的容灾 。集群容灾，在集群中某一个服务节点崩溃的情况下，集群中另外一台主机能够接替马上接替他的工作，并且故障节点能够脱离；分布式容灾：分布式系统一般会假设整个系统中随时都在发生单点故障/多点故障，当产生单点故障/多点故障时，整个分布式系统都还可以正常对外提供服务，并且分布式系统中的单点故障/多点故障区可以通过自动/人工的方式进行恢复，分布式系统会重新接纳它们；异地容灾（机房等级容灾）：在机房产生物理灾难的情况下（物理网络断裂、战争摧毁、地震等），在某个相隔较远的异地，备份系统能够发现这样的灾难发生，并主动接过系统运行权，通知系统运维人员（根据系统不同的运行要求，可能还有多个备份系统） 。异地容灾最大的挑战性是如何保证异地数据的完整性 。
业务适应性水平
系统架构归根结底还是为业务服务的，系统架构的设计选型一定是以服务当前的业务为前提 。在上文中提到的业务通信层中，选择SOA组件还是消息队列组件，又或者选择什么样的消息队列，就是一个很好的业务驱动事件 。例如，A业务是一种WEB前端服务，需要及时反馈给客户操作结果，B业务的服务压力又非常大 。A业务在调用B业务时，B业务无法在毫秒级的时间内返回给A业务调用结果 。这种业务场景下可以使用AMQP类型的消息队列服务 。另外说明两点，目前行业内有很多为解决相同业务场景存在的不同方案，架构师在进行方案选型的过程中，一定要对各种解决方案的特点足够掌握，这样才能做出正确的选择；另外行业内的解决方案已经足够多，架构师在业务没有特殊要求的情况下一定不要做“ 重复发明轮子”的事情 。
