『壹』 什麼是雲存儲技術
雲存儲是在雲計算(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物聯網，希望對大家有幫助。