Salesforce的簡介

在雲端計算方面，Salesforce 可以稱為業界的領袖，它不僅在產品方面比較成熟，而且在思維方面也是引領潮流的，特別是在SaaS（Software as a Service，軟體即服務）和PaaS（Platform as a Service，平臺即服務）這個兩個領域內。

圖1. Salesforce 商標（圖源自Salesforce.com）

首先，簡要地介紹一下Salesforce的歷史：Salesforce.com在1999年由前甲骨文高管 Marc Benioff 創立，他創辦Salesforce的核心理念就是”No Software（消滅軟體）”，但是其意義並不是排斥所有的軟體，而是主要排斥執行在企業資料中心的軟體（On-Premise Software），也就是希望讓使用者能直接通過網際網路來諸如CRM等軟體服務，並同時讓使用者無需自己搭建和維護軟體所需的硬體和系統等資源。Salesforce的主要產品包括Sales Cloud（CRM）、Service Cloud、Chatter和Force.com等。下面是它的主要發展史：

• 1999年，Salesforce在美國舊金山成立。
• 2001年，推出了第一款SaaS應用CRM，同時也受到眾多廠商和客戶的熱議。
• 2004年，Sunguard成為Salesforce第1000位使用者。
• 2005年，推出了名為”AppExchange”的程式商店，以豐富使用者選擇。
• 2006年，推出了首個執行在雲端計算平臺的語言Apex，並在語法上類似Java。
• 2007年，推出了它的PaaS平臺Force.com，來讓使用者更方便地在Saleforce平臺上開發線上應用，同時Salesforce憑藉Force.com得到了華爾街日報的科技創新獎（Technology Innovation Award）。
• 2009年，Salesforce成為首家年收入達到10億美元的雲端計算公司，並在年初推出了名為”Service Cloud”線上客戶服務應用。
• 2010年，Salesforce將推出名為”Chatter”的企業級線上SNS服務，類似於企業內部的”LinkedIn”，同時其CRM應用已更名為”Sales Cloud”。

Salesforce的整體架構

雖然Salesforce這些產品從表面而言有所不同，但是從全域性而言，它們卻是一個整體，具體可看下圖：

圖2. Salesforce的整體架構 （圖部分源自Salesforce.com）

從這張Salesforce的整體架構圖可以看成，Force.com 是 Salesforce 整體架構的核心，因為它首先整合和控制了底層的物理的基礎設施，接著給上層的Sales Cloud，Service Cloud，Chatter和基於Force.com的定製應用提供PaaS服務，最後，那些Force.com上層的應用以SaaS形式供使用者使用。這樣做的好處主要有兩方面：其一是關於成本的，因為通過這個統一的架構能極大地整合多種應用，從而降低了在基礎設施方面的投入。其二是在軟體架構方面，因為使用這個統一的架構，使得所有上層的SaaS服務都依賴Force.com的API

雖然Salesforce的”Sales Cloud”等SaaS應用也比較經典，但由於Force.com堪稱整個架構的核心，同時也是最值得的學習和借鑑的部分，所以本系列接下來將會把重點對準Force.com。

Force.com

Force.com是Salesforce在2007推出的PaaS平臺，並且已經有超過47000位企業已經使用了這個平臺。Force.com基於多租戶的架構，其主要通過提供完善的開發環境等功能來幫助企業和第三方供應商交付健壯的，可靠的和可伸縮的線上應用。

圖1. Force.com 商標（圖源自參[3]）

總體而言，Force.com主要有五方面功能：

• 強大的定製功能：在Force.com，不僅UI能夠定製，而且諸如Workflow和表格等也能被定製。
• 提供完善的開發環境：首先，通過Visualforce能方便地使用”Drag & Drop”的方式來設計頁面。其次，Salesforce提供基於Eclipse的IDE來快速地開發應用。最後，Salesforce還提供Sandbox來方便使用者測試。
• 支援複雜的事務和流程：通過Force.com專屬的APEX語言，能方便地設計和開發複雜的事務和流程。
• 優秀的整合功能：使用者除了可以在AppExchange購買其所需的功能和應用，而且還可以通過Force.com的Web Service介面來和其他應用整合，比如SAP等。
• 久經考驗的基礎設施：由於Salesforce除了通過在多個大洲建有資料中心來應對災難的發生，而且在可用性和安全性等方面也有一定積累，所以在Salesforce能長時間地支援眾多服務的正常執行。

