[翻譯圖書] Moving Applications to the Cloud on the Microsoft Windows Azure Platform – 2

第一章 介紹Windows Azure平台

Microsoft Windows Azure 技術平台提供了一個點播的, 雲端式的計算方式, 這裡的雲指的是存在於一個或多個資料中心裡互相串連著的電腦資源. 當前, Windows Azure平台在美國, 歐洲, 也亞洲都有資料中心. 研發人員可以使用雲來部署和運行應用程式以及儲存資料. On-premises的應用程式也可以使用雲端式的資源. 比如說, 存在於On-premises的一台伺服器上的一個應用程式, 一個運行在案頭電腦上的胖用戶端, 或者是運行在行動裝置上的用戶端, 他們都可以訪問在雲中儲存的資料.

 

Windows Azure平台通過虛擬化抽象了硬體資源. 每個部署在Windows Azure中的應用程式都運行在一台或多台虛擬機器上. 這些被部署了的應用程式表現的就像它們各自存在於專門的實體電腦上一樣, 但他們可能卻與存在於同台物理機裡的其他眾多虛擬機器共用著諸如硬碟空間, 網路IO, CPU核心等資源. 物理硬體上面的抽象層的一個關鍵好處是可移植性和可擴充性. 將服務虛擬化可以允許他在任何數目的物理實體機中間移動. 通過結合虛擬技術, 商品硬體, 多租戶, 和彙總需求, 微軟達成了規模經濟. 這些產生了更高的資料中心的利用率, 即硬體的按金分配, 接下來就是為你省錢了.

 

虛擬化還允許你既有垂直的可擴充性, 也有水平的可擴充性. 垂直可擴充性意味著, 隨著需求的增長, 你可以增加每個虛擬機器的資源的數量, 比如說CPU核心或記憶體. 水平的可擴充性意味著你可以添加更多的已有服務的虛擬機器的拷貝. 所有的這些執行個體都是在網路層次做了負載平衡的, 所以到來的請求會在這些虛擬機器之間進行分配.

在本文寫作之際, Windows Azure平台包括三個主要的組件:

• Windows Azure
• Windows Azure plat-form AppFabric
• SQL Azure

 

Windows Azure提供了如下的能力:

• 基於Windows的應用程式計算環境
• 結構化, 非結構化資料存放區, 還有非同步資訊傳遞

Windows Azure platform AppFabric 提供了兩項服務:

• Service Bus, 協助你串連在on-premises 或公用雲端中的服務, 忽略網路拓撲邏輯的細節.
• 存取控制服務, 使用security token為基於Representational State Transfer (REST)的web service管理認證和授權.

SQL Azure本質上就是雲中的SQL Server.

平台還包括各種管理服務, 能允許你控制所有的這些資源, 基於web的使用者介面也可以, 編程方法來控制也可以的. 在多數情況下, 可以用REST-based 的API來定義你的服務如何工作. 多數的可以通過web portal完成的管理工作也可以通過API完成. 最後, 微軟提供了完整的一套工具和SDK, 能夠允許你在本地的類比環境下開發, 測試你的應用程式. 這個本地的測試環境叫做"development fabric". 多數的工具都被整合到了Visual Studio中. 另外, 還有第三方的管理工具可以使用.

                                        

The Windows Azure Platform

----------------------------------------

在Windows Azure中, 整個計算環境會可靠地處理請求和儲存資料. 一個內部的子系統, 叫做"Windows  Azure  Fabric  Controller  (FC)"的, 管理所有的計算和儲存資源, 部署新的服務, 監管所部署的服務的健康狀態. 當一個服務掛掉的時候, FC會建立必要的資源, 重新部署這個服務. 另一個Windows Azure平台的組件就是SQL Azure. SQL Azure是一個雲中的關聯式資料庫. 本質上說, SQL Azure是一個微軟SQL的一個巨大的子集. 儘管SQL Azure是Windows Azure儲存服務的一個補充, 實際上他們是不同的.

 

在本書還在寫作的過程中, Windows Azure platform App Fabric提供了兩個服務: Service Bus和Access Control Services.

Service Bus允許你串連到應用程式和服務, 不管這些服務在哪裡.  比如說, 你能夠串連在企業防火牆之內的on-premises的application到運行在雲中的service. 它實現了普通的訊息和溝通模式, 比如event, one-way message, publish, subscribe, remote procedure call (RPC)風格的資訊交換, 還有為streamed data服務的tunnel.

Access Control服務允許你為基於REST的服務管理identity. 他實現了一個token-issuing service, 這服務也提供了token轉換的能力. Windows Azure platform AppFabric在這份指導中並沒有討論. 更多資訊, 可以參考本章後面的reference. 記住, Windows Azure platform AppFabric 和Windows Azure Fabric Controller是不同的.

 

除了這些組件, Windows Azure平台還提供了對service的診斷服務, 比如對應用程式健康情況的監控.

在Windows Azure中所有的儲存和管理子系統都使用基於REST的介面. 他們不依賴任何的.NET Framework或Windows作業系統. 任何能發行HTTP或HTTPS請求的技術都可以訪問Windows Azure的

