連接到雲，第1部分: 在應用程式中使用雲--充分利用混合模型

探究雲計算以及 Amazon、Google、Microsoft® 及 SalesForce.com 這幾家主要供應商所提供的各種雲平臺。 在這個由三個部分組成的系列文章的第 1 部分中，我們會給出一個典型的使用 JMS 佇列的企業應用程式示例，並研究在雲中結合使用此 JMS 基礎設施的一部分時將會涉及到哪些內容。

簡介

多年來，在網狀圖中，我們已經習慣于使用一個雲（特別是積雨雲）來表示 Internet。 雲狀圖像常被用來表示無固定形狀的、不清晰但又必須包含在圖表中的一些內容。 而網路上的線惟一的作用就是穿過雲以表示資料通過 Internet。 在以安全性為中心的圖表上，這條穿過雲的線可能還會在旁邊多出一個掛鎖以表示這個連接是安全的。

現在雲已經在網狀圖中扮演著主要角色。 應用程式可以利用雲來調用所添加的值，比如存儲、佇列及宿主應用程式。 應用程式本身也可以被託管在雲上。 現在的線已不再是簡單地穿過雲，而是連接到雲並將雲用作應用程式的一部分。 這就使雲有了更實際的意義。

在這個由三個部分組成的系列文章中，我們將探究雲計算的方方面面。 雲計算的供應商相對較少，每個供應商著眼于不同的方向並提供不同的服務。 程式設計語言各異，從 Python 到 C#、再到 JAVA 或其他的專有語言。 與雲的介面也各不相同，雖然輕量的 REST 介面是首選，但現在並不是每個雲計算供應商都提供這種介面。

在本系列的第 1 部分，我們將著重研究一個混合示例，一個使用雲計算服務和基礎設施進行增強了的專用應用程式。 通過研究這個混合應用程式，瞭解雲計算的功用。 為此，您需要探究它的淵源、雲計算的主要供應商目前所能提供的功能。 本系列的第 2 部分將會涵蓋在第 1 部分中設計的這個混合應用程式的開發。 第 3 部分將著重介紹此解決方案在安全性和管理方面的問題。

雲計算究竟是什麼？

IBM 將雲計算定義為一個新興的計算范型，在這個范型中，資料和服務位於可大規模伸縮的資料中心中，並可被 Internet 上的任何連接設備隨時訪問。 它為應用程式提供了可觀的伸縮能力（在使用 Amazon Elastic Computing Cloud 的情況下 — 通常被稱為 Amazon EC2），並能託管應用程式自身。

雲計算並不適合所有的情形，但是對於一個在不同時期需要不同計算能力的組織來說，雲是很有吸引力的。 如果一個組織對處理和存儲能力的要求是不均衡的，比如每週六的午夜進行批次處理，那麼此時與其採用一個大多數時間都空閒的資料中心，到不如使用雲更有意義。

雲計算也特別適合於那些剛剛起步的公司。 這些公司的創業者對投資資本家提出的問題恐怕都不會陌生，即 「您的技術如何伸縮？ 」雲計算是對此問題的一個很好的答案。 然而，正如您在本系列後面的部分看到的，雲計算也帶來了擁有權、安全與成本方面的問題。

雲的形成

在雲計算得到廣泛應用之前，我們使用的是網格計算與效用計算。 網格計算與雲計算的主要區別就是網格計算環境多是由不同的機器組成的，而雲計算環境則更加可控制，後端機器通常都是相同的。 效用計算是指按資料流量或應用程式的使用支付費用的一種業務模型。 服務的 「彈性」 增長的概念也沒有現在這麼盛行，而隨著使用的改變而相應增加（或減少）容量的能力卻是雲計算的一個重要部分。

從 2000 年初到 2000 年中，Google 和 Amazon 各自獨立開發了自己的雲計算架構以便在其上運行各自的業務。 開發了這種基礎設施後，二者發現他們自已的基礎設施本身成為了一個服務，可以按照每次的使用量賣給開發人員。 Amazon 更是意識到了其平臺中的關鍵價值，以至於它完全相信有一天 Amazon 將會因其計算平臺而再次名揚天下，一如它的線上零售網站一樣。 Amazon 認識到它可以以服務的形式出售其平臺（即 Platform as a Service，縮寫為 PaaS — 與 Software as a Service 即 SaaS 類似）。 因此，Amazon 常被視為是雲計算商業化方面的領跑者，在計費和使用模型方面尤為突出。

在基於雲的計算環境的設計方面堪稱專業的成功供應商為數不多，其中包括 Amazon 和 Google。 認識到這一點，Google、IBM 和幾所大學組建了一個 research cloud 來為從事雲計算研究的學生提供一個雲計算環境以便開發新的雲計算技術與應用程式。 儘管其規模不能與 Amazon 與 Google 的基礎設施相提並論，但此專案還是為學生研究雲服務提供了一個很好的環境。 來自此專案的研究成果將會有助於對雲計算進行更進一步的開發，比如有創建條件的組織可以在其基礎上開發專用雲。