多租戶的簡介

概念

雖然對我們而言，多租戶(Multitenancy)可以算是一個非常新穎的概念，但是其實這個概念已經由來已久了。簡單而言，多租戶指得就是一個單獨的軟體例項可以為多個組織服務。一個支援多租戶的軟體需要在設計上能對它的資料和配置資訊進行虛擬分割槽，從而使得每個使用這個軟體的組織能使用到一個單獨的虛擬例項，並且可以對這個虛擬例項進行定製化。但是要讓一個軟體支援多租戶並非易事，因為不僅對它的軟體架構進行相應的修改，而且需要對它的資料庫結構進行特殊的設計，同時在安全和隔離性方面也要有所保障。

還有，為了幫助大家進一步理解多租戶這個概念，特別選取兩個和多租戶比較接近的概念來進行進一步的辨析。

多租戶和多使用者的區別

多使用者的關鍵點在於不同的使用者擁有不同的訪問許可權，但是多個使用者共享同一個的例項。而在多租戶中，多個組織使用的例項各不相同。

多租戶和虛擬化的區別

多租戶和虛擬化在概念是比較類似，都是給每個使用者一個虛擬的例項，並且都支援定製化，但是它們作用的層次不同：虛擬化主要是虛擬出一個作業系統的例項，而多租戶則是主要虛擬出一個應用的例項。

優缺點

多租戶的優點：

• 經濟：因為通過一個軟體例項被多個組織共享，從而減低了整體資源的消耗，也同時減低應用執行的成本和相應的管理開支。
• 易於更新和開發：因為所有組織都共享同一套核心程式碼，所以能夠讓軟體更新和開發更簡單。
• 管理方便：首先，通過使用了多租戶架構能減少物理資源和軟體資源，這將簡化管理。其次。由於多租戶軟體主要由有經驗的雲供應商運營，所以能依賴那些非常經驗的管理人員來提升效率。

多租戶的缺點：

• 更復雜：由於一個軟體需要做出極大地修改，才能支援多租戶架構，而且這種修改，往往會增加整個軟體在架構方面的複雜性。
• 不夠安全：因為眾多組織的應用和資料共享同一套軟體和基礎設施，如果出現機器宕機，軟體出現問題或者大規模的資料被暴露等情況，將會造成更嚴重的後果，因為影響面更大。

幾種模型

在現有的實現中，主要有三種常見的模型，而且區別主要在於採用不同的資料庫模式（Database Schema）：

• 私有表（圖1-a）：它是最簡單的擴充套件模式，就是為每個租戶的自定義資料建立一個新表。優點是簡單。缺點是涉及到高成本的DDL操作，並且它的整合度不高。
• 擴充套件表（圖1-b）：總體而言，比較類似於私有表，但是一個擴充套件表會被多個租戶共享，所以無論是共享表還是基本表都會有租戶欄位。好處是比私有表更高的整合度和更少的DDL操作，但是在架構上比私有表更復雜。
• 通用表（圖1-c）： 主要通過一個通用表來存放所有自定義資訊，裡面有租戶欄位和許許多多統一的資料欄位（比如500個）。像這種統一的資料欄位會使用非常靈活的格式讓轉儲各種型別的資料，比如VARCHAR。由於在每一行中的資料欄位都會以一個Key一個Value形式存放所有自定義資料，導致通用表的行都會很寬，而且會出現很多空值，所以通用表這種方式也被稱為”Sparse Column”。好處是極高的整合度並避免了DDL操作，但是在處理資料方面難度加大。

圖1. 多種模式（圖源自參[7]）

差異與取捨

在實戰中，具體選擇那個模型，主要還是看那個模型更適合。

Force.com的多租戶架構

由於Force.com所負載的應用不論是在定製方面的靈活性上，還是所承受的負載上，對基於多租戶的架構而言，都是史無前例的，導致之前提到的一些模型或者改動已經無法滿足要求了，所以Salesforce在Force.com引入了通過Metadata（元資料）驅動的多租戶架構來動態生成快速的，可伸縮的和可定製的應用。接下來，將一步步為大家揭開Force.com多租戶架構的神祕面紗，首先是它的總體架構。

總體架構

在介紹Force.com的整個架構之前，請看下圖，此圖是根據Salesforce首席架構師Craig Weissman在2009年舊金山QCon大會上的演講總結而成。

