發行項
08/13/2015

本文章是由機器翻譯。

Windows Azure 內幕

Windows Azure 服務匯流排和互聯網的東西

機器到機器 (M2M) 計算正迅速成為一種技術，所有開發人員和架構師需要擁抱。許多研究表明一個未來世界的數百億美元的設備 (在地球上的每一個人的出現），到 2020 年 (bit.ly/M2qBII)。這種情況發生的原因之一是因為它一直都不容易為車庫修補匠和愛好者到原型消費者或商業化的設備，為以後的製造和銷售。硬體和軟體入門是非常低廉的。少於 100 元，您可以訂購 Arduino 或覆盆子 PI。

但你做得到什麼您支付和這些設備 — 尤其是 Arduino — 代表低端的裝置功能頻譜。32 KB 的快閃記憶體存儲和 4 KB 的 RAM，他們缺乏運行除了 Web 堆疊的最簡單方面的權力。Arduino 是開源微控制器裝有一個小小的晶片、記憶體和存儲。該套裝軟體括一個標準的程式設計語言編譯器和微控制器執行的引導載入程式。您可以添加擴展板插頭到該設備，勾搭電機控制、 GPS、乙太網、液晶顯示、感應器、執行器和更多。有點多付錢，你可以得到更強大的樹莓 PI，附帶了一個版本的 GNU/Linux 作業系統和 256 KB 的 RAM。

這些設備很少具有價值，除非它們連接到別的東西，或許雲後端接收資料併發送命令。但連接到、溝通和管理這些設備從運行在雲計算中的應用程式帶來了一些特殊的挑戰。數量的設備，以及其有限的電池壽命和頻寬，部隊雲開發人員要仔細考慮所有的選項。

在本文中，我們會看看如何開發商正在努力克服定址能力、頻寬和安全的關鍵挑戰。我們將揭穿神話 IPv6 和虛擬私人網路絡 (Vpn) 是簡單、高效和安全的並會建議 Windows Azure 服務匯流排是完美的產品，優雅地克服這些挑戰。開車回家的一些概念，我們會提出四種模式時，可以使用您的用戶端設備與雲後端進行通信。最後，我們會提出服務匯流排支援為先進的訊息佇列協定 (AMQP) 1.0 簡介 — 一種互通性和高效率的設備到雲通訊協定。

許多年來，安全意味著使用 IPv4，Vpn 結合使用 TCP/IP 的連接。這相當不錯，但現在出現了年齡的跡象。對於初學者，很難把唯一的 IP 位址出來了公共互聯網上使用的一種設備 — 我們有很多 IP 位址枯竭。IPv6 將來到搶救這辦法應許的死硬風扇。傳統的看法是如果你給設備唯一的 IP 位址，解決你所有的困難問題。不幸的是，這解決了整個問題的只有一小部分。給它自己唯一的 IP 位址的每個設備絕對不是許多人的期望的銀色子彈。

要明確的是，IPv6 和 Vpn 是充滿擁擠、連接設備的世界中存在的問題。頻寬，尤其是一個挑戰。健談的設備和網路之間的連接會導致過多的流量。此外，使用典型的 HTTP 要求/回應方法為所有消息傳遞的排水渠電池壽命在許多設備上。也許最重要的是不能保證安全。Vpn 是在某些情況下絕對不安全。之前提出一個解決方案，讓我們更加深入，探討這些問題。

創建網路通信量過大與雲回通信結束有問題的設備。如果有許多健談設備頻寬費用的錢，可能很多錢。此外，更多的資料意味著更多的 CPU 使用，這意味著更多的能量，在行動裝置上寶貴的資源。大多數電池供電設備配備一個無線發射器和一張 SIM 卡需要輸入期間，當他們不是發射或接收資料的低功耗的"睡眠"模式。IEEE 802.11 標準定義了此電源保存輪詢功能。資料獲取緩衝設備睡覺的時候。一旦它喚醒，緩衝的資料被傳遞。健談網路填充緩衝區和過早地喚醒沉睡的設備。

HTTP 要求/回復的辦法可以是可笑地浪費資源，給予相對於整體的 HTTP 要求-有效載荷的大小應對基礎設施。假設一個設備只需要向雲報告數量如溫度、壓力或 GPS 協調。二進位資料可能是只有幾個位元組的大小，但是 HTTP POST 一般是至少 500 至 1,000 的位元組數，僅從 200 到 2000 位元組的請求標頭。當然，有些開發人員用的特技，餡的一切入的 HTTP 標頭，以避免在 HTTP 要求的正文部分的開銷。但這並不是充足的和 HTTP 要求的大小僅獲取更大的時候你要傳輸的安全憑據。

這裡是一些簡單的數學，要說服你。想像一下您的設備已發送溫度資料每隔 5 秒和溫度的資料負載是慷慨的 20 個位元組。在 24 小時內，從設備到雲大約 350,000 位元組傳輸將本身的溫度資料。如果您添加的 HTTP 要求/回應信封，您每個傳輸通過提升 800 個位元組，一個因素 41，而不是只是在 350 KB 的溫度資料雲向發送超過 14 MB。這可以得到費用昂貴，如果你支援數以千計的設備。

也許最大的誤解是 Vpn 是本質安全。現實是 VPN 網路可以是有風險的尤其是當設備連接到 VPN 是製造商的或運營商的直接物理控制範圍之外。一旦違反了單個設備，連接到同一 VPN 的所有設備都都易受傷害。一旦一個不受信任的使用者獲取對已連接的設備的訪問，他或她可以使用該設備來探索和攻擊您的內部資源。儘管有這些缺點，Vpn 往往是由許多運營商提供的唯一選項。

Windows Azure 服務匯流排方法

Windows Azure 服務匯流排提供一些優秀的解決方案，對這些挑戰。利用服務匯流排是更安全，因為該設備是僅上互聯網的終結點，它可以將消息放入佇列。該設備不能達到內部雲服務的其他受保護的網路資源。此外，使用服務匯流排設備連接成本較少的電源，因為該設備可以更經常睡覺，醒來後定期要拉出任何等待佇列中的消息。

服務匯流排提供更多價值，因為它可以：

解耦設備溝通和互動從您的雲服務
啟用負載調配間和負載平衡您的後端服務的幾個實例
找出重複的消息
收集郵件到邏輯組（稱為會話）
執行事務行為和原子性
支援有序的傳遞的郵件，並為每個消息提供時間生活
延長以發佈-訂閱者案很容易使用的主題和訂閱

若要獲得更具體的概念設備如何連接到並與雲後端進行通信，看看圖 1，其中描述了如何專用設備可能適合到更大的體系結構。我們將使用 OpenSprinkler，開放原始碼的是能夠在決定打開水龍頭前檢查天氣的基於互聯網的噴灌閥門控制器的典型示例。它是使用 Arduino 零件生成的。注意在圖 1 Arduino 控制作為互聯網連接使用家用網路的自動噴水滅火系統，並與雲後端進行通信。

圖 1 Arduino 自動噴水滅火系統參考體系結構

解決連接問題

Windows Azure 服務匯流排能夠很好地解決的定址能力和網路連接性挑戰。Arduino 設備可能會坐在一些 NAT 層，因此很難從一個雲服務達到後面。幸運的是，服務匯流排大大簡化連接了由作為中繼服務，作為雲後端的代理。此外，它可以提供佇列、主題和訂閱，從而使其能夠作為事件中心的雲計算和設備之間發送的消息。作為中繼代理佇列的解耦的性質允許設備以非同步方式發送和接收郵件，從雲，即使只是偶爾連接。為了安全，該設備可以與 SharedAccessSignature、 SharedSecret、 SAML 或 SimpleWebToken 身份驗證。

注意在圖 1可從服務匯流排訊息佇列中讀取一個或多個輔助角色。輔助角色可以作出的決定和回設備發出命令。其他工作者角色可能從其他系統如國家氣象服務獲取天氣資訊。輔助角色也可能到 NoSQL 資料庫中，如 MongoDB 保存所有未處理傳入的事件。

圖 1 還顯示交互 Web 角色的移動使用者，可以安排澆水。移動使用者可以接收推送通知從 Windows Azure 移動服務（WAMS），它支援所有的主要通知網路，WindowsNotification Services（WNS）、 Microsoft 推送通知服務 (MPNS)、蘋果推送通知服務（資深護師) 和谷歌雲消息為 Android (GCM) 等。廣域測量系統容易地支援 Windows、 iOS 和 android 系統。

