【導讀】計算機軟件與硬件技術(shù)的飛速發(fā)展也導致了計算模型的不斷演化。計算概念與模型的泛化與商業(yè)化。總體上來講，云計算通過互聯(lián)網(wǎng)將超大規(guī)模的。計算與存儲資源整合起來，并以可信服務的形式按需提供給用戶。云計算是計算機資源公共化在商業(yè)模型上一個重要革新。將從繁重，復雜，易錯的計算機資源管理中解放出來，而只需關(guān)注業(yè)務邏輯。種業(yè)務邏輯與計算資源的分離將大大地降低企業(yè)信息化的復雜度。務的能耗量，并且有效屏蔽計算資源的出錯問題。云計算正處于不斷演化的過。程中，各界對云計算的定義持有不同看法。一種新的用戶體驗和業(yè)務模式：云計算式一種新出現(xiàn)的計算模。一種新的IT架構(gòu)管理方法：云計算是一種新的方式來管理大量。最終目的都是提供服務?！霸啤敝械馁Y源在使用

　　

【正文】 用程序的新發(fā)行版 時，可以將新發(fā)行版作為新版本上傳。在您改為使用新版本之前，舊版本可以繼續(xù)為用戶提供服務?？梢栽谂f版本仍運行的同時在 App Engine 上測試新版本。 Java SDK 在具有 Java 5 或 Java 6 的任何平臺上運行。 SDK 以 Zip 文件提供。如果您使用 Eclipse 開發(fā)環(huán)境，您可以使用 Eclipse Google 插件 來創(chuàng)建、測試和上傳 App Engine 應用程序。 SDK 還包括用于運行開發(fā)服務器和上傳應用程序的命令行工具。 Python SDK 通過純 Python 實現(xiàn)，可以在裝有 Python 的任何平臺（包括 Windows、 Mac OS X 和 Linux）上運行。該 SDK 以 Zip 文件形式提供，對于 Windows 和 Mac OS X 還提供安裝程序。 管理控制臺 是基于網(wǎng)絡的接口，用于管理在 App Engine 上運行的應用程序。您可以使用它創(chuàng)建新應用程序、配置域名、更改您的應用程序當前的版本、檢查訪問權(quán)限和錯誤日志以及瀏覽應用程序數(shù)據(jù)存儲區(qū)。 （ 9） 配額和限制 創(chuàng)建 App Engine 應用程序不僅簡單，而且是免費的！您可以創(chuàng)建帳戶，然后發(fā)布一個用戶可以立即使用的應用程序，無需承擔任何費用和責任。通過免費帳戶發(fā)布的應用程序可使用多達 500MB 的存儲空間和多達每月 500 萬次的頁面瀏覽量。當您需要更多時 ，您可以啟用付費、設置每日最高預算，并根據(jù)您的需要分配每個資源的預算。 每個開發(fā)人員帳戶最多可注冊 10 個應用程序。 每個應用程序在限制或 “配額 ”內(nèi)分配資源。配額決定應用程序在一個日歷天中可以使用的給定資源的量。您很快就能夠通過購買其他的資源來調(diào)整這些配額中的一些配額。 有些功能會施加與配額無關(guān)的限制，以保護系統(tǒng)的穩(wěn)定性。例如，當調(diào)用某應用程序以為網(wǎng)絡請求提供服務時，該應用程序必須在 30 秒鐘內(nèi)發(fā)出響應。如果該應用程序花費的時間過長，則進程會被終止并且服務器將向用戶返回錯誤代碼。響應超時是動態(tài)的，如果請 求處理程序經(jīng)常達到其超時，則可以縮短請求超時以節(jié)省資源。 26 服務限制的另一示例是查詢返回的結(jié)果數(shù)。一個查詢最多可返回 1,000 條結(jié)果。本該返回更多結(jié)果的查詢只能返回該最大值。在這種情況下，執(zhí)行這種查詢的請求不可能在超時前返回請求，但限制仍存在以節(jié)省數(shù)據(jù)存儲區(qū)上的資源。 試圖破壞或濫用配額（例如同時在多個帳戶上操作應用程序）違反 服務條款 ，并可能導致應用程序被禁用或帳戶 關(guān)閉。 有關(guān)配額列表和對配額系統(tǒng)的解釋，包括哪些配額可通過啟用付費來增加，請參閱 配額 。 Google Apps Google 企業(yè)應用套件有助于全面提升企業(yè)的運作效率。 企業(yè)應用套件主要包括以下功能： （ 1） 通信與聯(lián)系 ? Gmail： 為每個自定義電子郵件帳戶提供 GB 存儲空間的電子郵件、郵件搜索工具以及內(nèi)置的聊天功能。 ? Google Talk： 免費的全球文字通信和語音通話。 ? Google 日歷 ： 使用可共享的日程安排來協(xié)調(diào)會議與學校的其他活動。 （ 2） 協(xié)作與發(fā)布 ? Google 文檔 ： 創(chuàng)建并共享文檔，實現(xiàn)實時協(xié)作。 ? Google Sites（英文版） ： 一站式共享團隊信息。 ? 初始頁 ： 從同一位置訪問個人收件箱、日歷、文件和所需信息，并搜索網(wǎng)絡 ? Page Creator： 管理員可輕松創(chuàng)建并發(fā)布網(wǎng)頁。 （ 3） 管理您的服務 ? 控制面板 ： 在線管理域和用戶帳戶。 ? API 延展 ： 與現(xiàn)有的 IT 系統(tǒng)或第三方解決方案集成。 Google 云計算技術(shù) Google 云計算技術(shù)具體包括： Google 文件系統(tǒng) GFS、分布式計算編程模型MapReduce、分布式鎖服務 Chubby 和分布式結(jié)構(gòu)化數(shù)據(jù)存儲系統(tǒng) Bigtable 等。其中 GFS 提供了海量數(shù)據(jù)存儲和訪問的能力， MapReduce 使得海量信息的并行處理變得簡單易行， Chubby 保證了分布式環(huán)境下并發(fā)操作的同步問題， Bigtable使得海量數(shù)據(jù)的管理和組織十分方便。 27 （ 1） Google文件系統(tǒng) GFS Google 文件系統(tǒng)（ Google File System， GFS）是一個大型的分布式文件系統(tǒng)，位 于所有核心技術(shù)的底層。 GFS 使用廉價的商用機器構(gòu)建分布式文件系統(tǒng)，將容錯任務交由文件系統(tǒng)來完成，利用軟件的方法解決系統(tǒng)可靠性問題，這樣可以使得存儲的成本成倍下降。 GFS 將整個系統(tǒng)的節(jié)點分為三類： Client（客戶端）、 Master（主服務器）和Chunk Server（數(shù)據(jù)塊服務器）。 Client 是 GFS 提供給應用程序的訪問接口，一庫文件的形式提供。 Master 是 GFS 的管理節(jié)點，在邏輯上只有一個，保存系統(tǒng)的元數(shù)據(jù)，負責整個文件系統(tǒng)的管理。 Chunk Server 負責具體的存儲工作，它的數(shù)目直接決定了 GFS 的規(guī)模。客戶端在訪問 GFS 時，首先訪問 Master 節(jié)點，獲取將要與之進行交互的 Chunk Server 信息，然后直接訪問這些 Chunk Server 完成數(shù)據(jù)存取。這種設計實現(xiàn)了控制流和數(shù)據(jù)流的分離，降低了 Master 的負載。GFS 系統(tǒng)架構(gòu)如圖 10 所示。 圖 10 GFS 系統(tǒng)架構(gòu)圖 GFS 的系統(tǒng)管理技術(shù)包括： ? 大規(guī)模集群安裝技術(shù) ? 故障檢測技術(shù) ? 節(jié)點動態(tài)加入技術(shù) ? 節(jié)能技術(shù) 相對于傳統(tǒng) 的分布式文件系統(tǒng)， GFS 針對 Google 應用的特點多方面進行了簡化，從而在一定規(guī)模下達到成本、可靠性、性能的最佳平衡。具體來說，它具有以下幾個特點。 ? 采用中心服務器模式 中心服務器模式大大簡化了設計，降低了實現(xiàn)難度。 Master 管理了分布式文件系統(tǒng)中的所有元數(shù)據(jù)，解決了元數(shù)據(jù)的一致性問題，同時增加一個 Chunk Server 的難度降低了。但是中心服務器模型使得 Master 極易成為系統(tǒng)性能 和可靠性上的瓶頸。 28 ? 不緩存數(shù)據(jù) 在云計算系統(tǒng)中，客戶端大部分是流式順序讀寫，并不存在大量的重復讀寫，緩存對系統(tǒng)整體性能的提高作用不大，反而會產(chǎn)生可能的一致性問題。 GFS 文件系統(tǒng)將緩存的任務交給我本地文件系統(tǒng)，有本地文件系統(tǒng)實現(xiàn)緩存，減少了數(shù)據(jù)一致性的復雜度。 ? 在用戶態(tài)下實現(xiàn) 1) 在用戶臺下實現(xiàn)，直接利用操作系統(tǒng)提供的 POSIX 編程接口就可以存取數(shù)據(jù)，無需了解操作系統(tǒng)的內(nèi)部實現(xiàn)機制和接口，降低了實現(xiàn)的難度，并提高了通用性。 2) POSIX 接口提供的功能更為豐富，在實現(xiàn)過程中可以利用更多的特性，而不像內(nèi)核變成那樣首先。 3) 用戶臺下有多種調(diào)試工具，而在內(nèi)核態(tài)中調(diào)試相對比較困難。 4) 用戶臺下， Master 和 Chunk Server 都以進程的方式運行，單個進程不會影響到整個操作系統(tǒng)，從而可以對其進行充分優(yōu)化。在內(nèi)核臺下，如果不能很好地掌握其特性，效率不但不會高，甚至還會影響到整個系統(tǒng)運行的穩(wěn)定性。 5) 用戶臺下， GFS 和操作系統(tǒng)運行在不同的空間，兩者耦合性降低，從而方便 GFS 自身和內(nèi)核的單獨升級。 ? 只提供專用接口 1) 降低了實現(xiàn)的難度。通常與 POSIX 兼容的借口需要在操作系統(tǒng)內(nèi)核級實現(xiàn)，而 GFS 在應用層實現(xiàn)。 2) 專用接口可對應用提供一些特殊 支持，如支持多個文件并發(fā)追加的接口。 3) 專用接口直接和 Client、 Master、 Chunk Server 交互，減少了操作系統(tǒng)之間上下文的切換，降低了復雜度，提高了效率。 （ 2）并行數(shù)據(jù)處理 MapReduce MapReduce 這種并行編程模式思想最早實在 1995 年提出的。與傳統(tǒng)的分布式程序設計相比， MapReduce 封裝了并行處理、容錯處理、本地化計算、負載均衡等細節(jié)，還提供了一個簡單而強大的接口，可以把大尺度的計算自動地并發(fā)和分布執(zhí)行。 MapReduce 吧對數(shù)據(jù)集的大規(guī)模操作，分發(fā)給一個主節(jié)點管理下的各分節(jié)點共同完成，通過這種方式實現(xiàn)任務的可靠執(zhí)行與容錯機制。 MapeReduce操作 which 由 M 個 Map 操作和 R 各 Reduce 操作一起完成的。一個 Map 函數(shù)就是對一部分原始數(shù)據(jù)進行分發(fā)操作而一個 Reduce 操作就是對每個 Map 所產(chǎn)生的一部分中間結(jié)果進行合并操作。 MapReduce 操作的執(zhí)行流程如圖 11 所示。 29 圖 11 MapReduce 操作流程圖 (3)分布式鎖服務 Chubby Chubby 是 Google 設計的提供粗粒度鎖服務的一個文件系統(tǒng)，它基于松耦合分布式系統(tǒng)，解決了分布的一致性問題。 GFS 使用 Chubby 來選取一個 GFS 主服務器， Bigtable 使用 Chubby 指定一個主服務器并發(fā)現(xiàn)、控制與其相關(guān)的字表服務器。 Chubby 還可以作為一個穩(wěn)定的存儲系統(tǒng)存儲包括原數(shù)據(jù)在內(nèi)的小數(shù)據(jù)，同時 Google 內(nèi)部使用 Chubby 進行名字服務（ Name Server）。 Chubby 系統(tǒng)本質(zhì)上是一個分布式的、存儲大量小文件的文件系統(tǒng)，它所有的操作都是在文件的基礎(chǔ)上完成的， Chubby 的文件系統(tǒng)與 UNIX 類似。 Chubby 的設計目標有以下幾點： ? 高可用性和高可靠性： ? 高擴展性： 將數(shù)據(jù)存儲在價格較為低廉的 RAM，支持大 規(guī)模用戶訪問文件。 30 支持粗粒度的簡易型鎖服務：建議性的粗粒度鎖服務在用戶訪問某個被鎖定的文件時不會阻止，且持有鎖的時間較長，減少頻繁換鎖帶來的系統(tǒng)開銷，提高了系統(tǒng)的性能。 ? 服務信息的直接存儲： 可以直接存儲包括元數(shù)據(jù)、系統(tǒng)參數(shù)在內(nèi)的有關(guān)服務信息 ? 支持通報機制： 客戶及時地了解到事件的發(fā)生。 ? 支持緩存機制： 通過一致性緩存將常用信息保存在客戶端，避免頻繁訪問主服務器。 圖 12 Chubby 基本架構(gòu)圖 圖 13 Chubby 客戶端與服務器端的通信過程 Chubby 的客戶端與主服務器端通過遠程過程調(diào)用（ RPC）來連接，客戶端的所有應用通過調(diào)用 Chubby 程序庫中相關(guān)函數(shù)完成。服務器端由五個副本構(gòu)成一 Chubby 單元。這些副本通過 quorum 機制選舉產(chǎn)生一個主服務器，并保證在一定時間內(nèi)有且僅有一個主服務器，這個時間被稱為主服務器租約期。 Chubby 31 的 基本架構(gòu)如圖所示。客戶端與主服務器之間通信靠 KeepAlive 握手協(xié)議來 維持。通信過程如圖所示。 （ 4） 分布式結(jié)構(gòu)化數(shù)據(jù)表 Bigtable Bigtable 是一個分布式多為映射表，表中數(shù)據(jù)通過一個行關(guān)鍵字、列關(guān)鍵字和一個時間戳進行索引。 Bigtable 對存儲在其中的數(shù)據(jù)不做任何解析，一律看做字符串，具體數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)由用戶自行處理。 Bigtable 的存儲格式如圖 14 所示。 Bigtable 不支持一般意義上的事務，表中數(shù)據(jù)根據(jù)行關(guān)鍵字排序，使用詞典序；列關(guān)鍵字被組織成列族，族是 Bigtable 訪問控制的基本單元；不同版本的數(shù)據(jù)通過時間戳來區(qū)分。 圖 14 Bigtable 存儲格式 圖 15 Bigtable 架構(gòu)圖 Bigtable 是構(gòu)建在另外三個云計算 組件之上的，基本架構(gòu)如圖 15 所示。Bigtable 主要由三部分組成：客戶端程序庫（ Client Library）、一個主服務器（ Master 32 Server）和多個子表服務器（ Tablet Server）。客戶訪問 Bigtable 服務時首先利用庫函數(shù)執(zhí)行 Open()操作打開一個鎖獲取目錄文件，然后和子表服務器進行通信。 ? 主服務器 主服務器 主要進行元數(shù)據(jù)的操作以及子表服務器之間的負載調(diào)度問題，幾乎不與客戶端進行通信。當新的子表產(chǎn)生式，主服務器通過一個加載命令將其分配給一個空間足夠的子表服務器。子表服務器在初始化 時從 Chubby 得到一個獨占鎖，子表服務器基本信息以此保存在 Chubby 的服務器目錄中，主服務器通過檢測這個目錄獲取最新的子表服務器信息，并定期向子表服務器詢問獨占鎖的狀態(tài)。 ? 子表服務器 Bigtable 中實際的數(shù)據(jù)以子表的形式保存在子表服務器中，內(nèi)部數(shù)據(jù)存儲格式為 SSTable。 SSTable 中的數(shù)據(jù)被劃分成塊（ Block），在 SSTable 的結(jié)尾有一個索引，保存 SStable 中塊的位置信息。 SSTable 文件都存儲在 GFS 上，通過鍵查詢。子表由 SSTable 和日志構(gòu)成，子表的地址為三層結(jié)構(gòu)，如圖 16 所示 。 Bigtable將數(shù)據(jù)存儲劃分成兩塊，較新的數(shù)據(jù)存儲在內(nèi)存表中，較早的數(shù)據(jù)被壓縮成SSTable 格式保存在 GFS 中。數(shù)據(jù)壓縮氛圍此壓縮、合并壓縮、主壓縮三種壓縮形式。 Bigtable 使用了緩存和預取技術(shù)，子表地址被緩存在客戶端。 圖 16 SSTable 地址結(jié)構(gòu) ? 性能優(yōu)化 1）局部性 群組 ： Bigtable 允許用戶將原本并不存儲在一起的數(shù)據(jù)以列族為單位，根據(jù)需要組織在一個單獨的 SSTable 中，以構(gòu)成一個局部性群組。這實際上就是數(shù)據(jù)庫中垂直分區(qū)技術(shù)的應用。 2）壓縮 33 3）布隆過濾器 ：這是一個很長