圖1. Force.com的架構圖

首先，在最前面是Gateway（閘道器），閘道器將接受所有訪問Force.com的請求，無論它是訪問Sales Cloud，還是關於第三方定製程式的。接下來，閘道器會根據這個請求所屬的租戶把請求轉發給對應的POD，什麼是POD？簡單的來說，POD就是一組叢集伺服器，每個POD都運行同一套Force.com系統，而且每個POD支援成千上萬個租戶，Salesforce總共有10多個POD來支撐它所有服務的運營，並把所有租戶平衡地分配給每個POD，而且主要通過建立新的POD來支撐新的租戶。當POD收到請求之後，POD會先通過其內建的Load Balancer（負載均衡器）來將請求轉發給負載略輕的App Server（應用伺服器），由於為了簡化架構和方便伸縮（Scale），所以應用伺服器是Stateless（無狀態），而且在一個POD內會有多個應用伺服器以應對大規模的請求。最後，當應用伺服器在處理請求的時候，如果發現請求所需的資料沒有被Cache住的話，應用伺服器會呼叫這個租戶所屬的Shared DB（共享資料庫）來取得相關資料，雖然共享資料庫是使用成熟的Oracle資料庫產品，但是在資料庫表的設計上面為多租戶做了很多地優化。

接下來，將介紹Force.com是如何通過Metadata來動態生成和定製應用的。

Metadata驅動

首先，Force.com的Metadata是基於大家非常熟悉的面向物件的概念，所以也可以把Metadata認為是物件，也就是說Force.com是由一個個物件組裝而成，而且Force.com中的物件可以是表格，也可以是UI，甚至可以是使用者權益等。一個Force.com的物件和這個物件下面的欄位可以對應一個數據庫的表和這個表的列，而且Force.com物件之間的關係（relationship）在功能上類似於資料庫的引用完整性約束（referential integrity constraint），但與資料庫中每個資料庫表對應於獨立的儲存地址不同的是，Force.com使用幾個共享的大資料庫表來作為堆儲存（heap storage）來放置所有物件，另外這些儲存Metadata的表也被稱為”UDD（Universal Data Dictionary）”。

接著，是關於應用的，一個在Force.com上執行的應用例項是通過組合許許多多個物件來生成的，也可以說一個應用例項是使用Metadata來描述的，比如，在應用初始的時候，每個客戶都是使用同一個版本和同樣規模的物件，而且使用者通過新增和更新物件來定製應用，比如增加新的UI和欄位等，同時系統會對共享的和定製的物件進行嚴格地分離，使得既能非常方便地更新共享程式碼，也能保證某個使用者定製過的部分不影響到其他使用者。在實現上，Force.com並沒有實際地為一個新物件生成一個數據庫表，而且以元資料的形式儲存在幾張大表中，並在執行時候，Force.com會有一套引擎來通過分析資料庫中的Metadata來動態生成一個虛擬應用例項和這個應用所需的模組（Virtual Application Componets），比如公共UI（Common Application Screen），定製UI（Tenant-Specific Screen）和其他物件等。

圖2. 虛擬應用模組圖（源自參[1]）

還有，雖然Metadata驅動這種和Java很類似的動態生成機制在速度上有天生缺陷，但是Force.com也內建與Sun的Hotspot技術有異曲同工之妙的Metadata Cache來加速常用Metadata的讀取。

下面，將分別介紹Force.com的兩大組成部分：應用伺服器和共享資料庫。

應用伺服器

應用伺服器主要包括五大核心模組：

• Metadata Cache：用於存放那些最近用到的和比較常用的Metadata來加速應用的生成。
• 大規模資料處理引擎：主要用來加速處理大量的資料讀寫和線上事務。
• 多租戶感知的查詢優化引擎：這個引擎將通過維護多租戶的資訊來幫助Oracle自帶的基於成本的查詢優化器更好地適應多租戶環境。
• 執行時應用生成器：這個生成器主要根據使用者的請求來動態生成應用，並且利用上面提到的查詢優化引擎來提升效率。
• 全文檢索引擎：在資料庫對資料進行更新的同時，這個引擎會非同步更新這個資料的相關索引。

共享資料庫

圖1. Force.com的架構（圖源自參[1]）

整個共享資料庫主要有三種類型的資料庫表：