你甚至可以想像機器學習體系結構的一部分。Windows Azure 可以支援 Linux Vm 和很簡單配置 PyMongo （MongoDB 驅動 Python 程式）讀取事件流產生的各種設備和使用在 PyML 中的機器學習技術來查找模式或對事件流資料作出的預測。基於某些預測或圖案，雲服務可以選擇將命令發送到該設備，如開啟或關閉水。

消息傳遞系統，是用於發送和接收資料的主端點是可擴展的因為設備可以繼續發送單個消息流，雖然新的訂閱可以添加到每個新的系統，將消耗該消息流服務巴士主題。這些系統可以即時分析和機器學習，以及前面所述的其他方案。

雲計算與通信

有四個模式，可以在用戶端上用來與雲服務進行通信。在介紹了這些圖 2。

圖 2 四個型態的設備雲服務通信

圖樣	摘要	示例
遙測	用戶端設備向雲服務發送資料（單程）。	設備將有關溫度的消息發佈到主題。雲服務訂閱一些或所有這些溫度的郵件。
調查	用戶端設備查詢向雲服務發送和接收的回應。	設備通過張貼到某個主題的天氣查詢詢問了即將到來的天氣條件。雲服務訂閱查詢和職位到它自己的主題的消息回應該設備所訂閱。
命令	向用戶端設備發出命令，雲服務和用戶端設備返回一個成功或失敗的回應。	雲服務將溫度消息命令發佈到一個設備所訂閱的主題。該設備然後打開或關閉的水，通過過帳到某個主題的回應發送回雲服務的答覆。
告知	雲服務發出一個單向的帶外通知到用戶端設備是重要的設備的操作。	雲服務將時間重置消息發送到設備，通過向該設備所訂閱一個主題發佈消息。

