‘壹’ 什么是云存储技术
云存储是在云计算(cloud computing)概念上延伸和发展出来的一个新的概念，是指通过集群应用、网格技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的一个系统。 当云计算系统运算和处理的核心是大量数据的存储和管理时，云计算系统中就需要配置大量的存储设备，那么云计算系统就转变成为一个云存储系统，所以云存储是一个以数据存储和管理为核心的云计算系统。
云存储的两个层面
云存储的两个层面是作为云计算支撑的存储计算，主要涉及分布式存储(如分布式文件系统、IPSAN、数据同步、复制)、数据存储(如重复数据删除、数据压缩、数据编码)和数据保护(如RAID、CDP、快照、备份与容灾)等技术领域，如图8-30所示，这在第6章中已有所介绍。和云安全技术一样，云存储技术也需要利用现有的所有存储技术针对云计算三层架构的各个环节采用适当的存储技术，才能取得最佳效果，例如，对应不同需求，有时应该使用数据库技术但有时却应该使用LDAP技术，有些性能要求高的系统不能使用SAN或NAS，需直接使用基于RPC或Socket技术的并发文件系统，有些应用使用SAN成本太高等，这里不再做深入介绍。如图8-31所示是一个采用NetApp FAS、思科 UCS和 VMWare vShpere 4技术打造的存储系统，对上述两种云存储技术和应用都有促进作用。云存储架构
分为两类：一种是通过服务来架构;另一种是通过软件或硬件设备来架构。
传统的系统利用紧耦合对称架构，这种架构的设计旨在解决HPC(高性能计算、超级运算)问题，现在其正在向外扩展成为云存储从而满足快速呈现的市场需求。下一代架构已经采用了松弛耦合非对称架构，集中元数据和控制操作，这种架构并不非常适合高性能HPC，但是这种设计旨在解决云部署的大容量存储需求。各种架构的摘要信息如下：
紧耦合对称(TCS)架构
构建TCS系统是为了解决单一文件性能所面临的挑战，这种挑战限制了传统NAS系统的发展。HPC系统所具有的优势迅速压倒了存储，因为它们需要的单一文件I/O操作要比单一设备的I/O操作多得多。业内对此的回应是创建利用TCS架构的产品，很多节点同时伴随着分布式锁管理(锁定文件不同部分的写操作)和缓存一致性功能。这种解决方案对于单文件吞吐量问题很有效，几个不同行业的很多HPC客户已经采用了这种解决方案。这种解决方案很先进，需要一定程度的技术经验才能安装和使用。
松弛耦合非对称(LCA)架构
LCA系统采用不同的方法来向外扩展。它不是通过执行某个策略来使每个节点知道每个行动所执行的操作，而是利用一个数据路径之外的中央元数据控制服务器。集中控制提供了很多好处，允许进行新层次的扩展：
● 存储节点可以将重点放在提供读写服务的要求上，而不需要来自网络节点的确认信息。
● 节点可以利用不同的商品硬件CPU和存储配置，而且仍然在云存储中发挥作用。
● 用户可以通过利用硬件性能或虚拟化实例来调整云存储。
● 消除节点之间共享的大量状态开销也可以消除用户计算机互联的需要，如光纤通道或infiniband，从而进一步降低成本。
● 异构硬件的混合和匹配使用户能够在需要的时候在当前经济规模的基础上扩大存储，同时还能提供永久的数据可用性。
● 拥有集中元数据意味着，存储节点可以旋转地进行深层次应用程序归档，而且在控制节点上，元数据经常都是可用的。
‘贰’ 云计算时代操作系统Kubernetes之存储（中）
我们在POD中定义数据卷的时候，必须指定数据卷的类型。由于存储技术的发展远远早于Kubernetes平台的诞生，并且随着Kubernetes的日益流行，新的存储技术和方案也在日新月异，因此数据卷可以说理所当然的有很多很多类型，有些是通用的类型，而有些需要底层特定存储技术的支持，下边是Kubernetes支持的数据卷类型不完全清单：
- emptyDir类型，emptyDir类型的数据卷允许POD将数据保存到指定的文件夹中，并且数据在POD的整个生命周期中可见。保存数据的文件夹在POD启动前被创建，并且刚开始文件夹为空，这也是叫empty的缘由。
- hostPath类型，从宿主机的文件系统挂载文件到POD中。
- nfs类型，NFS类型的存储卷挂载到POD中。
- cephfs，cinder，fc等，用来支持不同类型的网络存储。
- configMap，secret，downwardAPI，以及projected类型，四种卷类型，用来将POD和Kubernetes的相关信息通过文件暴露给外部，这些卷类型主要用来配置应用程序。这几种类型笔者会在后续的文章中详细介绍。
- persistentVolumeClaim类型（PVC），一种轻量级的集成外部存储能力的方案。在这种类型的数据卷类型中，PersistentVolumeClaim类型的存储对象指向PersistentVolume类型的存储对象，真实的外部存储系统由PersistentVolume这个对象来引用。由于这是Kuberntes强烈建议大家使用的存储类型，因此笔者会在后续的文章中，单独来详细介绍。
- csi类型，一种通过CSI来扩展存储的方式。这种方式允许所有实现了CSI（Container Storage Interface）接口的存储实现能够被POD引用，在POD初始化的过程中，CSI驱动会将存储卷attach到POD上。
上边罗列的只是数量巨大存储卷类型中很小一部分，每种类型都有对应的使用场景。笔者在本篇以及后续的文章中，着重介绍最具代表性的几个类型，来帮助大家理解Kubernetes存储体系。首先我们从最简单的emptyDir类型开始，这种类型的数据卷用来在容器重启场景中保持状态。
还记得我们在前边文章中介绍如何在同一个POD中部署两个容器实例的例子吗？当时的做法是通过post-start hook来执行fortune命令产生一个名言警句写入文件中，运行在另外一个容器中的Nginx服务器由于挂载了相同的volume，因此会直接将这个信息返回给客户端请求。这个保存fortune产生的名言警句的文件在容器的文件系统中，这就意味着当容器由于liveness probe三次失败重启后，你会看到不同的名言警句，虽然说看起来问题不大，但是从原理上讲，数据由于容器重启丢失。
我们来验证一下上边的推理是否符合事实，请在自己的本地环境中部署yunpan-fs.yaml，然后执行kubectl port-forward yunpan-fs 1080:80来创建客户端代理，访问服务返回名言警句。然后通过命令让Nginx重新启动，重新访问服务，你可以看到两次返回的数据不一致，这就证明了保存在容器文件系统的数据，在容器重启的场景下，不会保持。在笔者的本地环境输出如下图：
如上图所示，重启容器后会产生新的名言警句，这就意味着容器重启后保存在文件系统中的数据丢失了。如果我们要在这种重启的场景中保持数据状态，那么就必须确保数据被保存在数据卷中，而emptyDir是解决这个问题的完美方案。当emptyDir类型的数据卷被挂载到容器中，应用写到挂载目录的数据文件，在容器重启后，能够继续保持。
emptyDir类型的数据卷可以让容器即便是重启后，可以让写到文件中的数据状态保持；或者容器的文件系统为只读，但是应用在运行的过程中，需要写状态到文件中等场景，我们也可以使用emptyDir类型的数据卷来在同一个POD的多个容器之前，进行数据共享。
废话不多说了，咱直接修改fortune pod来把post-start hook执行fortune命令返回的名言警句写到emptyDir类型的数据卷中，这样当容器重启后，就不会出现数据丢失了。我们其实要修改的地方不多，主要包括：1，给POD增加emptyDir类型的数据卷定义；2，在容器中将这个数据卷挂载到指定的目录。
另外我们对命令的执行进行了一点点优化，post-start hook会在每次容器启动后都会执行，因此我们需要防止重启后对fortune命令输出对已经存在文件的覆盖，因此我们对post-start命令脚本也做了优化，如下图所示：
注：post-start hook脚本被更新成"ls /usr/share/nginx/html/quote || (apk add fortune && fortune > /usr/share/nginx/html/quote)"，如果读者对Linux shell脚本不是很熟悉，这句肯定看的云里雾里，我们来稍微解释一下。首先ls命令先执行，我们这里用ls来检查quote文件是否存在，你有所不值得是，当ls后边给的文件存在的时候，命令返回0，而如果不存在，就返回非0。由于我们使用||将两个表达式进行了组合，因此当左边的ls quote执行成功，那么右边的语句就压根不会执行。通过这种方式，如果quote文件存在，那么咱就直接跳过了。而当文件不存在，才需要执行右边的一串命令，安装fortune和执行fortune来产生名言警句。这句脚本确保名言警句只被生成并写入一次，也就是只在容器第一次启动的时候。
如上图所示，我们定义了emptyDir类型的数据卷content，并挂载到nginx容器指定目录/usr/share/nginx/html（这个是Nginx服务器默认用来扫描静态资源的目录）。在POD中配置volume需要提供配置参数，接下来我们详细聊聊如何配置emptyDir类型的数据卷。
对于emptyDir类型的存储卷，Kubernetes要求配置如下两个属性：
- medium，文件夹的存储介质，如果留空不配置，那么默认就是宿主机的（工作节点）磁盘。除了磁盘之外，我们还可以配置Memory，这会导致数据卷使用tmpfs文件系统，这是一个在内存文件系统。
- sizeLimit，文件夹需要的磁盘空间大小，比如我们如果需要限制这个文件夹中文件的大小为10M，那么就可以设置为10Mi。
注：我们上边的例子中，emptyDir类型的数据卷content未显示的定义任何字段，取默认值，大括号非常明确的表达了这一点，但是并不是必须的。
在POD中定义完数据卷只完成了工作的一半，工作的另一半就是将数据卷挂载到容器实例中，这通过在容器spec.containers域通过volumeMounts来引用。volumeMounts除了要制定name之外，还需要包含mountPath字段，来指定数据卷被具体挂载到容器文件系统的文件目录树的那个路径。笔者上边提供的例子中，emptyDir类型的数据卷被挂载到了/usr/share/ngxin/html目录，因为这也是post-start hook将名言警句写到文件的路径。
由于使用了emptyDir类型的数据卷之后，名言警句被写入到了宿主机的文件系统，因此数据在POD的整个生命周期都会保持，因此我们无论重启nginx容器多少次，返回的数据（名言警句）都不应该有任何变化。
接下来，我们将这个新版本基于fortune命令的名言警句网站部署到Kubernetes集群，并人为的让nginx容器重启，你会发现无论我们重启多少次，quote接口返回的内容都一样。背后的原理是，因为我们只在容器第一次启动的时候，才创建quote文件，并且当容器重启重新挂载数据卷后，这个quote文件仍然存在。你可能会问，这个文件到底在宿主机的啥地方啊，可以运行kubectl exec yunpan-emptydir -- mount --list | grep nginx/html来发现，如下图所示：
如上图所示，通过使用emptyDir类型的数据局content，我们成功让容器重启之后，保持数据状态。接下来，我们继续看另外一个例子，如何通过数据卷在两个容器时间共享数据。
如笔者前边多次提到，我们也可以使用emptyDir类型的数据卷来在同一个POD中的两个容器之间共享数据，这里需要注意的是，我们无法通过emptyDir类型的数据卷在不同PDO中不同的容器间共享数据，请继续阅读。
我们基于fortune的名言警句网站目前略显无趣，因为每次都返回相同的谚语，我们希望这个行为能够增强，比如每30分钟更换一次。为了实现这个功能，我们需要将post-start hook替换成容器，并且在容器中，fortune命令每30秒运行一次。为了使大家学习更加容易，笔者已经构建好了需要的容器，并上传到Docker Hub，大家可以自行通过命令 docker pull qigaopan/yunpan-fortune:v1.0拉取。
好了，我们已经把需要的容器镜像都准备好了，接下来我们来编写POD的YAML文件，如下图所示：
如上图所示，emptyDir类型的数据卷被两个容器共享（共同挂载），容器fortune将数据写到content数据卷，在nginx容器中，相同的数据卷被以read-only的模式被挂载到nginx的默认目录。
注：我们在前边文章中反复强调过一个事实，同一个POD中的多个容器几乎是同时启动的，因此可能存在微小的一段时间，ngxin服务器已经成功运行起来，但是quote文件尚未生成。聪明的你可能想到了，要避免这种场景，我们可以使用初始化容器。
接着，我们将fortune POD部署到Kubernetes集群中，两个容器几乎同时开始运行。fortune容器每30秒更新一次谚语（名言警句），nginx容器基于相同的数据文件服务客户端请求，当POD中的两个容器都Ready后，可以验证一下输出，是否每30秒后，quote请求对应的谚语的返回会更新。
由于在fortune例子中emptyDir类型的数据卷会在宿主机的磁盘上创建共享目录，因此数据读写的性能，完全取决于工作节点上硬件的类型。如果我们的应用需要高性能的IO操作，那么磁盘可能不是最合适的存储介质。
Kubernetes允许我们使用tmpfs文件系统来创建数据卷，而tmpfs将数据保存在内存中，我们只需要在POD的YAML文件中，把emptyDir的字段meim设置为Memory。
其实Memory类型的数据卷除了提供较高的IO之外，数据安全性也比磁盘高。由于数据并没有落盘，因此数据不容易被恶意攻击者窃取，因此建议大家可以在自己的项目上考虑这种数据卷类型。另外我们也可以通过参数sizeLimit来约束数据卷的size，特别对于Memory类型的数据卷来说，请务必设置sizeLimit，以防内存被耗尽。
在前边的内容中，我们将目光主要集中在如何在POD中定义数据卷，而没有详细介绍volume是如何挂载到容器中的，接下来我们来看看在容器中挂载数据卷具体需要设置哪些参数。如下图所示，是我们在新版本的fortune POD定义中关于content数据卷挂载的配置：
从上图可以看出，挂载数据卷到容器中，我们需要至少配置两个字段：name和mountPath，其中name字段是我们在POD定义的数据卷的名字，而mountPath字段指定了数据卷应该挂载到容器文件系统的文件数的那个目录。
除了这两个必须提供的参数之外，我们还有一些可选的参数可以配置，详细的可配置参数清单如下：
- name字段，如笔者上边的介绍，name字段就是我们在POD中挂载的数据卷的name
- mountPath字段，前文应介绍，不累述
- readOnly字段，是否以只读的模式挂载数据卷，默认是false，也就是以读写的方式挂载数据卷。
- mountPropagation字段，设置如果在数据卷内部挂载额外的文件系统会发生什么。有几个选项，默认是none，指如果宿主机在数据卷中挂在了额外的文件系统，容器不会收到任何通知，反之亦然；还有两个选项HostToContainer和Bidirectional，具体含义如命名，如果要了解详情，可以参考官方文档。
- subPath字段，默认为“”，意味着整个数据卷都被挂载到mountPath指定的目录，当设置为非空的字符串后，只有subPath指定的文件路径被挂载到容器中
- subPathExpr字段，使用类似于shell提供的$(ENV_VAR_NAME)语句，只能使用环境变量。
在大部分场景下，我们只需要设置name和mountPath就可以了，顶多额外多配置参数readOnly。mountPropagation参数只有在一些复杂配置的场景下才会用到，当我们用一个数据卷来提供不同的文件夹给不同的容器的时候，subPath和subPathExpr非常有用。另外这两个参数也可以用作多个PDO共享一个数据卷的场景。
好了，这篇文章的内容就这么多了，下篇文章我们继续介绍存储，看看如何访问宿主机文件系统中的数据文件，敬请期待！
‘叁’ 请教：基于块存储和基于文件系统的存储
Ceph布式存储系统支持象文件快接口设计目标：
? 所组件横向扩展
? 没单点故障
? 普通厂商硬件使用
? 所机制都能自我管理
? 源
布式存储应用场景相于其存储接口现流行三种：
象存储： 通意义键值存储其接口简单GET,PUTDEL其扩展七牛、拍SwiftS3等
2.块存储： 种接口通QEMUDriver或者KernelMole式存种接口需要实现LinuxBlock Device接口或者QEMU提供Block Driver接口SheepdogAWSEBS青云云硬盘阿云盘古系统CephRDB（RDBCeph面向块存储接口）
3、文件存储： 通意义支持POSIX接口跟传统文件系统Ext4类型区别于布式存储提供并行化能力CephCephFS（CephFSCeph面向文件存储接口）候GFSHDFS种非POSIX接口类文件存储接口归入类
提存储种类提另外题：存储能做统化必须要同软件栈管理同存储设备：SSDSATA等
Ceph提同观点RADOS提供基础存储设备管理、数据控制流访问管理提供靠持久数据存储平台基于其我实现同接口户实现面向同需求接比象存储我单独库实现满足同存储需要比我块存储通RDP实现
统存储并意味着所存储都同接口同实现同软件栈其实使用同设备管理命周期数据访问效控制提供相合理非适合运维利于本利于软件靠性控制机制保证我存储靠
举例部存储厂商甚至网络厂商都自核软件栈文件系内核基于其演化各种同产品线厂商要追求各产品线极致应该每产品完全独立追求极致事实核底层技术栈需要高质量代码、完备测试期使用Ceph布式系统并发IO、布式恢复、数据端端校验等等关键实现唯实现熟系统系统些实现需要经定量级间考验才Ceph所谓统存储其接口堆叠式发
【Ceph其源布式存储、其商用存储区别处哪】
众所周知传统厂商立、富士通等存储厂采用Ceph作存储硬件载体Ceph能提供企业级存储服务定优势才能让传统存储厂商弃采用源存储案
1、化系统我认数据控制系统面做较迁移运维面提供较实现却元数据瓶颈访问数据需要经元数据服务器查询再寻找相应数据服务器规模扩展遇性能瓶颈问题
2、全布式系统虽提供较数据访问能力能高效处理客户端LO请求却没提供非数据控制实现比故障处理能力足数据恢复困难跳化元数据存储系统没办做强致性数据恢复
弹性数据布策略物理拓扑输入实现高用性高持久性Ceph高性能重构体现利用CRush算数进行约束避免数据布所集群节点利用Ceph设计并提供由CRush算支持高自由化存储集群设计实现高靠性高持久性高性能
‘肆’ 与云计算、云存储相关的IT技术都有哪些
云计算（Cloud Computing）是x0dx0a分布式计算（Distributed Computing）、x0dx0a并行计算（Parallel Computing）、x0dx0a效用计算（Utility Computing）、x0dx0a网络存储（Network Storage Technologies）、x0dx0a虚拟化（Virtualization）、x0dx0a负载均衡（Load Balance）、x0dx0a热备份冗余（High Available）等传统计算机和网络技术发展融合的产物。x0dx0a主要体现在虚拟化及其标准化和自动化。x0dx0a x0dx0a云存储是在云计算概念上延伸和发展出来的一个新的概念，是一种新兴的网络存储技术，是指通过集群应用、网络技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的一个系统。云计算系统中广泛使用的数据存储系统是Google的GFS和Hadoop团队开发的GFS的开源实现HDFS。x0dx0a x0dx0a从软件看，VMware、微软的Hpyer-V、Citrix以及开源的KVM等是主要的虚拟化平台，是云计算的基础。Citrix的优势在桌面虚拟化和应用虚拟化。x0dx0a至于云计算应用软件开发工具，并没有针对云计算、云存储的独特的编程语言。x0dx0a x0dx0a许多人会将云计算与大数据联系起来，其实两者既有联系又有区别。云计算就是硬件资源的虚拟化，主要是一虚多，充分利用高性能的硬件资源；而大数据就是海量数据的高效处理，通常需要多合一、或多虚一，跨越多台硬件处理海量数据任务。Amazon是云计算应用领域的先驱，而Google则是大数据应用领域的先驱。大数据既可以采用以虚拟化为基础的云计算架构也可以基于高性能计算（HPC，集群技术、并行技术）来处理。x0dx0a x0dx0a大数据相当于海量数据的“数据库”，而且通观大数据领域的发展也能看出，当前的大数据处理一直在向着近似于传统数据库体验的方向发展，Hadoop的产生使我们能够用普通机器建立稳定的处理TB级数据的集群，把传统而昂贵的并行计算等概念一下就拉到了我们的面前，但是其不适合数据分析人员使用（因为MapRece开发复杂），所以PigLatin和Hive出现了（分别是Yahoo！和facebook发起的项目，说到这补充一下，在大数据领域Google、facebook、twitter等前沿的互联网公司作出了很积极和强大的贡献），为我们带来了类SQL的操作，到这里操作方式像SQL了，但是处理效率很慢，绝对和传统的数据库的处理效率有天壤之别，所以人们又在想怎样在大数据处理上不只是操作方式类SQL，而处理速度也能“类SQL”，Google为我们带来了Dremel/PowerDrill等技术，Cloudera（Hadoop商业化最强的公司，Hadoop之父cutting就在这里负责技术领导）的Impala也出现了。x0dx0ax0dx0a因此，云计算、云存储均为计算资源的底层，通过虚拟化的方式提供“设备”级（或操作系统级）的服务，用户可以方便地申请使用”设备“来独立地实现自己的任务（就好像给你一台服务器），而实际上在云上提供给你的是一台虚拟机，至于这台虚拟机运行在哪台硬件设备上，却不一定，甚至可以”无缝“漂移，硬件故障时几乎不影响用户使用。
‘伍’ 云计算数据储存在哪里
云储存存在云计算系统中的存储设备中。
云存储是在云计算(cloud computing)概念上延伸和发展出来的一个新的概念，是一种新兴的网络存储技术，是指通过集群应用、网络技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的一个系统。当云计算系统运算和处理的核心是大量数据的存储和管理时，云计算系统中就需要配置大量的存储设备，那么云计算系统就转变成为一个云存储系统，所以云存储是一个以数据存储和管理为核心的云计算系统。简单来说，云存储就是将储存资源放到云上供人存取的一种新兴方案。使用者可以在任何时间、任何地方，透过任何可连网的装置连接到云上方便地存取数据。
‘陆’ 云计算架构
云计算架构主要可分为四层，其中有三层是横向的，分别是显示层、中间件层和基础设施层，通过这三层技术能够提供非常丰富的云计算能力和友好的用户界面，还有一层是纵向的，称为管理层，是为了更好地管理和维护横向的三层而存在的。下面介绍每个层次的作用和属于这个层次的主要技术。
显示层
这层主要是用于以友好的方式展现用户所需的内容，并会利用到下面中间件层提供的多种服务，主要有五种技术：
HTML：标准的Web页面技术，现在主要以HTML4为主，但是将要推出的HTML5会在很多方面推动Web页面的发展，比如视频和本地存储等方面。
JavaScript：一种用于Web页面的动态语言，通过JavaScript，能够极大地丰富Web页面的功能，最流行的JS框架有jQuery和Prototype。
CSS：主要用于控制Web页面的外观，而且能使页面的内容与其表现形式之间进行优雅地分离。
Flash：业界最常用的RIA(Rich Internet Applications)技术，能够在现阶段提供HTML等技术所无法提供的基于Web的富应用，而且在用户体验方面，非常不错。
Silverlight：来自业界巨擎微软的RIA技术，虽然其现在市场占有率稍逊于Flash，但由于其可以使用C#来进行编程，所以对开发者非常友好。
在显示层，大多数云计算产品都比较倾向HTML，、JavaScript和CSS这对黄金组合，但是Flash和Silverlight等RIA技 术也有一定的用武之地，比如VMware vCloud就采用了基于Flash的Flex技术，而微软的云计算产品肯定会在今后使用到Silverlight。
中间件层
这层是承上启下的，它在下面的基础设施层所提供资源的基础上提供了多种服务，比如缓存服务和REST服务等，而且这些服务即可用于支撑显示层，也可以直接让用户调用，并主要有五种技术：
REST：通过REST技术，能够非常方便和优雅地将中间件层所支撑的部分服务提供给调用者。
多租户：就是能让一个单独的应用实例可以为多个组织服务，而且保持良好的隔离性和安全性，并且通过这种技术，能有效地降低应用的购置和维护成本。
并行处理：为了处理海量的数据，需要利用庞大的X86集群进行规模巨大的并行处理，Google的MapRece是这方面的代表之作。
应用服务器：在原有的应用服务器的基础上为云计算做了一定程度的优化，比如用于Google App Engine的Jetty应用服务器。
分布式缓存：通过分布式缓存技术，不仅能有效地降低对后台服务器的压力，而且还能加快相应的反应速度，最着名的分布式缓存例子莫过于Memcached。
对于很多PaaS平台，比如用于部署Ruby应用的Heroku云平台，应用服务器和分布式缓存都是必备的，同时REST技术也常用于对外的接口， 多租户技术则主要用于SaaS应用的后台，比如用于支撑Salesforce的Sales Cloud等应用的Force.com多租户内核，而并行处理技术常被作为单独的服务推出，比如Amazon的Elastic MapRece。
基础设施层
这层作用是为给上面的中间件层或者用户准备其所需的计算和存储等资源，主要有四种技术：
虚拟化：也可以理解它为基础设施层的“多租户”，因为通过虚拟化技术，能够在一个物理服务器上生成多个虚拟 机，并且能在这些虚拟机之间能实现全面的隔离，这样不仅能减低服务器的购置成本，而且还能同时降低服务器的运维成本，成熟的X86虚拟化技术有 VMware的ESX和开源的Xen。
分布式存储：为了承载海量的数据，同时也要保证这些数据的可管理性，所以需要一整套分布式的存储系统，在这方面，Google的GFS是典范之作。
关系型数据库：基本是在原有的关系型数据库的基础上做了扩展和管理等方面的优化，使其在云中更适应。
NoSQL：为了满足一些关系数据库所无法满足的目标，比如支撑海量的数据等，一些公司特地设计一批不是基于关系模型的数据库，比如Google的BigTable和Facebook的Cassandra等。
现在大多数的IaaS服务都是基于Xen的，比如Amazon的EC2等，但VMware也推出了基于ESX技术的vCloud，同时业界也有几个 基于关系型数据库的云服务，比如Amazon的RDS(Relational Database Service)和Windows Azure SDS(SQL Data Services)等。关于分布式存储和NoSQL，它们已经被广泛用于云平台的后端，比如Google App Engine的Datastore就是基于BigTable和GFS这两个技术之上的，而Amazon则推出基于NoSQL技术的Simple DB。
管理层
这层是为横向的三层服务的，并给这三层提供多种管理和维护等方面的技术，主要有下面这六个方面：
帐号管理：通过良好的帐号管理技术，能够在安全的条件下方便用户地登录，并方便管理员对帐号的管理。
SLA监控：对各个层次运行的虚拟机，服务和应用等进行性能方面的监控，以使它们都能在满足预先设定的SLA(Service Level Agreement)的情况下运行。
计费管理：也就是对每个用户所消耗的资源等进行统计，来准确地向用户索取费用。
安全管理：对数据，应用和帐号等IT资源采取全面地保护，使其免受犯罪分子和恶意程序的侵害。
负载均衡：通过将流量分发给一个应用或者服务的多个实例来应对突发情况。 运维管理：主要是使运维操作尽可能地专业和自动化 ，从而降低云计算中心成本。
负载均衡：通过将流量分发给一个应用或者服务的多个实例来应对突发情况。
运维管理：主要是使运维操作尽可能地专业和自动化，从而降低云计算中心的运维成本。
现在的云计算产品在帐号管理，计费管理和负载均衡这三个方面大都表现地不错，在这方面最突出的例子就是Amazon 的EC2，但可惜的是，大多数产品在SLA监控，安全管理和运维管理等方面还有所欠缺。
举例
接下来，将以Salesforce的Sales Cloud和Google的App Engine这两个着名的云计算产品为例，来帮助大家理解本文所提到的云计算架构：
Salesforce Sales Cloud
也就是之前的Salesforce CRM(客户关系管理)，属于云计算中的SaaS层，主要是通过在云中部署可定制化的CRM应用，来让企业用户在很低初始投入的情况下使用上CRM，并且 可根据自身的流程来进行灵活地定制，而且只需接入网络就能使用。在技术层面上大致的架构：
采用的主要技术：
显示层：基于HTML、JavaScript和CSS这对黄金组合。
中间件层：在此层，Salesforce引入了多租户内核和为支撑此内核运行而经过定制的应用服务器。
基础设施层：虽然在后端还是使用在企业环境中很常见的Oracle数据库，但是其为了支撑上层的多租户内核做了很多的优化。
管理层：在安全管理方面，Salesforce提供了多层保护，并支持SSL加密等技术，除此之外，其还在帐号管理、计费管理和负载均衡这三方面有不错地支持。
Google App Engine
App Engine属于云计算中的PaaS层，其主要提供一个平台，来让用户在Google强大的基础设施上部署和运行应用程序，同时App Engine会根据应用所承受的负载来对应用所需的资源进行调整，并免去用户对应用和服务器等的维护工作，而且支持Java和Python这两种语言。由 于App Engine属于PaaS平台，所以关于显示层的技术选择由应用的自身需要而定，与App Engine无关，关于App Engine在技术层面上大致的架构。
采用的主要技术：
中间件层：既有经过定制化的应用服务器，比如上面已经提到过的Jetty，也提供基于Memcached的分布式缓存服务。
基础设施层： 在分布式存储GFS的基础上提供了NoSQL数据库BigTable来对应用的数据进行持久化。
管理层：由于App Engine是基于Google强大的分布式基础设施，使其在运维管理技术方面非常出色，同时其计费管理能做到非常细粒度的API级计费，而且App Engine在帐号管理和负载均衡这两方面都有非常好地支持。
以上内容分析源自OFweek物联网，希望对大家有帮助。