突然發現，很多公司一夜之間變戲法似的迅速的推出了自己基於雲的業務系統:比如儲存雲，或者基於雲環境的資料倉儲等。似乎凡是冠以雲的名義的系統便更有技術含量，能狠狠的吹噓一番，賺足眼球。但是什麼才叫真正的雲呢，它和傳統的集群系統有何差別呢？因為雲的定義目前可謂是眾說紛紜，未有定論
——從而任你如何標榜大概都無可厚非。
得了，具體商業上如何定義雲我們暫且迴避不論了，這裡把注意力僅僅集中到雲的實現架構特徵上來，嘗試**一下目前雲系統和傳統分布系統、集群系統的異同，從而了解雲技術基礎架構的某些特質，進一步談談將現有系統移植到雲上需要注意的地方。
我在另一篇文章中提到過，雲計算的基礎架構發軔於（其實就是）分布儲存，平行計算，網格計算等老技術。這些技術的共同點顯而易見：都是為了滿足海量資料和海量結算，而利用計算機集群這種橫向擴充套件方法將資料分布或者計算任務分布到多台機器上，達到協作完成任務的目的。
要說到雲和傳統集群的區別除了商務上的服務方式創新外，最大的特點是其執行環境有別於傳統集群！當前雲計算初衷的執行環境被認為是廉價普通pc伺服器，而且往往是異構機器——其儲存部件多是sata硬碟，而非高階磁碟陣列；使用的處理器也不會是numa體系的多核，而多是使用smp體系多核。簡而言之，「雲」並非代指高階執行環境，而恰恰相反它暗示著在「弱環境」（暫且叫它弱環境吧）中執行的服務。相對而言，傳統的集群系統——如並行資料庫等設計的執行環境很多是在專業伺服器上完成，而且是同構的一批機器。請別忽視這種看似簡單的區別，其實正是這種區別決定了雲計算架構設計的很多策略。
下來我們具體來分析一下，弱環境中集群系統設計要考慮的一些問題。如果你想將原來的某個系統（如以前在專有硬體上執行的）移植到雲環境中執行，那麼你首先需要很清楚得知道弱環境下需要解決那些問題。
「弱環境」首先要考慮的是廉價機器的異常故障情況要遠多於專有硬體平台，所以集群系統設計必須充分考慮到機器異常情況。其次，還需要考慮異構環境的速度不匹配問題，這對並行任務執行影響不小。
我們具體來看：
1 對於集群中的儲存由於沒有專門的磁碟陣列（一般都支援raid），而且由於系統可靠性不高，因此往往設計上需要使用軟體方式實現多副本儲存，已提高資料的安全性（當然也起到了負載均衡作用）。比如當前雲環境中比較流行的gfs檔案系統，dynamo儲存系統都是如此。
2 對於集群資料計算（比如並行資料庫）等，需要盡可能的將任務劃分，且要中間結果持續化，以避免某個處理節點故障後，由於沒有中間資料，而不得不把整個計算任務重頭再做——在專有環境下，節點故障率要低很多，因此各個節點之間常使用pipeline等形式傳送中間結果，不會將中間結果落地，這樣做無疑效能更高，但是如果遇到處理節點故障則需要從頭翻工—— 當前雲計算中hadoop的map/reduce任務便是這種設計，map的中間結果落地。
3 對於異構機器來說——即便採用虛擬化技術，由於排程等原因，同一宿主機上的各同配置虛擬機器執行效能也有不小的差別——所以雲中各任務執行速度差異顯著，因此往往需要跟蹤發現執行緩慢的任務，以便把任務排程到更快節點上重新做，或者進行任務遷移等。目前hadoop已經實現了此種特性，可見其充分考慮了異構集群執行能力差異問題。而我們知道很多設計在同構機器上執行的並行資料庫，並不會重排程或任務遷移，因此當到雲這種異構環境執行時，任務的最終執行會被最慢的那個拖累，造成整個任務執行效能下滑。
4 弱環境中的程式設計更合適於對等網，也就是說集群中沒有特殊節點，都是對等的，比如dht架構的儲存網。這種無單點的集群結構，對故障容忍度更高。當然這個不是絕對的，hadoop，bigtable等雲服務屬於master/salve結構，系統中存在master單點，因此部署時最好對單點進行ha考慮，比如多部署幾個做熱備。
5 弱環境最大的優點是成本優勢，裝置便宜、通用，因此實現橫向擴充套件很經濟。執行於雲的集群最好能充分利用這種擴充套件成本優勢，將系統設計成易於動態擴充套件的高可用性系統（可用性設計要有好的故障轉移機制，這裡不多講）。如何設計易於擴充套件系統呢，目前最普遍的方式莫過於share-nothing架構。這種結構不同於分層架構,它需要將請求接受、處理和儲存等都處於乙個節點內完成（不一定是乙個物理機器，可以只是乙個虛擬執行容器），這樣以來各個點之間被解偶，不相互依賴，因此可以很容易的進行線性擴容。dynamo系統，teradata並行資料庫等都屬於這種架構。
這節我們談談假如把乙個已有的集群系統移植到雲環境，可能要做哪些工作。我們假定移植目的地是amazon的ec2平台上，需要移植的系統假定是teradata這種並行資料庫。
第一： 硬體需要軟體化 --- amazon提供的ec2平台是使用虛擬化技術按需提供的虛擬機器，你可在這些虛擬機上安裝各種軟體（預先製作好其虛擬機器映象），但是並未允許你將特殊硬體引入其環境。而teradata並行資料庫中，聯接各計算點的資料匯流排（bynet）採用的是硬體裝置，如果需要移植到ec2中則需要將其軟體化——利用軟體實現這種資料匯流排。
第二：teradata的資料儲存是利用磁碟陣列完成，而雲環境並沒有這種磁碟陣列。所以這時需要找到替代方法。最直接就是採用amazon的ebs服務——掛載外部儲存磁碟到ec2系統上，這樣可做軟raid方案來代替磁碟陣列。（這裡可能會有乙個小問題，就是teredata架構裡vproc單元的故障轉移策略是：當某個vproc發生故障後，另一太機器上的vproc會接替其處理請求，這就要求它能訪問故障點對應的虛擬盤。而amazon目前ebs服務，不允許乙個虛擬盤同時掛載到多個例項上。而teradata的故障轉移機制需要多個vproc掛載同乙個或一組虛擬盤上。不過這個問題不大，似乎amazon正在解決）。
第三：將pe處理點和vproc處理點等都做為ec2的例項進行部署即可。比如每個pe部署在乙個ec2虛擬機器上，而vproc也部署在不同的虛擬機器上。
當完成以上步驟後，便可以將類似teradata這種並行資料庫集群移植到amazon提供的公共雲中進行服務。當然如果要提供更可靠和高效的服務，那麼上一節提到的那些弱環境集群設計要求都應該充分考慮。
如果要移植的是網際網路程式則相對容易許多，一般可採用如下步驟進行
1 將靜態網頁，等內容可存入
s3系統。
2 將應用程式和
web server
等安裝到
ec2的例項上。這裡如果處理量大則需要部署成集群。這是自然也需要考慮到雲中的虛擬機器故障，也就是要設計故障轉移策略等。不過部署在
amazon
雲中有乙個很大好處，你可以選擇跨地區部署伺服器，以提高容錯性。比如在美國和中國都進行部署，則將風險分散。
3 將資料儲存層移植到
aws雲中。如果使用的是關聯式資料庫（
mysql
、postgress
）等，就需要利用
ebs服務來做後台儲存體，將關聯式資料庫服務程式安裝到
ec2例項中。同樣道理你也必須自己設計資料冗餘機制，以便防止某點故障時資料不丟，且可進行不間斷服務。
但是如果你更激進一些，採用
aws提供的
******db
這種多維對映表代替關聯式資料庫，那麼所有的冗餘設計都交給了
******db
——而******db
則有良好的擴充套件性，效能和可用性。但它沒有關聯式資料庫那種關聯查詢等操作，因此如果你想使用它，那麼你的
程式設計就要避免關聯查詢（關於
******db
的特性請去
吧）。
總結：雲計算是不是未來趨勢現在來講還維持尚早，但無可否定它的確帶來了許多新奇、精彩的系統，如
hadoop
、hive、s3
、******db
。但從技術角度講仍然未有實質性變革，而更多是各種已有技術的取捨和組合。本文僅做拋磚引玉，希望能結識熱衷雲計算技術的朋友，一同交流提高。
從做題來看計算機的思維
還有五天就到軟考的日子了，經過這段時間，一早一晚，還有零星的上班時間的準備，要比2018年上半年參加的那次軟考更有信心了些，希望自己能過，也不做必須過這樣的強制了，結果對我來說雖說是重要的，但重要的還是使自己能夠補全自己在計算機方面的知識體系 這才是參加軟考的意義。2019年11月3日晚 這次不過，...
從資源取用的角度理解雲計算
從資源取用的角度理解雲計算 從資源取用的角度理解雲計算，主要可以從四個方面進行解讀，具體如下 硬體和軟體都是資源，通過網路以服務的方式提供給使用者。在雲計算中，資源已經不限定在諸如處理器機時 網路頻寬等物理範疇，而是擴充套件到了軟體平台 web服務和應用程式的軟體範疇。傳統模式下自給自足的it運用模...
雲計算 Linux從入門到精通 阿里雲大學的部落格
linux是一套免費使用和自由傳播的類unix的的作業系統，是乙個基於posix和unix的多使用者，多工，支援多執行緒和多cpu的作業系統。它能執行主要的unix工具軟體，應用程式和網路協議。它支援32位和64位硬體.linux繼承了unix的以網路為核心的設計思想，是乙個效能穩定的多使用者網路作...