混合模型應運而生

放棄所有本地應用程式而只使用雲，或相反地，只依靠本地應用程式而忽略雲，都不是明智之舉，現在最流行的辦法是將本地應用程式與雲相結合使用。 即所謂的混合模型。 這就讓一個公司在必要的時候使用雲計算，而同時又能保持它對其關鍵應用程式的控制。 例如，很多公司已經發現，使用 Amazon 的 Simple Storage Service (S3) 存儲圖片、視頻或文檔等會更經濟。 混合模型也有助於增量方法。

即使您認為將大部分甚至全部的應用程式都轉向雲更有意義，但是也不建議您這麼做，因為一次性完成這樣的轉移風險太大。 借助混合模型，可以先將容易的東西（比如檔存儲）轉向雲。 然後在您適應了這種部署模型後，再將應用程式更重要的部分轉向雲。 這也是我在本系列中所採用的方式。 接下來，讓我們先看一下這個通過轉移部分基礎設施實現混合的應用程式。

設計一個混合應用程式

這個示例混合應用程式是一個非同步電子郵件通知系統。 它可以是一個工作流系統中的一個子系統。 當一個新行為被提交並等待批准時，就會向能夠做出批准或拒絕決定的主體發送電子郵件。 這種系統可以用於一個履行訂單的系統中。 當訂單貨物運出時，就會發出一個電子郵件以通知相關的人訂單在貨運途中。 不難想像，在很多種應用程式中都可以使用到這個系統。 電子郵件在本質上是非同步，所以能生成電子郵件的非同步機制是滿足此類用例的一種有效途徑。

假設有一個現成的應用程式，在此應用程式的某個位置已經具有了這種系統，可以使用很多種方法實現此類系統，但一個相對優雅的方式是使用一個 JMS。 JMS 規範是 J2EE™ 技術棧的一個重要部分。 目前，針對此標準已經有很多專有或開源的實現。 很容易想像有這樣一個系統，它向一個 JMS 佇列發送通知，而另外一個系統對這個 JMS 佇列進行週期性地讀取並為每個消息生成電子郵件提醒。

對於一個混合模型，可以先將這個 JMS 佇列轉移到雲。 換句話說，就是用在雲中運行的一個服務來替代它。 這是一種什麼樣的服務呢？ 如何更改應用程式以使其與此服務進行交互呢？ 這取決於所使用的雲平臺。 接下來，我們來看一下各種平臺及怎樣使用這些平臺來實現或像本例一樣重新實現一個 JMS 佇列的功能性。

Amazon Web Services

作為一個商業化雲計算的先軀，Amazon 提供了一系列開發人員感興趣的成熟服務。 Amazon 最知名的雲服務莫過於 EC2 (Elastic Computing Cloud) 服務。 它允許構建可在 Amazon 自已的基礎設施上運行的虛擬機器實例（被稱為 AMI — Amazon Machine Images）。 也許有人會說，除了使用的不是真實的電腦以及基於流量使用收費而非收取機器的租賃費之外，EC2 更接近于託管供應商的一項服務。

Amazon 的 S3 服務是一個線上存儲服務，對於需要擴展存儲能力的新起步的那些公司來說尤其具有引吸力。 它可用作其他 Amazon 雲服務（比如 EC2）的一個附件。 這就意味著一個 AMI ，或是一個運行著 PHP 的 Linux™ 電腦，可以使用 Amazon S3 作為它的資料存儲。 隨著資料流量的增長，S3 服?? 也會彈性擴展。 Amazon 的 SimpleDB 是一個基於雲的快速而簡單的資料庫，它可以提供索引、存儲及訪問。 很顯然，它比功能完善的關係資料庫要簡單很多，因為它不需要模式，它可以自動地索引資料，並提供了 API 用於存儲及訪問。

Amazon 的 SQS (Simple Queue Service) 提供了一個佇列服務，類似于 JMS，但有一個 RESTful 介面。 您也可以將 SQS 與 Amazon 的其他雲服務聯合使用，也可以將它作為任何一個可用簡單的 HTTP GET 或 POST 連接到它的應用程式的一部分使用。 對於這個混合應用程式，它是 JMS 佇列的一個很好的替代品。 它可以通過它的 RESTful 的 XML 介面訪問到，可以方便地與一個現有應用程式集成。 SQS 可能是這類混合應用程式的最為直接的選擇。

很多軟體供應商都與 Amazon 有過合作以説明其客戶充分利用 EC2。 例如，IBM 和 Amazon 合作開發了 IBM 的很多最受歡迎的企業軟體，比如 EC2 上的 DB2®、Informix® 及 WebSphere®。

