文/林仕鼎

云計算概念發端于Google和Amazon等超大規模的互聯網公司，隨著這些公司業務的成功，作為其支撐技術的云計算也得到了業界的高度認可和廣泛傳播。時至今日，云計算已被普遍認為是IT產業發展的新階段，從而被賦予了很多產業和產品層面的意義。由于意義多重，各種概念紛繁復雜，眾多公司和從業人員的眼中都有自己的一朵云，正如徐志摩在《偶然》一詩中所說：“我是天空里的一片云，偶爾投影在你的波心”。

傳統的系統設計考慮的主要是單機環境，而云計算主要考慮的環境卻是數據中心。從單機到數據中心，很多設計原則發生了根本變化，極端點甚至可以說PC時代30年來一以貫之的系統設計原則到今天已完全不適用。

考慮到云計算的諸多內涵，從技術角度講，數據中心計算?（Datacenter?Computing）可能是更合適的表述。本文對數據中心計算的技術領域和設計原則的變化進行了粗淺的探討。一家之見，僅供參考。

云計算簡介

從20世紀80年代個人電腦的發展開始，PC的計算能力不斷增強，用一臺PC就可以存放個人需要的所有數據并完成處理工作，比如編寫文檔、處理郵件等。但在互聯網時代，一家互聯網公司提供服務時需要用到遠超過個人規模的數據，這些數據的存儲和處理需要成千上萬臺機器的協同工作才能完成。這種服務器規模不是個人能夠提供的，只有大型公司或機構才能擁有，這好像又回到了更早以前的Mainframe時代。從Mainframe到PC再到云，這正是計算機技術螺旋上升的發展過程。

簡單來說，云計算就是利用系統架構技術把成千上萬臺服務器整合起來，為用戶提供靈活的資源分配和任務調度能力。這里有幾個關鍵字：一是超大規模，包括機器的數量、用戶的數量和并發任務的數量；二是資源整合，成千上萬臺的服務器資源能集合起來做一件事情，比如存儲大量數據，或者處理一個大型任務；三是靈活與快速交付，大規模的服務器資源能進行靈活的調配，按應用需求分解成若干個虛擬的資源池，快速地支持大量的并發請求或作業。

云計算技術的出 現，使整理和加工數據的能力變得空前強大，這種能力可以幫我們找出很多看似無關的事件背后的規律，并用其來預測未來發展。結合移動和物聯網等技術，還可以 更好地服務于社會和人們的日常生活，如災難預警、智慧城市和智能交通等。這種數據處理能力是在海量數據之上發展起來的，與作為基礎支撐的系統架構技術同步 發展并逐漸融合，共同組成了現在大家所看到的云計算技術。

綜合系統架構和數據處理技術兩方面，云計算技術自下而上可分為硬件基礎架構、軟件基礎架構和數據智能三個層面，如圖1所示。

硬件基礎架構包括服務器、網絡和數據中心的設計與實施等技術領域，軟件基礎架構聚焦于存儲、計算與大規模分布式系統等技術領域，數據智能則關注數據倉庫（Data?Warehouse）、機器學習（Machine?Learning）及數據分析與可視化（Data?Analysis?&?Visualization）等技術領域。值得一提的是，這三個層次的劃分主要以技術領域為出發點，而通常提到的云計算三個層次SaaS/PaaS/IaaS則更多地是從資源的提供形態和接口為考慮進行劃分的，二者并非同一維度。

時下流行的大數據（Big?Data）概念可以看成從海量數據的角度看數據分析技術和軟件架構支撐，包括軟件基礎架構與數據智能相關技術。二者都與數據有關，但其區別在于：軟件基礎架構關心的主要是數據的格式、容量以及訪問模式等，而數據智能更在意數據的語義。

而數據中心計算則是從體系結構的角度看待軟硬件系統設計。下文將就相關的技術領域和設計原則進行討論。

數據中心計算

技術領域與挑戰