• Metadata表：主要存放使用者定製的物件和物件所包含的欄位的結構資訊，也被稱為”UDD”。
• 資料表：主要儲存那些使用者定製的物件和物件所包含的欄位的資料。
• Pivot表：用來維護那些用於檢索（indexing），唯一性和關係等denormalized （去規範化）資料以優化系統的效率。

還有，在物理層面，資料庫裡面所有表格，包括底下的索引，都根據每個租戶不同的租戶ID（OrgID）來使用Oracle的Hash分割槽技術進行分割槽。通過Hash分割槽這種久經考驗的技術能夠將大規模的資料平均地分割成多個更小的和更容易管理的分塊，從而幫助大資料庫系統能夠在多租戶的環境下提升速度，伸縮性和可用性等。

大規模資料處理引擎

由於Force.com需要處理的資料量不論是來自網頁端，還是來自Web Service端都是非常巨大的，所以Salesforce在Force.com中引入了特製的大規模資料處理引擎來處理大量的資料讀寫和線上事務。它主要有兩大特點：其一是對大規模資料處理進行了優化，特別是當一個API呼叫發來很多待處理的資料時，這個引擎能非常快速地處理。其二是這個引擎內建錯誤恢復機制，當處理大規模資料時候，假如其中一個步驟發生錯誤時，這個引擎會捕捉和修復這個錯誤，並且保持這個步驟之前正確的結果以避免整個重做。

多租戶感知的查詢優化引擎

大多數現在資料庫都自帶基於成本的查詢優化器，這種優化器主要是基於資料庫表和索引資料等相關數值來進行計算和比較。但是由於傳統的基於成本的優化器都是主要為單租戶的環境設計的，所以他們並不能很好地適應多租戶的環境，因為在資料庫中是沒有多租戶這個概念。為了讓優化器能夠在多租戶環境下良好工作，Salesforce在Oracle自帶優化器的基礎上搭建了一個多租戶感知的查詢優化引擎，它也主要有兩個特點：其一是這個引擎為每個多租戶物件維護了一整套便於優化的資料（租戶層的，組層的和使用者層的）。其二是這個引擎也維護租戶和租戶下面使用者的安全資訊，這樣不僅能提升了效率，因為能避免將那些不屬於這個租戶的資料加入到計算，而且能提升資料的安全性。

全文檢索引擎

全文檢索功能對Web應用而言，基本可以算是一種基本功能，而對基於Force.com的應用而言，同樣如此，Force.com為此內建一個全文檢索引擎，其是基於大名鼎鼎的Lucene技術。當一個執行在Force.com平臺上的應用對資料庫中資料進行更新的時候，會有一組稱為檢索伺服器的後臺程序來非同步更新資料相關的索引。通過這種非同步機制不僅能夠保證檢索工作不影響處理事務的效率，而且同時也能讓使用者使用到最新的搜尋結果。為了優化這個檢索流程，系統會同步將修改過的資料複製到一個內部”等待檢索”的表，之後檢索伺服器會訪問這個表來進行檢索，這樣好處是減少了檢索伺服器的I/O處理量。而且為了更好地適應多租戶環境，檢索引擎自動為每個租戶維護一個獨立的索引。

資料庫表的設計

下圖為Force.com的資料庫表結構：

圖1. 資料庫表的結構（圖源自參[4]）

Metadata表

Metadata表的作用是儲存使用者定製的物件和物件所包含的欄位的結構資訊，不儲存具體的資料，主要有兩大類：

• Object Metadata表：這個表主要儲存物件的資訊，其中主要欄位包括物件的ID（ObjID），擁有這個物件的租戶的ID（OrgID）和這個物件的名字（ObjName）。
• Field Metadata表：這個表主要儲存物件附帶欄位的資訊，其中主要欄位包括欄位的ID（FieldID），擁有這個欄位的租戶的ID（OrgID），這個欄位的名字（FieldName），這個欄位的資料型別（datatype）和一個布林欄位（IsIndexed）來定義這個欄位是否需要被檢索。

Data表

Data表的作用和Metadata表正好相反，它主要儲存那些使用者定製的物件和物件所包含的欄位的資料，主要也包括兩大類：

