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