所有四個模式利用服務巴士主題和訂閱。根據通信（設備雲服務或雲服務到設備）的方向，該設備可以訂閱的主題，或者發佈到主題。主題是只是一種機制，發送的郵件，而使用訂閱，則要使用的消息。您可以創建篩選器規則，以允許更多的細細微性控制檢索消息時的訂閱。可以用於輔助角色在雲服務中的，將消息發佈到主題或消耗從訂閱消息。

由於空間的限制，我們不能說明所有的模式在這裡在這篇文章，所以我們會深入研究只是其中一個。圖 3 顯示命令模式的參考實現。它演示設備從建築物 1 和 2 可以訂閱消息（命令）和後返回到主題回應。請注意在雲服務工作者角色可以對溫度和樹蔭下命令主題發佈消息和特定的設備可以單獨訂閱的溫度或樹蔭下控制訊息。服務巴士主題和訂閱可用於多種組合中適當地進行分區的消息流。

圖 3 為命令模式的的體系結構

AMQP 和相互聯繫

Windows Azure 服務匯流排團隊最近宣佈為先進的訊息佇列協定 (AMQP) 1.0，一個開放的標準與面向消息的中介軟體的二進位應用程式層的支援。它的主要價值是它是高度互通性和它使用的二進位格式在電線上，儘量減少有效載荷大小。