Google

Google 因其快速而準確的搜索而聞名，對於很多使用者來說，它都是 Arthur C Clarke 的名言 「任何足夠先進的技術都與魔法沒有區別」 的最好的體現。 由於是技術將魔法變成了現實，因此 Google 是提供雲計算平臺的最佳之選。 在 Google 的平臺上運行應用程式的美好前景讓開發人員無比興奮，這完全可以理解。

Google 提供了一個名為 App Engine 的雲計算平臺，它基於的是 Google 早就建立起來的底層平臺。 這個平臺包括 GFS（Google File System）和 Bigtable（構建于 GFS 之上的資料庫系統）。 Google App Engine 內的程式設計採用的是 Python。 程式師用 Python 編寫應用程式，然後再在 App Engine 框架上運行。 除 Python 外的其他語言在將來也會得到支援。 出於開發的需要，可以下載 App Engine 環境的一個本地模擬程式。 App Engine 可免費使用並且包括多達 500 MB 的存儲及足夠的 CPU 頻寬來滿足每天 5 百萬次頁面流覽。

Google App Engine 提供了一些有用的基礎設施，比如源自 GFS 的資料存儲和一個 memcache 實現。 然而，它並不提供開箱即用的排隊機制。 不過，有了這樣一個純 Python 的程式設計環境，就可以在 App Engine 之上很容易地創建您自已的 JMS 替代。 這個資料存儲很適合於混合應用程式，並且只需很少的 Python 程式設計就可以打造出一個面向您的佇列的 RESTful 式介面。

Microsoft Azure

正如您所期望的，Windows® 和 .NET 是 Windows Azure 的主要特點。 Microsoft 已經提供了一個開發環境，在這個環境中，用 Visual Studio® 編寫的應用程式可以被託管于 Windows Azure 環境並在其上運行。 Azure 平臺提供了很多服務，比如像用於檔存儲與資料訪問的面向基礎設施的服務，同時也提供了更為專用的服務，比如搜索和連絡人管理。 它還包括了 NET Service Bus。 這是典型的 Enterprise Service Bus (ESB) 設計模式的 Microsoft 實現。 ESB 最簡單的用法之一就是訊息佇列，它完全可以充當 JSM 佇列的替代。 NET Service Bus 還是開發者友好的。 它既支援使用 XML 的輕量的 RESTful 介面，也支援較重量的、包括了 WS-* 標準全部實現的基於 SOAP 的介面。 這兩個介面均支援現有應用程式和 NET Service Bus 間的簡便的互通性。

SalesForce.com

SalesForce.com 提供了一個模型，借助這個模型，開發人員可以使用其 Apex 開發語言來訪問 SalesForce.com 服務。 SalesForce 稱 Apex 是 「世界上第一個隨需應變的程式設計語言」。 隨需應變主要表現在 Apex 代碼託管于 SalesForce 的 Force.com 雲服務，並在該上下文運行。 在句法方面，Apex 與 JAVA 或 C# 語言類似。

Apex 代碼被用來生成服務于 VisualForce 層的 Web 頁面，該層就是實際的使用者介面。 它也使用了 Model-View-Controller (MVC) 模型。 這非常類似于 .NET 中借助 C# 生成 ASPX 頁面。 這些 VisualForce 頁面可以包含 HTML、Ajax（XMLHttpRequest 物件）及 Adobe Flex。

VisualForce 允許開發人員在 SalesForce.com Web 介面上創建不同的變體。 這對於喜歡 SalesForce.com 但又想向其添加功能的公司來說十分有用。 與其要求 SalesForce.com 構建這種功能性，不如讓 Salesforce.com 的使用者通過創建 VisualForce 頁面並用 Apex 代碼將它們寫入 SalesForce.com 後端來實現同樣的目的。

Salesforce 還提供了控制器，用來連接頁面表示與來自 SalesForce 資料庫的底層資料，包括如 Edit 或 Save 這樣的標準的常式。 Force.com 雲實現了巨大的成功。 它不僅為開發人員提供了在雲上構建應用程式的方法，借助它，還可以通過直接發行模型來向使用者收取這些應用程式的使用費用。 然而，它是一個非常專門化的雲。 它並不太適合增量方法。 通常需要對 Force.com 雲進行構建。

結束語

在本文中，我們瞭解了不同的雲服務提供者能為我們帶來的各種功能，另外還學習了如何使用這些雲服務來代替 JMS 佇列以及如何將一個現有的應用程式轉變成一個混合的雲應用程式。 在接下來的兩篇文章中，我們將瞭解綁定本地應用程式與雲服務的這個混合模型是如何實現的。 我們還將研究能夠影響雲計算的安全與管理方面的重要問題。