如圖2所示，數據中心計算包含存儲、計算、實時存儲與計算、超大規模系統、體系結構以及數據中心等技術領域。存儲系統的需求來自兩個維度。首先，大量的無結構數據需要表（Table）、對象（Object）與文件（File）等多種存儲結構進行支持；其次，訪問模式的不同（如只讀不寫、只寫少讀、讀寫均勻等）將很大程度上影響對存儲系統設計和優化的考慮。

計算系統的需求和技術特點與計算任務的類型有很大關系。數據密集型的代表是MapReduce，它對CPU和I/O的需求比較均衡。計算密集型任務與通信密集型任務都是CPU密集計算，但二者訪問數據的規模不同。如果只需要少量數據則是計算密集型。而如果需要訪問大量數據，比如大矩陣迭代，內存限制這些數據必須存放在多臺機器上，那么往往此時系統瓶頸將轉移到通信的延遲上，這類似于傳統的高性能計算。

通常的存儲系統和計算系統只能支持到一定級別的延遲和并發度，對于更高的要求則需要基于內存構造實時的存儲與計算系統。考慮到內存的特點，在存儲上更適合提供具有豐富語義的數據結構。在分布式數據結構的基礎上，加入流式數據處理和觸發式事件處理的模型，則可以更好地支持實時檢索、OLAP、PubSub等應用。

超大規模系統主要通過分布式相關技術保證系統的可用性（availability）和可管理性?（manageability），包括系統建模、設計、開發以及運維等多方面。體系結構包括虛擬機、服務器設計等。數據中心包括機柜設計、網絡規劃與設計、數據中心設計與建設等，主要關注于能效比（PUE）。

系統設計原則

傳統的軟硬件系統主要面向單機和個人，在桌面環境中使用，我們也可以稱其為桌面計算（Desktop?Computing）。從桌面到數據中心，應用特點和負載模型發生了巨大變化。

在單機上，主要面向一個用戶，他可能運行多項任務，任務可以分為前臺任務和后臺任務兩種。用戶對系統的響應性（promptness或responsiveness）十分敏感，所以前臺任務通常優先于后臺任務，而后臺任務則希望被公平調度。這也是搶占式調度（Preemptive?Scheduling）策略最終勝過協作式調度（Cooperative?Scheduling）的原因。

在數據中心里，同樣也有在線和離線兩種應用類型，在線系統直接面向用戶，而離線系統多用于數據處理。在線系統通常是一個大型應用服務于海量用戶，用戶對系統響應性仍然十分敏感。但由于用戶規模巨大以及互聯網服務通常免費，成本壓力十分嚴峻，所以系統需要充分挖掘用戶對響應性的容忍度。通常情況下，人對事件響應的感知能力在500ms左右，利用這一特點可以優化系統調度并節省資源。而在極限壓力情況下，沒有足夠的資源滿足所有請求，很多系統開始延長響應時間，然后在持續壓力下失去響應直至崩潰。此時，為可服務范圍內的請求提供正常服務，并為超過范圍的請求提供快速的拒絕響應，將會給用戶帶來更好的體驗，也能提升系統的可用性。到最后，我們會發現在線服務系統應以穩定的極限吞吐（Sustained?Throughput）作為首要設計目標。當然，要在一定延遲閾值的前提保證下。

離線系統主要服務于數據處理類作業，這些作業涉及海量數據，使用者的預期并不會特別高，此時的處理效率更為重要。通常，這些作業將會以批處理的方式合并執行，提升系統的總吞吐率，即資源利用率成為首要調度目標。

在系統設計時，有一些永恒的矛盾需要做出折中考慮，例如延遲與吞吐、公平與效率。在桌面環境中，我們選擇了低延遲和公平，而在數據中心環境中，我們選擇了高吞吐（或穩定的極限吞吐）和高效率。在具體實現方案上，也帶來了不同的選擇，比如同步與異步模型、線程與事件驅動、線程池與隊列等。