• Data表：這個表放置著上面那些物件和欄位所對應的資料，核心欄位有全域性唯一的ID（GUID），租戶ID（OrgID），物件的ID（ObjID）和存放物件名字的”Nature Name（自然名稱）”，比如這行和一個會計物件有關，這行的”"Nature Name”欄位可能是”Account Name”，除了這些核心欄位之外，這個表還有名字從Value0到Value500的501個數據列來儲存資料，而且這些列都是varchar的形式來承載不同型別的資料，這種資料列也被稱為”flex列”。
• Clob表：這個表主要存放那些CLOB（Character Large Object，字元大物件）資料，物件最大支援到32000個字元。

Pivot表

Pivot表，也稱為”資料透視表”，在Force.com中是以denormalized （去規範化）格式儲存那些用於特殊目的的資料，比如用於檢索（indexing），唯一性和關係等，主要作用是加速這些特殊資料的讀取以提升系統整體的效能。主要有五種Pivot表：

• Index Pivot表：由於Data表裡面數據都是以”flex列”的形式儲存，所以很難在Data表的基礎上對錶中的資料進行檢索，所以Force.com引入Index Pivot表來解決這個問題，系統在執行的時候會將需要索引的資料從Data表同步到Index Pivot表中相對應的欄位來方便檢索，比如這個資料的型別是日期型的，那麼它將會被同步到Index Pivot表中的日期欄位。
• UniqueFields Pivot表：這個表是用來幫助系統在Data表中欄位實現唯一性。
• Relationships Pivot表：Force.com提供了”Relationship”這個資料型別來定義多個物件之間的關係，而Relationships Pivot表則起到方便和加速”Relationship”資料讀取的作用。
• NameDenorm表：是一個簡單的資料表用於儲存物件的ID（ObjID）和這個物件的例項的名字，主要讓一些僅需獲取名字的查詢呼叫，從而讓一些簡單的查詢無需查詢規模龐大的Data表。
• FallbackIndex表：這個表將記錄所有物件的名字，來免去成本高昂的”UNION”操作，從而加速查詢。

APEX

APEX的語言是為Force.com度身定做的一門語法上類似Java的強型別面嚮物件語言，主要可以通過APEX在Force.com上建立Web Service，編輯複雜的商業邏輯和整合多個Force.com的模組等。APEX主要以兩種方式執行：其一是以單獨指令碼的形式，按照使用者的需要執行。其二是以觸發器的形式，當一個特定的資料處理事件發生的之前或者之後，與這個事件繫結的APEX程式碼將會被執行。而且所有APEX程式碼將會以Metadata的形式儲存在Metadata表內。當一段APEX程式碼被呼叫的時候，APEX的翻譯器（runtime interpreter）將會從Metadata Cache讀取編譯之後的APEX程式碼，而且能夠同時被多個租戶共享以提升效率。

那麼為什麼要在Force.com引入APEX這門新的語言，而不是像Google App Engine那樣支援已經有一定市場佔有率的語言，比如Java和Pyhon。Salesforce的首席架構師在談到這點時，他提出了一個非常重要的原因，那就是安全，首先，Salesforce會APEX語言度身設計一組管理工具，通過這個工具能夠非常方便地監控APEX指令碼的執行，並且能知道這個指令碼在執行過程所耗費的CPU時間，記憶體容量和SQL語句的數量等資料來判斷是否需要中斷這個APEX指令碼，以避免影響到屬於其他租戶的應用，如果中斷的話，系統會丟擲一個runtime exception給上層的呼叫者。其次，基於APEX語言的程式碼能夠對其內嵌的SOQL（Sforce Object Query Language）和SOSL（Sforce Object Search Language）進行驗證來避免實際執行時出現錯誤。還有，在安全方面除了APEX自帶的功能之外，Salesforce還要求每個上傳到Force.com的APEX指令碼，都需要自帶能覆蓋其75%程式碼的測試用例，這種做法不僅顯著地提升APEX程式碼的質量從而確保平臺整體執行的穩定，而且在Force.com自己更新的時候，能使用這些用例來確保新的更新不會影響現有的基於Force.com的應用。

總結

設計理念

根據 Craig Weissman 的演講和幾份官方的白皮書，在Force.com的設計方面Salesforce團隊主要有下面這五大考量：