AMQP 支援可靠的消息傳輸、佇列、路由、 pub/sub 和更多。因為它是針對整個網路流媒體的資料線級協定，任何相容的工具可以與執行語言無關的資料進行交互。這使得跨平臺的混合應用程式使用的開放的、標準的協定。圖書館可以混合和匹配語言、框架和作業系統，支援.NET，JAVA，Python PHP。你會發現在 Windows Azure範例頁的詳細資訊 aka.ms/G3izk8。設計為光和除可操作，AMQP 是一個很適合今天的設備需要連接到雲後端的很多。

然而，AMQP 是太多軟體，今天的 Arduino，缺乏必要的記憶體、存儲和處理能力。運行 AMQP 需要支援傳輸層安全 (TLS)，一種加密協定，提供了 com通過 TCP 服務的安全。TLS 使用 X.509 憑證（非對稱加密技術）來驗證的跨線通信各方身份。此外，Apache Qpid 質子基於用戶端消息庫通常用於 AMQP 來簡化跨路由器、橋樑和代理伺服器的通信與整合。這一切引起了問題：你如何支援低端設備連接到後端雲同時享受服務匯流排消息處理基礎結構的好處？

一個選項是要付出更多的錢和獲取樹莓 PI。如果你不想要這樣做，你就會需要更具創造性。您可以通過利用Clemens Vasters啟動 ' 在代碼 bit.ly/1acvLdS，其中允許接收命令眨眼微控制器上的 LED 燈 Arduino。代碼實現設備的閘道，提供 Arduino 連接到 TCP 端點。要維持通過 Nat 和 Windows Azure 負載平衡器的連接，雲服務需要 ping Arduino 每 235 秒（只是不到 4 分鐘）。請參閱 Vasters C# 專案，LedBlinkerServer。

在我們下一列中，我們將進行更深入解釋代碼如何工作以及如何你可以 Arduino 來發送和接收到來自服務匯流排的消息。

總結

在本月的專欄中我們提出了四種模式，可用於生成管理處能消息交換設備和雲服務之間。我們引進了 AMQP 的開源訊息佇列的協定，有助於提高互通性和最小化頻寬，完全支援 Windows Azure 服務匯流排。最後，我們開始討論如何支援低端設備連接到後端雲同時使用的服務匯流排消息傳遞基礎設施，我們會繼續在我們的下一條。

我們想感謝Clemens Vasters和阿彼錫 Lal 説明我們理解連接設備的勇敢新世界。顯然，連接到雲服務的專用設備的世界正在迅速增長。採用傳統的方法與雲服務通信時需要進行重新求值。安全、頻寬、網路可靠性和互通性，只是一些與專用設備在 M2M 世界設計師和開發人員面臨的挑戰。使用 Windows Azure 服務匯流排使得這些遠同樣艱巨的挑戰。

Bruno Terkaly 是微軟開發者福音傳教士。他深入的知識來自于多年的經驗在欄位中，編寫代碼使用多種平臺、語言、框架、 Sdk、庫和 Api。他花時間編寫代碼，寫博客，給現場演示上構建基於雲計算的應用程式，具體地使用 Windows Azure 平臺。您可以閱讀他的博客在 blogs.msdn.com/b/brunoterkaly。

Ricardo Villalobos 是具有超過 15 年的經驗設計和創建應用程式的公司在多個行業的經驗豐富的軟體設計師。他從達拉斯大學工商管理持有不同的技術認證，以及碩士學位，為微軟，説明世界各地的公司要在 Windows Azure 實施解決方案作為一個雲建築師在 DPE 全球範圍內參與合作夥伴團隊工作。您可以閱讀他的博客在 blog.ricardovillalobos.com。

Terkaly 和比利亞洛沃斯共同提出大行業會議。他們鼓勵讀者的 Windows Azure 內幕交易與他們聯繫的可用性。也可以撥打 Terkaly bterkaly@microsoft.com 和比利亞洛沃斯也可以撥打 Ricardo.Villalobos@microsoft.com。

感謝以下 Microsoft 技術專家對本文的審閱：阿彼錫拉爾和Clemens Vasters