從桌面到數據中心，同樣發生變化的還有開發模式。PC是一個開放系統，無論軟件還是硬件，每個廠商都只負責系統中的一部分，都需要考慮和不同的組件一起工作。由于用戶眾多，需求各不相同，只能采取按層次組織的系統架構（layered?architecture）以及約定俗成的標準化規范。這雖然保證了系統的通用性，以及不同來源的各種組件的有效分工和協同工作，但也帶來了一些問題，例如一個功能需要穿透多層才能完成，而每層互不信任，需要執行嚴格的參數檢查等。

更嚴重的是，在系統的每一層中，都可能存在一些重復的功能。以存儲為例，一次寫入需要經歷從libc的文件流（FILE?stream），到文件系統的緩沖區，再到驅動器中的緩沖區，最后到磁盤上的緩存這樣的長調用流程才能完成持久化（persistency）。這個流程從其中的每一層單獨來看都是合理的，但從整個系統的角度看來，存在著性能浪費。另外，由于分層帶來的透明性使得數據持久化不得不通過額外的fsync操作才得以保證，從而使系統的可靠性保證機制變得更復雜。

此外，在架構設計時，我們也經常在談機制（mechanism）與策略（policy）的分離。固定、明確的功能稱為機制，通過靈活的可變的策略進行配置，從而使系統具有良好的可擴展性。但實際上，每層獨立且透明，且通常也都沿用相同的設計理念，這其實并不能保證機制策略的有效分離，最后的系統往往很難取得可擴展性和性能的良好平衡。

我們可以發現分層導致了每層都傾向于變得聰明、變得復雜，但綜合效果卻不如人意。而在今天的數據中心環境中，如前面所說，很多時候我們其實是在做一個超大型應用，應用的特點需要被充分考慮。另外這個系統通常只有一個生產商，可以進行垂直化的設計或整合。此時，由應用層或平臺的上層提供策略，而下層只需要考慮機制，這將使系統變得更加簡單，從而取得更好的性能，而擴展性也可以得到很好的保證。

以SSD為例，現在的SSD在設計時通常假設由文件系統來使用。由于閃存的擦除特性，需要考慮寫緩沖區，而由于緩沖區需要有預留空間也需要有復雜的置換算法和回收機制，這對性能和成本（也包括開發成本）都有很大影響。但在數據中心環境里，我們通常有完整設計的存儲系統，數據組織方式和讀寫流程也被充分優化，對存儲設備的需求就是最基本的定長塊。這種情況下，SSD的邏輯其實可以做得非常簡單，直接對上層暴露內部的狀態（如通路、物理塊），從而提高性能、降低成本。更重要的是，這將有效提高交付速度——這對于緩解服務器、網絡、IDC等硬件系統的長實施周期和業務快速增長的規模需求之間的矛盾至關重要。

上層對下層的要求是邏輯簡單、功能單一，而下層對上層則暴露更多細節，最復雜的邏輯判斷由最上層的應用來完成，這是另一種方式的層次化。而且，層次之間也不需要維持一個物理邊界（如現在應用和內核之間），可以通過函數調用的方式實現柔性的層次劃分。有興趣的讀者可以參考libOS【注：Exokernel】或者in-kernel?web?server【注：khttpd】的一些設計思路。

從桌面到數據中心的第三個變化是評價體系。一個中等規模的數據中心通常包含數萬服務器，在這樣的規模下，硬件故障成為家常便飯。一般，我們通過冗余復制或者重復處理來解決硬件故障問題。在習慣了硬件故障之后，我們對軟件Bug的態度也會發生變化。軟件Bug中有一種偶發性Bug【注：也被稱為heisenbug，意指海森堡測不準原理】最難發現也最難調試，消除這些Bug需要付出巨大的代價。但考慮到這種Bug的出現概率堪比硬件故障，我們其實可以采用同樣的方式來對待。