• 資料驅動：由於 Salesforce 主要面向企業使用者，導致其上面執行的應用，無論是 CRM ，還是報表工具，都是以資料的CRUD（增刪改查）為核心，所以 Force.com 需要由資料來驅動，而且也需要為此做一定程度的優化。
• 規模經濟：由於需要在低價格和靈活付費的基礎上提供可定製化應用，所以需要讓儘可能多使用者共享同一套系統，來大幅減低基礎設施和管理等資源的投入，並實現規模經濟的效益。
• 安全為先：由於在一套物理裝置上將承載數以萬計客戶的企業級應用，那麼如果出現嚴重的程式錯誤或者資料方面遺失或者錯亂，將會發生非常嚴重的後果，所以安全問題是一個 Salesforce絕不能輕視的問題。
• 定製方便：雖然各個企業都會存在一部分比較通用的流程，但是每個企業都可能存在一部分私有或者獨特的流程，所以Force.com需要提供方便的定製功能來幫助使用者將更快捷地將企業的業務遷移到其上。
• 功能豐富：雖然使用者能在 Force.com 上進行開發和定製，但是如果 Force.com 能提供更多的功能模組或者能讓使用者購買和整合第三方的應用將非常有效地幫助使用者開發應用。

雖然這些設計理念說起來很容易，但是實現起來是非常艱難的。可貴地是，Salesforce 團隊在開發 Force.com 的過程中基本實現了這些設計理念。

總結

關於本系列的總結，也主要包括五個方面：

• Trade-Off 是難免的：為了滿足設計目標，有時不得不做Trade-Off 。由於 Salesforce 所需要承載的多租戶應用的規模之大，定製化需求之高都是前所未見的，所以Salesforce並沒有採用在第二篇所提到幾種常見模型，而是從長計議，採用了更靈活但技術要求更高的 Metadata 方式。 還有為了避免在資料庫中執行成本非常高並會 Locking 整個資料庫的 DDL（資料庫定義語句）操作，所以在 Force.com 執行的時候是無法建立和修改資料庫表，而這樣將會提升實現的難度。

• 優化很重要，雖然 Force.com 的多租戶架構就像 Java 一樣，採用了很多動態生成的機制。很顯然，如果像早期的Java那樣缺乏優化的話，那麼 Force.com 整體的效能將會非常糟糕，從而無法實現其設計要求。但幸運的是，Salesforce 團隊不僅做了優化，而且憑藉著其很多核心成員來自於 Oracle 的背景，在資料庫端做了很多高水平的優化，比如添加了很多貌似累贅的 Pivot 表來加快部分常用資料的讀取。

• 人才很重要：經過本系列的介紹，可以看出 Force.com 的整個架構並不全是在現有的框架和庫的基礎上構建的，而是為了設計目標開發了很多比較底層和比較複雜的模組，而且這些模組是隻有那些頂級的程式設計師才能編寫出來的，所以說如果沒有矽谷那個龐大的優秀程式設計師池，Salesforce 就很難走到今天。

• 軟體是一個進化的工程：剛開始的時候 Salesforce 架構是普普通通的 B/S 架構，但是隨著使用者不斷地提出定製化的要求，Salesforce 也不得不在架構中引入多租戶的概念，之後，由於使用者需要更靈活的，可伸縮的和功能更強大的平臺，導致 Salesforce 不斷地對其架構進行重構，到最後，終於整出了 Force.com 這一優秀的 PaaS 平臺。

• 有用的創新才珍貴：Salesforce 不僅在 Force.com 引入很多創新，而且都非常有效。在這些創新當中，最有用的除了 Metadata 驅動這種多租戶架構實現機制之外，還有一個名為”回收站（Recycle Bin）”的概念，這個回收站主要儲存30天來那些從資料表裡面刪除的資料，如果使用者在30天內發現數據是誤刪，可以對資料進行恢復，這樣既減低資料誤刪的可能性，而且能回收部分物理資源，比如硬碟空間等。

最後，我想說雖然到現在為止，Salesforce 還不能算是一場巨大的商業勝利，但是它在產品和思路方面有很多值得我們借鑑的地方，這也是我寫本文的初衷，並謝謝大家花時間在這個系列上面，希望能對得起大家的時間。還有，如果大家對本系列有什麼疑問或者見解，那麼就不要吝惜你的時間，請留下你的評論。

本系列參考資料

按：此為客座博文系列。投稿人吳朱華，曾在IBM中國研究院從事與雲端計算相關的研究，現在則致力於研發下一代雲端計算系統，撰寫一些與雲端計算相關的文章，他的個人站點: PeopleYun.com。(文章版權屬於原作者，轉載請勿混淆。本篇原文地址)