分层存储与虚拟化技术_百度百科
分层存储与虚拟化技术
本词条缺少信息栏，补充相关内容使词条更完整，还能快速升级，赶紧来吧！
分层存储（Tiered Storage），也称为层级存储管理（Hierarchical Storage Management），广义上讲，就是将数据存储在不同层级的介质中，并在不同的介质之间进行自动或者手动的，复制等操作。同时，分层存储也是的一个具体应用和实现。
随着信息技术的发展，新产生的电子数据近年来呈现出井喷式的增长，而这又带动着对于存储的大量需求。这种需求增长不仅仅限于企业用户，多媒体数据、邮件等个人信息也使得普通用户对于的需求也出现了明显的增长。当前PC的标准存储容量配置300G、500G已经是非常普遍的了。想象一下前几年配置容量为40G，60G的时代，甚至更往前到KB、MB的时代，似乎现在的机器容量配置实在是十分奢侈。我们不需要引用 IDC 对于存储市场的调查分析数据，我们都已经切身感受到自己似乎身处于电子数据宇宙中。
市场的发展推动需求的提高，并且催生新的需求，而这些变化及新需求又推动着技术的进步与变革。满足市场的需求无外乎在于对原有技术的深耕细作、组合升级原有技术、或者发明一种新的技术手段。而存储市场也不外乎这样的发展历程。需求、市场、变化推动着我们不得不重新思考原有技术实现，推动我们再深入研究不同的技术。而外部软、硬件技术的发展也使得我们可以以一种全新的应用方式来发展及深化这些技术，让这些技术生出春天般的生命力。
特别是虚拟化技术出现，则完全催生出一个全新的存储应用。同时，诸如这样新的存储应用及其他的需求，则促使我们对于存储分层技术及技术的进一步探索研究。
什么是分层存储
分层存储其实已经不是一个新鲜的概念，而是已经在计算机存储领域应用多年。其与计算机的发明与发展相伴相生。在冯－诺依曼提出计算机的模型“”时就已经包含了分层存储的概念。“”原理，是将根据特定问题编写的程序存放在计算机中，然后按存储器中的存储程序的首地址执行程序的第一条指令，以后就按照该程序的规定其他指令，直至程序结束执行。在这里的与，就是一个分层存储的最初模型。
分层存储（Tiered Storage），也称为层级存储管理（Hierarchical Storage Management），广义上讲，就是将数据存储在不同层级的介质中，并在不同的介质之间进行自动或者手动的，复制等操作。同时，分层存储也是的一个具体应用和实现。
而实际上，将相同成本及效率的存储介质放在不同层级之间进行复制在实用性及成本上并不是有效的方式。因此，在不同的层级之间使用有差别的存储介质，以期在相同成本下，既满足性能的需要又满足容量的需要。这种存储介质上的差别主要是在存取速度上及容量上。存取速度快的介质通常都是成本（每单位存储容量成本，如1元/GB）高，而且容量相对来讲比较低。相应的，存取速度慢的介质通常是为了满足容量与成本方面的要求，既在相同的成本下可以得到更大的容量。所以，从这方面来说，分层存储其实是一种在高速小容量层级的介质层与低速大容量层级的介质层之间进行一种自动或者手动、复制、管理等操作的一种存储技术及方案。
一般来说，分层存储中，我们将存取速度最快的那一层的介质层称为第0层（Tier 0），依次为第1层，第2层等等。理论上说，层级的划分可以有很多层，但是在实践中，最多的层级在5层左右。过多的层级会增加数据及介质管理的难道及可用性。因此在层级的设置上有一个拐点，即层级达到一个特定的层数时，会导致成本的上升，而使得可用性、可靠性都会相应下降。通常层级的设定在2－4层之间。如下图所示：
为什么需要分层存储
在中，CPU 的运行速度往往要比内存速度快上好几百倍甚至更多，为了更多地榨取CPU的计算能力，就需要在访问数据的速度上进行提升，否则内存的速度将成为整个系统的性能短板。因此在这样的思想下，CPU慢慢发展出来1级或者2级这样的存储缓存。实际也表明，缓存的存在确实对于系统性能的提升起到了巨大的推动作用。
相应的，内存的访问速度又是硬盘访问速度的几百倍甚至更多，也是基于CPU类似的指导思想，我们能不能在存储之间也进行这样的分层（或者说缓存）以期提高系统的I/O性能，以满足应用对系统提出的更多高I/O的需求呢？
从某种意义上说，内存其实也就是充当了CPU与外部存储之间的另一个级别的缓存。作为用户来讲，我们当然希望所有需要用到的数据都最好是存在最高速的存储当中。但是这样近乎是乌托邦式的理想至少在当前来说是不现实的。在技术上的难度不说，成本的压力就会使得用户喘不过气来，再一个就是有没有必要的问题，因为有的数据根本都不需要一直存于这样的存储中。在计算机界中有一个很有名的理论，就是说，加上一个中间层，就可以解决计算机中许多的问题。而这个“中间层”也正是我们所寻求的，实际也证明这样的中间层确实取得了非常好的效果。
据IDC数据预测，到2012年，信息数据的增长将会达到50%的复合年增长率，这个增长主要源于越来越来多数据内容生成并存储，经济全球化使用商业各个部门及与商业伙伴之间需要保持连接，使得更多的数据被生成，复制及保存。法规遵从及管理，还有与备份都使得数据的增长持续上升。天下没有一劳永逸的解决方案，我们需要根据不同的需求，设计不同的存储方案。比如归档，我们可以将在磁带上，比如需要频繁访问的实时数据我们可以放在内存或者SSD（）设备中，对于或者备份，我们可以使用大容量低成本的存储来应对。正所谓好钢用在刀刃上，用户也希望把资金投向更能产生效益的存储上。
除了需要满足不同的存储需求，还有出于对于高性能高吞吐量应用的支持。因为有的应用需要这样。特别是现在风头正劲的虚拟化技术。为了在一台设备上支持更多的，就需要系统支持更大的吞吐量以及更高的性能。全部采用高速介质在成本上现在依然不是可行的，也不是必须的。因为根据数据，往往被频繁访问的数据是局部而有限的。为了应对部份这样的数据而全采用高速存储实在是过于奢侈。如果我们针对这部份数据另开小灶来解决不是更好？所以分层存储在这里就可以大展拳脚。我们把高频率访问的数据放在高速存储介质上，而其他的数据放在速度较慢一些的介质上，这实际上就是提高了系统的吞吐量。
分层存储介质的分类
从角度来说，最上层的存储层应该是CPU内的各类型寄存器，其次是CPU内的，其次再是。因为从分层存储的定义上，此类型是符合定义规则的。因为这些速度与容量都有差别，越靠近CPU的存储器成本越高，速度越快，容量越小，并且在CPU的控制下，数据这些不同类型的存储器中间进行自动的转存。比如寄存器通常在16、32、64、128位之间，而则在几十个及到几兆字节之间，内存容量当前通常都在几百兆字节以上，服务器级的内存也上几十个。很有意思的是，这类型的分层也非常符合上图所示的效益成本曲线图。层级过多时，对于CPU的硬件设计及不同层次之间的的保证都是一个挑战。所以，现代CPU在与内存之间的基本在1-3级。而我们通常使用的386平台的CPU（Intel 及 AMD）基本上都只有两级。这类存储都有一个共同的特点，就是系统掉电后数据不复存在。我们将此类型的分层存储称为易失性存储分层，或者内部分层存储。
而另外一种分类，则是非易失性分层存储，或者叫外部分层存储。此类型的存储介质一般包括（SSD）、机械式硬盘、光盘、闪存盘（包括外置硬盘）、等等。而此类的存储介质分层正是我们所要关注的，如没有特殊的说明情况下，在此文档中所说的分层存储都是指外部分层存储。一般来说，作为第0层的存储介质通常为 RAM （随机访问存储磁盘，其速度与内存同速，但是价格昂贵，使用环境基本上是特殊计算环境）以及 SSD，第1层可能有 FC 15K硬盘或者SAS 15K硬盘，或者相应的10K硬盘。第2层可能有其他类型的硬盘及磁盘库等。第3层，可能是如以及这样的离线介质。当然这样的分层不是标准，但是一个实践中常用的分层策略。
如 D2D2T 这样的存储方案，其实就是分层存储的一个实践方案。数据从本地的磁盘转存于于另一个远程的磁盘（D2D）。这个的形式可以是一个JBOD，或者一个虚拟存储设备，然后再通过一定的转存策略将这个磁盘的数据转存于或者磁带（D2T）。存储柜X系列都支持D2D2T这样的应用。
分层存储需要考虑的问题
由上一节可知道，外部分层存储只不过是内部分层存储的一个外延。所以，外部分层存储考虑的问题与内部分层存储实际上是大同小异的。
首先是的问题。这个问题比较好理解。如果不同的数据在不同的存储层级之间存在时，数据的改写必然导致数据的不致的问题。在内部分层存储时，可以采用通写策略或者回写策略。而不同的方法也有各自优缺点，这里就不再赘述。但是外部分层存储与内部分层存储有一个最大的不同是，内存储最终数据需要写到内存中，而外分层存储中，则不是必须的。当然也可以设计成这样的实现方案，但是这样话，分层存储的性能优势则必定会受到影响。数据在不同层级之间的连续性可以由一个虚拟层来保证。这个我们在谈到虚拟化时会讨论这个问题。
第二个问题就是命中率的问题。如何设计一套算法或者实现策略来提高数据系统的命中率是分层存储中是否能起到其相应作用的关键。这个与CPU的缓存机制是完全一样的。不过，CPU的缓存机制已经有一套非常成熟的算法设计。而外部分层存储与内部分层存储有其不同的特性，因此，CPU中的缓存机制不能全部照拿过来用。特别是CPU的缓存机制还主要是硬件设计上面的问题。而外部存储层可能还与一些相关，比如文件系统，文件等。从这点上说，外部分层存储的软件设计上比起CPU缓存的设计可能要更复杂一些。
第三个问题就是在分层介质的选择上。上面也提过，不同层级之间的介质应该是有差别的，否则就失去了分层的意义。一般来说，高速介质应该是小容量、高成本，随着层级的往下走，其成本容量曲线应该呈现如下的形式：
　即容量越大的单位成本越低，速度越慢，因此应该放到更低的层级中，反之亦然。因此，在存储介质的配置上如何找到一个合适的点，使得成本与效益最优化则是在分层介质选择及策略制定上需要考虑的问题。下面的图中给出了一个实际的可能的配置方案：
第四个问题就是数据分层的级别。对于数据的描述有字节级，块级（包括及簇），文件级及文件系统级。当然不同的级别有不同的应用场合，并不是哪种级别好于哪个级别。对于文件级的分层，对于归档，法规遵从则比较适合。对于文件系统级的则多用于及备份系统中。对于块级则可能用在虚拟化中较为合适。因此需要根据不同的需求制定不同的分层级别。
第五个问题就是数据的迁移策略的设计。可以根据数据的重要性、访问频度、大小、年龄来制定迁移策略。但是如同第四点所说明的那样，不同的策略是有不同的应用场合的，没有孰优孰劣的问题。好的策略应该是不同最优策略的组合，也就是因“需”制宜地选择合适的迁移算法或者方法。根据年龄进行迁移的策略可以用在归档及系统中。根据访问频度则可以用于虚拟化中等等。类似的方法已经用于计算机软件设计或者硬件设计当中的很多地方，如LRU（最近最少使用）、ARC（自适应交替缓存）都是可以借鉴的。
存储虚拟化技术
什么是存储虚拟化
根据SNIA（Storage Networking Industry Association，中文译名为“存储网络联合会”）官方对于Virtualization（存储虚拟化技术）的定义，如下：
是将存储（子）系统内部功能与具体应用、主机及通用网络资源分离、隐藏及抽象的行为。以期达到存储或数据管理的网络无关性。
对于存储服务及设备的虚拟化应用，以期达到整合设备功能、隐藏复杂细节以及向已经存在的底层存储资源添加新的应用。
从上面的定义可以看到，虚拟化包括两层的含意，一个是动词，一个是名词。动词表明了如何来达到虚拟化，而名词则说明了应用的目的。对于当前数据的几何式增长以及带来的数据管理的复杂性，加之存储、备份及需求的发展，需要一个更高级的抽象，以此来获得应用的更大的灵活性。
虚拟化存储与是两个极易混用的概念，简单来说，存储虚拟化是指就是指的SNIA中的第一个定义，既将存储抽象;而虚拟化存储则是第二条定义，既是侧重于对存储虚拟化的应用。也就是与虚拟化存储是同一个概念（Virtualization）的两个面。因此为了避免在两者之间跳来跳去，在此文档中，都将这两个概念统一称为技术。当要特别指明是哪个面的时候，我们就直接使用相应的概念。
存储虚拟化技术的前世今生
与分层存储技术一样，技术是与计算机一起发展起来的概念。比如内存系统中的地址就是对于内存位置及其数据的一种抽象。这种抽象其实就是一种虚拟化。其次到外部存储器中，对于一开始使用（CHS）编址方式到的LBA编址方式就是一种技术，再到后来的RAID技术，再到分层存储都是在不同等级上的虚拟化。因此，虚拟化技术由来已久，只是在当前数据暴增的情况下，对于技术提出了更高层次的抽象要求，加上虚拟机技术也为这个概念推波助澜，使得存储虚拟化技术从深宫走向台前成为妇孺皆知的名词。
关于SNIA的共享存储模型
为了让终端用户与存储设备生产厂商能在同一个平台概念上进行讨论，SNIA 对于存储定义了一个SNIA共享存储模型，如下示：
　在上面的模型中，虚拟化技术可以在不同的层进行抽象。当然，在第一级的抽象中就有CHS以及LBA的编址方式。而每一个层都为上一层提供虚拟化接口。当然，最底层与最上层因为没有更下一层及更上一层，他们是这个模型中的两个端点。最底层永远为上一层提供虚拟化接口，而最上一则只使用其下一层的虚拟接口。
当前有许多的技术在不同层中对存储层中进行虚拟化，包括物理存储，RAID，LUN（Logical Unit Number），，LUN分区，LUN遮罩及影射，文件系统，。相应地实现这些虚拟化技术的设施有，阵列控制器，存储交换机，路由器，分布式，适配器，操作系统以及相应的应用层软件。这些不同的技术表明对于解决共有的存储问题，虚拟化是一个很关键的技术方向。
为什么需要存储虚拟化技术
随着技术的发展以及对于及管理的要求不断在提高，对于所提出的要求也自然水涨船高。比如达到100%的系统可用时间以及对于系统失效的能力，即系统的单点失效不会导致整个系统的瘫痪。而随着企业自身的发展及建设，企业内部的存储基础架构基本都是异构的平台。而这样的复杂性已经成为保证的障碍。而存储中此类型的诸多问题其实都可以通过存储虚拟化技术来解决：
在没有虚拟化技术的支持的情况下，SAN网络上单点的失效或者交换的失效是一个严重的问题，企业则为了保证存储的可用性及连续性不得不投入高昂的费用，以此来保证整个的可靠性。
存储中的性能是评价一个存储系统服务质量（QoS）的关键参数。在异构平台环境中，为了保证满足应用要求的存储性能是一个极为复杂的工作。技术使得在性能的保障上提供了实现可能性，也保证了可评估的QoS。
存储中的数据对于企业的日常的工作及生产都是至关重要的，对于数据的丢失所适成的损失对于一些企业来说可能就是一场灾难，而技术可以在这一方面大有所为。虚拟化技术则使得用户可以以可承受的成本代价得到高端的解决方法。
对于纯存储（）的需求的增长，导致了的应用效率变低。据调查在中对于存储的利用率，磁盘仅为30-50%，而磁带为 20-40%，也就是说，企业每买一个GB的同时需要多买2-3G的存储，产生这种低使用率的问题主要原因是存储与主机的绑定关系，为了保证每个主机都能正常工作，用户常常一次性分配大量的，而这些存储空间即使在未使用的情况下，也不能被其他的主机占用。而虚拟化技术可以提供这样的按需提供的功能，并且与分层存储结合在一起，可提供不同等级的服务质量。
存储虚拟化技术的分类
存储虚拟化技术根据不同的分类原则会有不同的类型。比如根据虚拟化实现在数据传输路径中的位置来分有带内与带外的虚拟化，根据虚拟化在栈中的位置可以分为磁盘虚拟化或者磁带虚拟化。又根据虚拟化的粒度则可以分为文件/记录型虚拟化，型虚拟化。由于与本文档主要讨论分层存储及虚拟化技术关系的原因，我们这里只关注于两种虚拟化类型，一是文件/记录型虚拟化，一个是块级虚拟化。
文件/记录型虚拟化
对于使用这个类型的虚拟化的一个非常典型的例子就是HSM，即层级存储管理，也就是此文档所说的分层存储。这种虚拟化技术自动地在不同的层级之间的存储之间进行，对于应用来说，这个过程是透明的。通过相应的指针及文件元数据，虚拟化存储层可以很方便在各层之间查找数据，并将数据返回给用户，而请求者不需要知道详细的文件物理位置，并且自动将用户的数据存于不同的存储层中，以释放相应的I/O吞吐量及，使得用户的投资得到保护，并且也提高了系统的总体性能。
近来这种虚拟化技术受到越来越多的关注，而这种虚拟化技术处于SNIA存储模型的第二层。此虚拟化技术处理的主要是块级存储的磁盘，而很多的厂商在提及块级虚拟化技术时指的就是这种技术。
在这种虚拟化技术的背后，其实就是很简单的思想：克服单个设备的物理限制而不需要影响用户及应用，因此后者只看到一个大的“”。当然，这种块聚集技术只是块虚拟化技术的一个方面，在这个虚拟化技术方案之中还有相当多可以提供的服务，如自动数据分层，空间自动按需配置，，卷复制，甚至是等。下面的图中显示了这种虚拟化技术的特点及结构：
　在上面的图中，对于存储的使用者只需要关注存储容量、性能以及可用性，而无需关注磁盘的物理特性。因此在这样的结构下，用户不需要与某个生产商绑定，因此可以做到存储的异构环境的整合，这种结构也极容易进行向上（增加容量及扩展设备）与向下（压缩容量及移除设备）的扩展。
存储虚拟化技术的实现
存储虚拟化技术由于类型众多，而它们所处于存储栈位置也不一样，因此其实现技术也相当的多，而且所关注的面也不一样。比如 RAID 技术其实就是基于存储设备的存储虚拟化技术实现之一，还有卷管理技术 LVM，包括 SoftRAID 也都是存储虚拟化的实现技术。作为与本文所讨论的存储分层存较为接近关系原因，我们这里重点介绍一下基于及存储设备的虚拟化技术的实现。而对于基于网络的虚拟化技术实现主要用于级的存储规划中。特别的，这三种实现技术可以同时结合起来，或者一个以另一个为基础来实现。
这种虚拟化技术是最常用的虚拟化技术之一。这种技术从桌面应用到的服务器上都存在，并且一般通常都与卷管理技术结合在一起。因为DAS的大量存在，并且卷管理技术已经是操作系统内置的一个功能。当然更高级的第三方的卷管理技术实现也是很常见的一种方式。这种技术的好处就是成熟稳定，并且开放。因此可用于各种异构的环境中。而缺点就是这个虚拟化技术是以服务器主机为中心的。所以，这个虚拟化技术必须以为单位进行实现。这使得将不同的存储系统整合成更大、更复杂的存储系统较为困难。因此，有的厂商提供所谓的集群卷管理技术，使得在异构的服务器中共享不同卷以并以单独卷的方式进行。
基于存储设备的虚拟化实现
其实这种虚拟化技术就是，但并不仅限于RAID，其中包括快照、LUN 遮罩以及影射等，这些实现技术都是块级虚拟化的实际例子。而这种技术同样适用于SAN以及DAS环境中。这种不依赖于特定的以及操作系统，通过调整与硬件设备相关一些特性，如Cache，就可以取得更好的性能。但这种虚拟化技术的缺点就是的应用只能限于在一个阵列里，不能做到跨阵列进行存储的管理与整合。
通常的情况下，上面的两种虚拟化方式都是组合在一起使用的，使得虚拟化技术即有基于主机的的灵活性，也通过基于存储的虚拟化取得性能上的好处。比如在阵列中的数据可以通过条带化将数据分布在不同的设备上，这样读写性能就会得到相应的提高。如果以基于的虚拟化技术将卷建立在这样的中，马上就可以得到性能上的提升。诸如此类的结合也说明虚拟化技术的实现不会以单独的形式出现，而是多种虚拟化技术的相互补充。
存储虚拟化的未来
统一管理。这个统一管理包括数据发掘、、存储虚拟化以及存储自动化。在一个异构的存储世界里，这样的方法可以给各个层次，从到物理存储层的存储提供统一的活动管理。而正是用户的期望的也是虚拟化技术所要解决的问题。正如Eisoo(爱数)的All-In-One-Web技术就已经成为统一管理的一个缩影。在此基础之上实现存储的管理，数据的管理，以及备份等应用的大一统格局。但无论是基于Web 的或者其他形式的统一管理，都将是存储虚拟化技术所追求的一个方向及未来的愿景。
自动。存储虚拟化技术的进一步发展会使用服务变得普遍。这种发展趋势既是技术上的也是成本上的。在技术上讲，这样的数据服务提供了及高性能数据访问能力。当感知到已经无法再满足用户或应用的存储需求时，则需要迁移或者复制到其他的更快、容量更大的设备上。从成本上的观点来看，并不是所有的数据对于企业来讲都是同等重要，一些老旧的数据一般来讲其价值并不需要用户将其一直保存在高昂的存储设备中。这样，这个数据就需要从昂贵的存储上迁移到低成本的存储设备上。这个过程不再需要用户的干预，而是由自动完成。
级的卷及文件系统。如果一个卷指派给不同的系统进行同时数据访问，有些问题就需要特别注意以保证数据的一致性。一个简单的解决方法就是实现一个集群文件系统，由这个集群文件系统来管理不同服务器对于数据的访问。而当前的情况下这些文件系统都是在同构的环境实现的。为了使得这个集群文件系统成为可能就需要对不同的操作系统及其对卷中存储的使用以及文件系统都要进行虚拟化。
作为一个应用系统之内技术实现及概念，往往并不是孤立地存在。作为存储技术来说，分层存储与也是相互交叉、互为因果的一种关系。分层存储的实现需要的支撑，这样才能将分层的实现与具体应用分离。而虚拟化技术的实现又有分层技术的影响。正所谓独木不成林，要打造一个稳定、高效、易扩展的存储应用系统，必定是十八般武艺齐上阵。技术与分层技术的发展与应用，必将给存储行业造成深远的影响。1706人阅读
标准Web系统的架构分层
– 转载请注明出处
1、架构体系分层图
在上图中我们描述了Web系统架构中的组成部分。并且给出了每一层常用的技术组件/服务实现。需要注意以下几点：
系统架构是灵活的，根据需求的不同，不一定每一层的技术都需要使用。例如：一些简单的CRM系统可能在产品初期并不需要K-V作为缓存；一些系统访问量不大，并且可能只有一台业务服务器存在，所以不需要运用负载均衡层。
业务系统间通信层并没有加入传统的HTTP请求方式。这是因为HTTP请求-响应的延迟比较高，并且有很多次和正式请求无关的通信（这在下面的内容中会详细讲到）。所以，传统的HTTP请求方式并不适合在两个高负载系统之间使用，其更多的应用场景是各种客户端（WEB、IOS、Android等）-&服务器端的请求调用。
我们把业务编码中常使用的缓存系统归入到数据存储层，是因为类似于Redis这样的K-V存储系统，从本质上讲是一种键值数据库。为什么Redis会很快以至于可以作为缓存使用，我将在随后的文章中进行详细的描述。
还有一点需要注意的是，上面架构图中的每层之间实际上不存在绝对的联系（例如负载层一定会把请求转送的业务层，这样的必然性是不存在的），在通常情况下各层是可以跨越访问的。举例说明：如果HTTP访问的是一张图片资源，负载层不会把请求送到业务层，而是直接到部署的分布式文件系统上寻找图片资源并返回。再比如运用LVS做Mysql负载时，负载层是直接和数据存储层进行合作。
2、负载分配层
实际上负载均衡的概念很广泛，所述的过程是将来源于外部的处理压力通过某种规律/手段分摊到内部各个处理节点上。在日常生活中我们随时随地在和负载技术打交道，例如：上下班高峰期的车流量引导、民航空管局的航空流量管制、银行柜台的叫号系统。
这里我们所说的负载分配层，是单指利用软件实现的计算机系统上的狭义负载均衡。一个大型（日PV一亿+）、中型（日PV一千万+）Web业务系统，是不可能只有一个业务处理服务，而是多台服务器同时进行某一个相同业务的服务。所以我们需要根据业务形态设计一种架构方式，将来自外部客户端的业务请求分担到每一个可用的业务节点上。如下图所示：
负载层还有一个作用，是根据用户的请求规则，将不同的请求类型分派到不同的服务器上。例如：如果某一个HTTP请求是请求一张图片，那么负载层会直接到图片存储介质上寻找相应的图片；如果某一个HTTP请求是提交的一张订单，那么负载层会根据规则将这张订单提交发送到指定的“订单服务”节点上。
不同的业务需求，使用的负载层方案也是不同的，这就考验架构师的方案选择能力。例如Nginx只能处理TCP/IP协议的之上应用层HTTP协议，如果要处理TCP/IP协议，则要按照第三方的TCP-Proxy-Module模。更好的直接在TCP/IP层负载的方案，是使用HAProxy。
常用的负载层架构方式包括：
- 独立的Nginx负载或HAProxy方案
- LVS（DR）+ Nginx方案
- DNS轮询 + LVS
+ Nginx方案
- 智能DNS（DNS路由） + LVS + Nginx方案
随后的文章中将详细介绍这些负载架构方案以及这些方案的变形。
3、业务服务层和通信层
通俗来讲就是我们的核心业务层，订单业务、施工管理业务、诊疗业务、付款业务、日志业务等等。如下图所示：
很明显在中大型系统中，这些业务不可能是独立存在的，一般的设计要求都会涉及到子系统间脱耦：即X1系统除了知晓底层支撑系统的存在外（例如用户权限系统），X1系统不需要知道和它逻辑对等的X2系统的存在就可以工作。这种情况下要完成一个较复杂业务，子系统间调用又是必不可少的：例如A业务在处理成功后，会调用B业务进行执行；A业务在处理失败后，会调用C业务进行执行；又或者A业务和D业务在某种情况下是不可分割的整体，只有同时成功才成功，其中有一个失败整个大的业务过程都失败。如下图所示：
这样一来业务间的通信层又是一个逃不开的话题。 在随后的文章中，我们将以Alibaba的Dubbo框架、基于AMQP协议的消息队列和Kafka消息队列技术的原理和使用方式，来讲解业务通信层技术，特别是业务通信层的技术选型注意事项。
3.2、不得不提的HTTP请求方式
有的读者可能会问，为什么业务系统间通信层没有提到HTTP这样的调用方式。毕竟很多公司目前都采用这种方式作为业务系统间的调用方式。我们首先通过一个图来看看HTTP方式的调用过程。（注意，此过程不考虑http客户端缓存的过程也不考虑DNS域名解析的过程，从HTTP建立可靠的TCP连接开始）：
从上图中我们可以看出以下几个问题：
从技术原理层面看，HTTP请求是在需要进行调用时建立TCP连接，并且发送并等待数据回送，在得到请求结果后，可能需要再关闭这个TCP连接。这样的原理使得很多时间浪费在和业务无关的技术特性上。
另外，发送Head信息和接收Head这样的数据，对业务数据来说是毫无意义的。在访问量较小的情况下，这样的过程都还是可以接收的，但是当带宽资源吃紧的情况下，这样的数据空间就是弥足珍贵的。
独立的HTTP请求由于没有SOA结构中的“治理中心”的概念，所以单纯的HTTP请求很难保证负责业务联动中的上下文一致性。当然你可以自行编码来保证，但那样真的合理吗？
最后，需要说明的是，现在类似Apache HTTP Components这样的组件提供了HTTP Pool来减少TCP连接时长，但这仅仅是优化了HTTP作为业务间通信时的一个问题，其他的问题依然存在。
基于以上的描述，本文并不推荐使用HTTP作为业务间通信/调用的方式，而建议HTTP方式仅限于WEB、iOS、Android等这样的客户端请求服务的方式。
4、数据存储层
数据存储将是这个系列文章中将要介绍的另一个重点。进行业务计算前的初始数据、计算过程中的临时数据、计算完成后得到的计算结果都需要进行存储。我们通过一张思维导图首先从几个维度阐述一下数据存储的基本分类。
4.1、文件存储原理
我们通过一个最基本的在Centos6.5系统上创建Ext4文件系统的过程，讲解文件系统的最基本原理。
首先我们会通过fdisk命令对本地硬盘进行分区（即确定可控制的扇区的范围），如下图所示：
然后我们会在这个区上面通过mkfs命令创建我们想要的文件系统（Ext3、Ext4、LVM、XF、BTRFS等），如下图所示：
最后我们挂载这个文件系统到指定的路径，如下图所示：
通过df命令查看挂载信息，如下图所示：
万变不离其宗的创建过程告诉我们一个什么事实呢？
物理块，一个物理块是我们上层文件系统能够操作的最小单位（通常为512字节），一个物理块在底层对应了多个物理扇区。通常一块SATA硬盘会有若干机械手臂（决定于物理盘片数量），和若干个物理扇区（物理扇区的大小是磁盘出厂时就确定的，我们无法改变）。
单个扇区的工作是单向的，那么映射出来的一个物理块的工作方式也是单向的。原理就是机械手臂在读取这个扇区的数据时，硬件芯片是不允许机械手臂同时向这个扇区写入数据的。
通过上层文件系统（EXT、NTFS、BTRFS、XF）对下层物理块的封装，OS是不需要直接操作磁盘物理块的，操作者通过ls这样的命令看到的一个一个文件也不需要关心这些文件在物理块的存储格式。这就是为什么不同的文件系统有不同的特性（有的文件系统支持快照，有的文件系统支持数据恢复），基本原理就是这些文件系统对下层物理块的操作规范不一样。
4.2、块存储和文件存储
上一小节我们叙述了最简单、最原始的物理块和文件格式规范的工作方式，但是随着服务器端不断扩大的数据存储容量的需求和数据安全性的需求，很显然单机的存储是没办法满足要求的，目前存储环境两种大的需求类型是：
稳定的扩展存储容量，并且不破坏目前已存储的数据信息，不影响整个存储系统的稳定性。
文件共享，让多台服务器能够共享存储数据，并且都可以对文件系统进行读写操作。
要解决这两个问题，我们首先要将问题扩展到上一小节的图例中，如下图所示：
很明显图中两个问题的答案是肯定的，也就是我们将要介绍的块存储系统要解决的问题。
4.2.1、块存储系统
我们先来聊一下块存储。之前我们提到的最简单的情况就是磁盘在本地物理机上，传输的物理块I/O命令，也是通过本地物理机主板上的南桥进行的。但是为了扩展更大的磁盘空间，并且保证数据吞吐量，我们需要将磁盘介质和本地物理机分离，并且让物理块的I/O命令在网络上进行传输：
虽然磁盘介质和本地物理机发生了分离，但是直接传输块I/O命令的本质是没有改变的。本地南桥传输I/O命令变成了光纤传输，只在本物理机内部传输I/O命令变成了网络传输，并且I/O命令通过某种通信协议进行了规范（例如FC、SCSI等）。
文件系统的映射却是在本地进行，而非远程的文件系统映射。上文中我们已经提到，由于块操作的顺序性（在一个扇区进行写入的时候，是不会进行这个扇区的读取操作的），且块操作属于底层物理操作无法向上层的文件逻辑层主动反馈变化。所以多个物理主机是无法通过这个技术进行文件共享的。
块存储系统要解决的是大物理存储空间、高数据吞吐量、强稳定性的共存问题。作为上层使用这个文件系统的服务器来说，它非常清楚，除了它以外没有其他的服务器能够对专属于它的这些物理块进行读写操作了。也就是说它认为这个庞大容量的文件存储空间只是它本地物理机上的存储空间。
当然随着技术的发展，现在已经有一些技术可以只用TCP/IP协议对标准的SCSI命令进行传输，以便减小这个块存储系统的建设成本（例如iSCSI技术）。但是这种折中方式也是以减弱整个系统的数据吞吐量为代价的。不同的业务需求可以根据实际情况进行技术选型。
4.2.2、文件存储系统
那么如果是将文件系统从本地物理机通过网络移植到远程呢？当然可以，典型的文件存储系统包括了FTP、NFS、DAS：
文件存储系统的关键在于，文件系统并不在本机。而是通过网络访问存在于远程的文件系统，再由远程的文件系统操作块I/O命令完成数据操作。
一般来说诸如本地文件系统NTFS/EXT/LVM/XF等是不允许直接网络访问的，所以一般文件存储系统会进行一层网络协议封装，这就是NFS协议/FTP协议/NAS协议（注意我们说的是协议），再由协议操作文件存储系统的服务器文件系统。
文件存储系统要解决的问题首要的文件共享，网络文件协议可以保证多台客户端共享服务器上的文件结构。从整个架构图上可以看到文件存储系统的数据读写速度、数据吞吐量是没办法和块存储系统相比的（因为这不是文件存储系统要解决的首要问题）。
从上面的简介中我们可以清楚的知晓，当面对大量的数据读写压力的时候，文件存储系统肯定不是我们的首要选择，而当我们需要选择块存储系统时又面临成本和运维的双重压力（SAN系统的搭建是比较复杂的，并且设备费用昂贵）。并且在实际生产环境中我们经常遇到数据读取压力大，且需要共享文件信息的场景。那么这个问题怎么解决呢？
4.3、对象存储系统
兼具块存储系统的高吞吐量、高稳定性和文件存储的网络共享性、廉价性的对象存储就是为了满足这样的需求出现的。典型的对象存储系统包括：MFS、Swift、Ceph、Ozone等。下面我们简单介绍一下对象存储系统的特点，在后面的文章中，我们将选择一款对象存储系统进行详细说明。
对象存储系统一定是分布式文件系统。但分布式文件系统不一定是对象存储系统
我们知道文件信息是由若干属性进行描述的，包括文件名、存储位置、文件大小、当前状态、副本数量等信息。我们将这些属性抽离出来，专门使用服务器进行存储（元数据服务器）。这样一来文件操作的客户端要访问某一个文件，首先会询问元数据节点这个文件的基本信息。
由于是分布式系统，那么数据一致性、资源争夺、节点异常问题都需要进行统一的协调。所以对象存储系统中一般会有监控/协调节点。不同的对象存储系统，支持的元数据节点和监控/协调节点的数量是不一致的。但总的趋势都是“去中心化”。
OSD节点（基于对象的存储设备）用于存储文件内容信息。这里要注意，虽然OSD节点的底层和块存储底层一样都是依靠块I/O进行操作的，但是上层构造两者完全不同：OSD节点并非向块存储设备那样，通过块操作命令跳过本地文件系统直接进行物理块操作。
随后的文章中我们将选择一款流行的对象存储系统，详细剖析对象存储系统，并且对分布式存储系统中三个核心概念和取舍进行说明（CAP）：一致性、扩展性和容错性。
4.3、数据库存储
这篇文章已经写了很多存储层的概要描述了，所以我们熟悉或者不熟悉的数据库存储技术的概述就不在这里介绍了。
后续的文章我将使用Mysql讲解几个常用的架构方案和性能优化点，当然也会讲到Mysql中，诸如Innodb这样的核心数据引擎的工作方式。这些架构方案主要解决的是Mysql的单机I/O瓶颈、机房内数据容灾、数据库稳定性、跨机房数据容灾等核心问题。
后续的文章我还会选取目前流行的数据缓存系统，讲解其工作原理、核心算法和架构方案。以便读者们根据自己的业务情况设计符合业务的存储集群。当然还有非关系型数据库Cassandra、HBase、MongoDB的深入介绍。
5、评价架构的特性
我们如何来评价一个服务系统的顶层设计是否优秀呢？抛开八股文式的扩展性、稳定性、健壮性、安全性这样的套话不说。我从实际工作中为大家总结了一下几个评价要点。
5.1、建设成本
任何系统架构在进行生产环境实施的时候，都是需要付出建设成本的。显然各个公司/组织对成本的承受度是不一样的（这些成本包括：设计成本、资产采购成本、运维成本、第三方服务成本），所以如何利用有限的成本建设出符合业务需求、适应访问规模的系统，就是一个复杂的问题。另外，这种要求下架构师是不能进行过度设计的。
5.2、扩展/规划水平
根据业务的发展，整个系统是需要进行升级的（这包括已有模块的功能升级、合并已有的模块、加入新的业务模块或者在模块功能不变的情况下提高数据吞吐量）。那么如何尽量不影响原业务的工作，以最快的速度、最小的工作量来进行系统的横向、纵向扩展，也就是一个复杂的问题了。好的系统架构是可以在用户无任何感觉的情况下进行升级的，或者只需要在某些关键子系统升级时才需要短暂的停止服务。
5.3、抗攻击水平
对系统的攻击肯定是瞄准整个系统最薄弱的环节进行的，攻击可能来自于外部（例如Dos/DDos攻击）也可能来自于内部（口令入侵）。好架构的系统不是“绝对不能攻破”的系统，而是“预防很好”的系统。所谓预防，就是预防可能的攻击，分阶段对可能遇到的各种攻击进行模拟；所谓隐藏，就是利用各种手段对整个系统的关键信息进行涉密管理，ROOT权限、物理位置、防火墙参数、用户身份。
5.3、容灾恢复等级
好的架构应该考虑不同等级的容灾。集群容灾，在集群中某一个服务节点崩溃的情况下，集群中另外一台主机能够接替马上接替他的工作，并且故障节点能够脱离；分布式容灾：分布式系统一般会假设整个系统中随时都在发生单点故障/多点故障，当产生单点故障/多点故障时，整个分布式系统都还可以正常对外提供服务，并且分布式系统中的单点故障/多点故障区可以通过自动/人工的方式进行恢复，分布式系统会重新接纳它们；异地容灾（机房等级容灾）：在机房产生物理灾难的情况下（物理网络断裂、战争摧毁、地震等），在某个相隔较远的异地，备份系统能够发现这样的灾难发生，并主动接过系统运行权，通知系统运维人员（根据系统不同的运行要求，可能还有多个备份系统）。异地容灾最大的挑战性是如何保证异地数据的完整性。
5.4、业务适应性水平
系统架构归根结底还是为业务服务的，系统架构的设计选型一定是以服务当前的业务为前提。在上文中提到的业务通信层中，选择SOA组件还是消息队列组件，又或者选择什么样的消息队列，就是一个很好的业务驱动事件。例如，A业务是一种WEB前端服务，需要及时反馈给客户操作结果，B业务的服务压力又非常大。A业务在调用B业务时，B业务无法在毫秒级的时间内返回给A业务调用结果。这种业务场景下可以使用AMQP类型的消息队列服务。另外说明两点，目前行业内有很多为解决相同业务场景存在的不同方案，架构师在进行方案选型的过程中，一定要对各种解决方案的特点足够掌握，这样才能做出正确的选择；另外行业内的解决方案已经足够多，架构师在业务没有特殊要求的情况下一定不要做“ 重复发明轮子”的事情。
5.5、维护难易程度
一套服务系统从架设之初就需要运维团队不断的进行投入。显然根据系统的复杂程度和物理机器的数量，运维团队的知识复杂性也是不一样的。在架构师进行顶层架构设计时，必须还要考虑系统的运维难度和运维成本。
6、其他说明
负载层、业务层、业务通信层、数据存储层的详细架构方案在后续文章中我们会用若干文章进行深入讲解，包括核心算法、架设原理、架设案例。随后的文章中我们将首先介绍系统负载层。
在很多系统中我们还涉及存储的数据进行分析，形成数据分析结果。这涉及到数据分析层的架构知识。Hadoop生态系统是目前行业公认的高效率、高稳定性、高扩展性的数据分析生态系统。这个系列的博文暂时不会介绍数据分析层的架构设计和开发知识，后续将会独立成文。
各位看官我们马上进入负载层技术的详细讲解！
版权声明：欢迎转载，但是看在我辛勤劳动的份上，请注明来源：http://blog.csdn.net/yinwenjie
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：22135次
排名：千里之外
原创：26篇
评论：100条
阅读：4893
阅读：6323