規模增長的同時，系統的復雜度也變得越來越高，以至于很多時候已經超過一個人的直接掌控能力。要去理解系統的運行狀態以保障其正常運行，在這種情況下變得十分困難。此時，我們可以利用系統冗余的特點，對一些組件進行定期重啟（reboot），通過重置狀態降低Bug被觸發的概率【注：“Recovery?Oriented?Computing”】。而對于性能上的問題則更是如此，有時還需要采用數據挖掘的方法來進行優化或系統調試【注：M.K.?Aguilera,?J.C.?Mogul,?J.L.?Wiener,?etc., “Performance?debugging?for?distributed?systems?of?black?boxes”,?in?SOSP’03】。

海量數據以及數據處理應用也帶來了很大的影響。由于數據的規模以及處理算法的特點，很多時候系統只需要提供概率意義上正確的結果，不需要保證數據的絕對可靠，也不需要嚴格保證運行結果的可重復性。

總而言之，互聯網服務規模巨大，對成本很敏感，而且業務需求的變化也異常頻繁，這和PC應用的特點截然不同。現在的系統設計原則是在桌面環境中歷時30余年發展起來的，但到了今天已經完全不適應數據中心環境，我們需要重新思考并總結出適用的設計原則，這體現在如下三個方面。

• 從單用戶多任務到多用戶單任務的環境變化，導致我們在系統設計時重新審視對延遲與吞吐、公平與效率的折中考慮。
• 自行開發全套系統成為可能，透明性不再是美德，架構由層次化向豎井式演進，系統由需求驅動而定制。
• 由于規模與復雜度增大，我們不再追求零缺陷，而是與故障和Bug共舞。同時數據也成為系統的一部分，這些都使得以前的確定性系統變得不確定，評價指標也由正確性（correctness）向精確度（precision）轉變。

需要強調的是，這些設計原則的改變并不意味著，我們需要顛覆桌面環境的通用系統，全盤轉向專用系統。以前通用系統的設計完全以桌面環境為出發點，現在則是新的環境、新的應用形態和新的業務需求，這時需要有另一種類型的通用系統。這就像現在的NoSQL系統，提出之時是專用的，但正逐漸變得通用。

總結

互聯網服務區別于傳統行業最顯著的特點是超大規模的數據以及快速迭代的開發方式，通過數據可以分析用戶行為，而快速迭代則使數據分析結果更快生效，從而優化運營或適應用戶需求的變化。可以說，數據規模和迭代速度決定了一個互聯網公司創新的速度，同時也是它技術水平的標志，而其中最關鍵的便是云計算技術。

云計算技術可分解為大數據和數據中心計算。大數據從海量數據的角度看數據分析技術和系統架構支撐，包括軟件基礎架構與數據智能等相關技術，而數據中心計算則是從體系結構的角度看待軟硬件系統。傳統的軟硬件系統基于桌面環境設計，而今天的數據中心環境有了很多變化，比如應用特點和負載模型、開發模式、評價體系等，這導致了傳承至今的設計原則不再適用。

本文主要從宏觀上對數據中心計算的特點進行討論，旨在理清概念、拋磚引玉，引發業界對系統設計原則的重新思考。對于具體的技術方向如存儲、計算以及大規模分布式系統等，文中并沒有詳細描述，留待日后陸續討論。

一、云計算核心技術架構與大數據二、云計算平臺與應用實踐 三、云計算時代的安全解決方案 四、云計算時代的數據中心與運維之道五、云計算與智慧城市六、云終端與新型應用七、云計算與移動互聯網 八、云計算與電信運營轉型九、云計算產業規劃十、云計算與重點行業信息化創新（能源、交通、教育、媒體）十一、云計算與電子政務信息化創新十二、云計算與醫療信息化創新十三、云計算與社區信息服務創新十四、中國-歐美云計算合作圓桌論壇十五、海峽兩岸云計算合作圓桌論壇十六、開放平臺晚場沙龍