裝置. 典型地, 在Windows Azure中啟動並執行應用程式會有多個執行個體. 這些案例的每一個都運行在有Windows Azure建立和管理的Windows Virtual Machine中. 目前, 你不能像使用Virtual PC或Virtual Server一樣的方式來訪問這些虛擬機器. Windows Azure替你控制了.

要開始瞭解Windows Azure platform, 請訪問http://www.windowsazure.com.

 

Windows Azure Compute

-------------------------------------------

在Windows Azure中啟動並執行應用程式被稱為"hosted service". 典型地, 一個hosted service包含不同的計算資源, 他們一起處理資訊, 和彼此通訊並和外部世界互動. Windows Azure裡的Hosted service是有角色的, 目前有兩種角色可用: Worker Role和Web Role.

 

Work role是通用的代碼宿主. 它們頻繁地被用於處理長久啟動並執行任務, 還有非互動的任務. 但實際上, 你可以讓它寄存任何種類的工作. Work Role已經通用到甚至可以寄存整個應用程式平台, 比如Microsoft IIS服務, 或者Apache Tomcat. Windows Azure初始化和長時間運行work role, 就像運行Windows Service 一樣.

 

預設地, 你可以認為web role是擁有IIS的特殊的worker role. 所以, 他們能夠寄存web applications和web services. 表徵圖1描述了Web Role 和Worker role.

 

典型地, 一個Web Role執行個體接受到訪連接埠80或443的http或https請求. 這些公開連接埠被叫做"public endpoints". 所有的public endpoint都是在網路層面自動被負載平衡的. Work role和web role二者都既可以向外發出TCP串連, 也可以為進來的串連開啟endpoints.  除了負載平衡的public endpoint之外, 執行個體間還可以開啟內部的endpoints. 這些internal endpoints既不是負載平衡的, 對Internet也不可見. 作為替代, internal endpoints能夠被用來進行執行個體間和角色(role)間的同步通訊.

 

同時運行著web role和worker role的虛擬機器執行個體還運行著一個Windows Azure agent(代理人). 這個"代理人"暴露了一個API允許該執行個體跟 Windows Azure FC互動. 比如說, 一個執行個體可以使用"代理人"來遍曆該虛擬機器執行個體所有公用的和內部的endpoints, 而這些endpoints可能是該虛擬機器正在使用的, 或是用來發現運行時配置的.

 

部署的應用程式的web role可以通過ASP.NET, Windows Communication Foundation (WCF), 或任何能與IIS協同工作的技術來實現. 比如說, 你可以弄一個寄存在Windows Azure中的PHP應用程式, 因為IIS通過Fast CGI支援這它. Fast CGI是一個規定了如何與web server中的應用程式的介面的協議. 大多數的web role應用程式都是針對"要求-回應"模式的負載而最佳化過的, 這裡請求與響應之間的時間間隔在理想情況下是非常短的.

 

對Web Role的一項關鍵的衡量指標就是"session management", 即會話管理. 在標準的ASP.NET應用程式中, 是由某些方法儲存工作階段狀態(session state)的. 比如說, 線上商店會儲存一個購物車. 與web伺服器陣列相似, 在每台伺服器執行個體的記憶體中儲存工作階段狀態(session state)對於基於web role的網站來說是個讓人撓頭的問題. 因為不能保證使用者每次發出請求後都會被重新導向到相同的web role執行個體上. 取而代之的是, 你會在web role執行個體之外的地方去維護工作階段狀態(session state)的資訊, 比如說Windows Azure Storage, 或是SQL Azure, 或是你發回給用戶端的cookie, 或是在隱藏的表單元素中.

在Windows Azure中最常見的應用程式模式是讓web role接受到來的請求, 然後用Windows Azure的queue來傳遞這些請求給worker role去處理. Worker Role定期地去queue裡讀取資訊, 來查看是否有工作要做. 如果有的話, 它就開始執行任務. 典型地, Web Role會從persistent storage中接受完成了的工作, 比如說一個blob, 或是一個table. Figure 2 展示了這個典型的設計模式.

 

 

這是種簡單並且常見的Web role與worker role之間的互動方式, 但是也還有許多其他可能的互動方式的. 比如說, 你可以使用WCF來串連Web role和worker role.

在Web 和worker role上啟動並執行"代理人"的另一項功能是通過FC來維護系統的心臟跳動. FC會監視VM們和物理機們的健康情況.如果應用程式由於在代碼中出現了錯誤而變得沒有響應, 或者執行個體底層的硬體出現了當掉的情況, FC會採取任何恰當的措施來進行恢複.  如果應用程式崩潰了, FC可能會簡單地重啟失敗的執行個體. 在物理層硬體錯誤這種極端情況下, FC會嘗試遷移受影響的執行個體到資料中心的另一台物理機上. 任何時候FC都會嘗試保持儘可能多的你指定了的眾多執行個體的運行.目前還沒有自動衡量(auto-scaling )能力. 你要對Windows Azure中的計算資源的執行個體的數量負責, 要麼通過Web Portal對數量進行控制, 要麼就通過management API來進行控制.