# Microsoft Azure - Microsoft Azure - 大圖 作者?[Tony Meleg](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Tony+Meleg)?| 2015 年 10 月 每個月，本雜志都會向讀者詳細介紹 Microsoft Azure 的某些新的或有趣的服務。對于開發者來說，開發之路是永無止境的，但是通往成功的道路往往不止一條，這有時候會給人們造成困擾。將零零散散的信息匯聚起來形成一張“大圖”并不是一件簡單的事情。 我們的行業正不斷創新，對于 IT 組織和 IT 從業者來說，無法查看大圖將會引發實際問題。本文全部旨在幫助你了解 Azure，避免關注細枝末節 - 這與我們的日常工作正好相反。 讓我們面對它吧，即使開發者并不是時時刻刻擅長化難為簡。通常，面對某個簡單的問題，我們會實施非常復雜的解決方案。我們需要了解相關工作原理，尤其是那些并非由我們本人生成的工作。在某種程度上這屬于信任問題，但也使我們可以了解如何調整和微調軟件的某個組件或整個軟件，以滿足我們的特定需求。這也關乎于控制。 ## Microsoft 的大手筆 如果你對我關于開發者的主張耳熟能詳，那么你可能對我接下來的介紹不感興趣。Azure 是一個由應用程序構建基塊或“服務”組成的集合，其中每一項都提供你有時可能在要生成的應用程序中需要的不同功能。Microsoft 相信這些塊可自我復原、可高度擴展并且可自行管理。你可以在世界各地提供任何服務、僅支付你所消費的部分，最重要的是，你可以隨時隨地更改你的消費。你可能不喜歡的是： 這些服務才剛剛開始。它們簡化了你的工作；你對它們的控制可能會大大減少；你看不到它們的內部。換句話說，除了信任它們，你別無他法。這聽起來并不像你會感興趣的事情，對嗎？因為你想要獲得控制權，你不“信任”，而且你喜歡復雜的事情？ 你可以大致將 Azure 分為三層：數據中心基礎結構、基礎結構服務以及平臺服務，如圖 1?所示。 ? 圖 1 Microsoft Azure 概念視圖 你可以理解為這三層彼此堆疊，每一層的下面都有一個抽象層。所以，基礎結構即服務 (IaaS) 主要是基礎物理服務器、存儲和聯網的抽象。平臺即服務 (PaaS) 是應用程序軟件基礎結構的抽象，它通常安裝在服務器上并在創建 Web 服務器、數據庫、消息傳遞系統和標識基礎結構等的應用程序時使用。該服務的職責不在于提供軟件本身，而是提供給你一項可持續運行、可復原、始終在線的服務（以及幕后操作來以透明方式監控和修復任何問題，而不會降低應用程序的性能）。 這些服務不僅可用在 Azure 公有云中，也可用在其他任何地方。它可以充當你的數據中心、主機或者外包程序。Microsoft 最近推出了 Azure Stack 來實現此理念 - 它將作為 Azure 的秘密武器和服務提供，并將部署到你自己的硬件上。畢竟，它也只是在 Windows Server 和 Hyper-V 的核心基礎頂端生成的軟件而已。在這個新世界里，你并不真的關心如何正確構建解決方案以及如何計劃服務，因為你的注意力集中在你所需要的服務上。 ## 平臺構建基塊 所以，讓我們大致看一下 Azure 整體。圖 2?列出了一系列功能組中的所有服務，可跨基礎結構服務和平臺服務拆分。應該將基礎結構服務視為允許你為現有應用程序創建低級別基礎結構的功能。你需要裝有磁盤的計算機；需要將其聯網在一起；需要共享磁盤；并且需要將它們連接到其他位置上的其他系統和網絡等等。 ? 圖 2 Microsoft Azure 服務 在基礎結構服務層上，抽象更為人熟知，因為它們代表基礎物理數據中心，例如以虛擬機 (VM) 形式存在的計算機以及附加到計算機的虛擬磁盤。它允許你運行已有系統，并且如常執行操作，因為唯一的抽象是計算機，而不是你可能使用的應用程序軟件。你仍然有責任安裝、管理、修補、修復以及復原在聯網的 VM 中或之間運行的任何軟件，其操作方式與你在自己的數據中心中的操作方式一致。 與此相反，平臺服務包含使你遠離服務正在使用的較低級別的計算機/存儲/網絡的功能；也就是說使所有抽象對象遠離你。一般來說，如果無法實際接觸或者連接到特定服務中的基礎 VM，則服務就是 PaaS。同樣，你無需選擇提供服務的軟件，也無需調試或者控制該軟件。該服務的職責是適合工作、自我修復和修補，并且監控所有 Azure 數據中心內所需的服務的所有部分。你只需要關注如何使用它 - 無論如何，這才是你的實際工作。 ## 旁白 - Azure 數據中心基礎結構 你可能感興趣，因為我們所有人都對促進 Azure 的所有基礎復雜計算和數據中心基礎結構很癡迷。你可能想了解服務器的物理硬件規格、所使用的交換機以及機架的構建方式。你可能想了解可在所有服務上提供超級快的恒定速度的復雜網絡拓撲，以及可將 Azure 數據中心區域連接在一起的全局網絡。可能你很好奇目前全世界裝有 Azure 的全部 24 個數據中心區域（或者即將在加拿大和印度推出的 5 個新區域），如圖 3?所示。 ? 圖 3 Microsoft Azure 全球數據中心足跡 這是你作為開發者在新領域內進行的首次嘗試： 至少在 Azure中，你不需要再考慮它。如果你想在自己的數據中心中使用 Azure Stack 生成自己的“Azure”，你（或你組織內的其他人）仍然需要將所有這些物理條件考慮在內。你在過去需要考慮這些（甚至需要考慮特定應用程序所需的基礎結構）的其中一個原因是：萬一出錯，付出的代價將非常高昂。你無法真的了解所需服務器的數量和大小；你假設最差的情況，并在此基礎上增加一些，以防萬一。在 Azure 中，這些問題都不會出現，因為需要多少，提供多少即可。如果你需要更大的計算機，則獲取一個大計算機；如果獲取的計算機過大，只需進行更換即可。在 Azure 中，你只需要確定應用程序用戶的所在地，以及哪些數據中心最適合用來交付解決方案。通常是最接近的那一個。 ## 基礎結構服務 - 更可控、更有效 當你在圖 2?中查看 60 項左右的服務時，列表可能會使人感到困惑。但是，大多數時候，你生成的大部分應用程序中僅包含很少的功能。通常，具有核心 Web 服務器和關系數據庫，以及很多用來標識、報告以及執行一些批處理操作的其他對象。現在，我們將專門討論 Web 基礎結構和數據庫。 你可以立即做出選擇： 你是否從事基礎結構或平臺層抽象方面的工作？ 你是否啟動某些 VM、安裝 Web 服務器及數據庫并開始運行？ 請記住，這一抽象主要關于物理服務器、存儲/磁盤以及網絡，而非需要在這些服務器上運行的軟件。聽起來很容易、很熟悉，猜一猜這是什么。這就是你整個職業生涯中要做和已做的事情。請看一下圖 4。VM 具有虛擬磁盤，這些磁盤可以跨 VM 共享，或者附加到特定計算機。VM 可以放在虛擬網絡內，以便它們可以通信，而且網絡可以連接到你自己的數據中心，以及跨越 Azure 區域。這些都是通過該軟件抽象實現的，這意味著你最后使用了一臺具有一個或多個磁盤的計算機，并且位于與其他計算機連接的網絡中。 ? 圖 4 服務器、磁盤和聯網的虛擬機抽象 你需要對 VM 集內部所需的一切進行控制、優化、調整、調試和干擾。事實上，因為使用了抽象，它甚至比你的本地環境更有優勢。你無需再考慮物理計算機、主機操作系統和虛擬機管理程序。無需擔心虛擬磁盤的底層存儲基礎結構的復原。提供了一組幾乎令人難以置信的 VM 大小以供選擇（CPU 和 RAM 的不同組合，以及不同的磁盤大小、速度以及網絡帶寬）。 更好的是，它是全自助式服務，每一項都可以自動化，因此可以非常輕松地定義所需的基礎結構，并通過一個簡單的腳本啟動數百個實例。 假設你的應用需要適當程度的伸縮和復原。可輕松創建 VM 和 Web 服務器的 Web 場，以及數據庫群集。你（或者與你關系最好的 IT 專業人員）知道如何實現所有這些操作 - 這并不簡單，但是可行。你可以隨時執行此操作，無論白天還是夜晚；可以在世界任何地方預配它；可以僅支付你所消費的部分并隨時更改主意、全部撤銷并且不購買任何物品。這多么不可思議？ 聽起來令人難以置信，有什么注意事項嗎？ 在基礎結構層上，你仍然需要執行大量工作來部署和運行一切。所有對象均運行后，你需要做更多的工作來使其持續運行。但是，這非常有用，尤其是當你想“讓它運行”時。在本地環境中，部署一組復雜的、互相關聯的 VM 時會出現更多問題，包括 Azure 中的功能（例如 Azure 資源管理器）、通過 Windows PowerShell 的自動化，以及許多來自第三方的其他解決方案。所有對象均工作后，你仍然需要修補你在 VM 內部使用的所有軟件，其中包括正在運行的任何操作系統。你需要管理所有應用程序軟件的運行狀況，這對于 Web 服務器和數據庫來說并不麻煩，但是當你向外擴展或者加入 5 個其他功能時，就會非常麻煩。 你需要對工作或工作量進行控制。如果你想控制，則需要付出更多努力來生成所需內容，并使其全部正常工作。 ## 平臺服務 - 控制越少、工作越少 你可能記得一句話“所有計算機科學問題都可以通過向其添加另一個間接層來解決。” 然而，有人在這句話后又加了一句“...但是，這通常會引發另一個問題。” 事實確實如此，平臺服務就是最明顯的例子。圖 2?中的 Azure 服務圖展示了用于本示例中所需的兩個構建基塊的兩個平臺服務抽象：Web 服務器和數據庫。在 Azure 中，這些抽象是 Web 應用（在 Web 和 Mobile 部分中）和 SQL 數據庫（在 Data 部分中）。在 Azure 中預配這些服務的方法與預配任何服務的方法一致，即轉至 Azure 管理門戶、選擇所需的服務并填入所需的詳細信息：服務名稱、數據中心位置、初始性能/定價等級等等。 從這里可以體現出控制越少/工作越少這一點。讓我們以數據庫為例。我在北歐的數據中心中預配了一個數據庫。在不到 1 分鐘的時間里，我的數據庫可以充分運行，我接下來要做的是向該數據庫部署架構和數據，然后連接到我的 Web 應用。不需要安裝軟件；我得到了所需的 SQL 數據庫。事實上，我不止得到了一個數據庫，我得到的是三個，它們在一個高度可用的群集里一起工作，使我獲得了難以想象的復原等級。我只需選擇不同的性能等級，即可上下調整三個數據庫的性能（可以更改我支付的價格）。你只能選擇這個三向群集數據庫；你必須接受它，因為服務始終希望確保能向你提供一個有效的數據庫，而這是最行之有效的方式。 正如圖 5?所示，當你使用 Azure Web 應用為自己的應用預配 Web 基礎結構時，將有一個類似的模型起作用。你可以使用簡單的滑塊選擇所需的實例數。你只需上下調整實例計數，該服務會完成剩余工作。甚至可以讓系統基于負載或計劃來為你完成此操作。更重要的是，服務的職責是始終提供你指定的實例計數，并且監控和修復斷開的實例。你只需要寫入 Web 應用代碼并將位傳遞給服務，以便它可以確保所有位在你的實例上均位于所需的適當位置。 ? 圖 5 更改 Web 應用實例計數 所以，平臺服務抽象提供的服務通常負責為你預配、復原和管理該服務。抽象引發的“其他問題”是你將失去一些控制權。你無法選擇軟件、無法訪問“內部”、無法調整和微調從操作系統到堆棧一直使用的軟件 - 你完全失去控制權。你失去的另一項控制權是你現在無法使用該服務的任何功能，也無法使用該服務的 API；也就是說，你無法干預應用程序代碼與該服務的交互方式。例如，你可能需要數據庫中提供而服務器不提供的一些具體內容。可能是特定數據類型，甚至是全文搜索之類的整體功能。你可能正在將現有應用程序移動到云，在你的應用中使用的功能與 Azure 中服務的功能不匹配。您將怎么辦？ 圖 2?中的 Azure 服務構建基塊圖列出了 IaaS 或 PaaS 中的所有服務，你可以“一起”使用它們，并且無界限限制。例如，沒有任何理由致使 PaaS Web 應用服務不能與安裝了 Oracle（在 Linux 上運行）或 SQL Server（在 Windows 上運行）的 VM 一起使用。現在，你可以平衡控制和工作量。事實上，你可以做的更多。由于所有這些構建基塊都在等候使用，所以理所當然地你可以從任何地方使用它們。它所需要的只是一個簡單 API 或者你已經用來與這些服務交流的一些現有協議。可以將這些塊中的任何一個與你自己的數據中心中的現有系統一起使用。也可以將這些塊與來自第三方（甚至是來自其他云提供商）的其他塊一起使用。當然，它假設應用程序可以容忍用戶造成的延遲問題，但這是可能的。 ## 其他服務 那么，你為什么需要 Azure 中的所有這些功能？ 如果你環顧自己的 IT 商店，你會發現在當今生產環境中運行的所有應用程序中，有相當一大部分的應用程序軟件使用這些應用：消息傳遞系統、數據分析功能、標識基礎結構、安全層、備份系統、數據倉庫、監控和管理系統等等。總的來說，在你的整個 IT 組合中，你需要所有這些“內容”。 我喜歡將 Azure 視為一組“IT 樂高積木”。 當你在生成下一個出色對象時，你并不是隨時都需要所有類型的塊，但是你的工具包中需要包含所有這些類型。 你如何決定在生成新的解決方案時使用哪些塊？ 這與之前沒什么不同 - 你需要了解構建基塊的功能，并使其符合你的應用程序的特定需求，然后進行調用。需要注意的是，在云中生成應用程序的方式不同，而且更為復雜。它兩種都不屬于，但是你需要執行一些其他操作，因為你的工作環境是“共享”基礎結構這一基本概念。這意味著許多服務都有約束，而且這些約束隨著所使用的各種功能級別和定價等級的不同而不同；你需要了解它們的具體內容。我記得你不喜歡一成不變；你想根據應用程序加載和需要自行調整。你需要保守地對這些約束以及服務可用性和響應作調整。你可以使用相同工具、相同語言和框架來生成解決方案，而且所有處于最低級別的服務都使用基于 REST 的 API 以及特定于框架的包裝程序。這意味著你實際上可以從具有簡單 Web 堆棧的任何對象（例如傳感器）訪問構建基快，原因是云推動了物聯網解決方案的發展。 云的好處是你可以快速迭代（因為它很容易啟動服務）；你可以嘗試一些其他方法；由于投入非常少，所以失敗也不要緊，而且造成的損失不大。回過頭來看圖 2。是否缺少某些內容？ 在圖中你可能會看到你不需要的對象，但是我敢保證你很難判斷哪些功能是你需要的或者已經具有的。我們為你提供了大量的指南，對每項服務都提供了廣泛的指導和詳細實施說明。 大多數開發者可以通過 DNA 獲得更多新信息。你有機會接觸更多技術，嘗試更多新鮮事物。即使你的公司幾乎從來也不生成任何對象，將它放到公有云中，開發者仍然可以從這一世界上最佳的位置獲得知識并快速成長。 ## 應變 在結束前我最后再講一個主題，就是如何應對變化。我必須要承認 Azure 的創新腳步異乎尋常的快，要想緊跟其步伐是一件非常困難的事情，然而這是我的工作。過去，你可以花費 3 到 5 年來研發產品特性和功能，但是這個時代一去不復返了。現在縮短為 6 個月。你會發現，在你生成內容期間，會出現新新功能甚至是整個新服務，它需要將這些內容評估和重構到你的解決方案中。設定 1 年的通知期后，功能和服務也可以被移除，而在過去的服務器軟件行業里，支持周期往往在 10 年以上。 服務版本控制現在出現了，這意味著向服務添加新功能可能會無法實現該服務以及在服務上生成的應用。所以需要決定是否進行版本控制，即是否創建新的端到端實現。這正是最近在 Azure 上通過 Azure SQL 數據庫完成的工作。有關 Azure SQL 數據庫版本 12 的新增功能，請查看?[bit.ly/1Dcjpo4](http://bit.ly/1Dcjpo4)?上的文章。 關鍵是使用云需要繳稅，你要有這個認知，并了解哪些因素會產生稅費。你需要了解云支持/變更通知過程，以便提早做計劃，而不會猝不及防。當然，稅費也會發生變化，與本地相比，它的稅費會更高，繳稅頻率會更大。但是不要因為稅費望而卻步，它的好處也是顯而易見的。它會顯著提高你的工作效率、大幅度提高質量并盡可能降低風險。 了解更多詳細內容？ 通過 AzureCon 虛擬活動，你可以獲得 Azure 專家意見、查看問題和答案并找到所有關于 Azure 最新創新的信息。你可以在?[bit.ly/1KRD76d](http://bit.ly/1KRD76d)?上注冊以訪問所有舉辦的展會信息。 * * * Tony Meleg?*是 Microsoft Azure 團隊的技術產品經理。他會抽出時間為各種受眾編寫技術信息、分享 Azure 的信息并用通俗易懂的方法讓大家了解復雜的內容。*