【51CTO.com快譯】在OnRue技術(shù)解決方案公司，我們一直致力于開發(fā)DataWheels，一款專門面向個人與公共交通方向的物聯(lián)網(wǎng)解決方案。而作為項目起點，我們首先需要選擇理想的物聯(lián)網(wǎng)平臺。盡管市面上的選項眾多，但我們?nèi)匀粚⒎秶s小為以下三種：

　　一）Azure

　　二）Google Cloud Platform

　　三）AWS

　　另外需要提醒大家的是，本項研究完成于2016年8月的第二周，因此在閱讀本文時，各平臺的功能可能已經(jīng)出現(xiàn)了些許變化。

　　一、架構(gòu)成熟度

　　在整體解決方案層面，我們需要一款能夠?qū)崿F(xiàn)輕松開發(fā)并具備常規(guī)REST服務(wù)、深入分析功能、消息收發(fā)隊列以及物聯(lián)網(wǎng)特定功能的解決方案。有鑒于此，谷歌的表現(xiàn)要落后于AWS與Azure。雖然谷歌的云平臺擅長托管通用型應(yīng)用并在分析方面表現(xiàn)優(yōu)異，但我們需要多路并進(jìn)從而以組合性方式滿足業(yè)務(wù)需求。以下參考架構(gòu)圖獲取自各相關(guān)站點。雖然我們能夠?qū)ζ溥M(jìn)行定制化調(diào)整，但作為理想的起點，改動越少顯然就越好。

　　谷歌參考架構(gòu) (援引自: https://cloud.google.com/solutions/iot-overview#telemetry)

　　AWS 參考架構(gòu) (援引自:https://aws.amazon.com/iot/how-it-works/)

　　Azure 物聯(lián)網(wǎng)架構(gòu) (援引自: https://azure.microsoft.com/en-in/documentation/articles/iot-suite-what-is-azure-iot/)

　　Azure還提供一項配置設(shè)定，即大家可利用自己的數(shù)據(jù)中心作為網(wǎng)關(guān)。只有Azure與谷歌提供流或者通道，用于簡化集成方式(AWS于今年9月發(fā)布了類似的方案)。在谷歌方面，其僅推薦使用pub/sub連接方式; 而在Azure與AWS方面，我們則擁有更多更為靈活的選項。總體來講，Azure在這一領(lǐng)域略占優(yōu)勢，而AWS則稍稍落后。雖然我們并不需要，但我注意到只有Azure與AWS提供從云到設(shè)備的消息傳遞機制。

　　二、現(xiàn)成功能

　　由于我們的解決方案將供最終用戶使用，因此其必須能夠激活并停用對方的設(shè)備。我們的物聯(lián)網(wǎng)平臺還需要啟用高級層級驗證與安全保護(hù)機制。只有Azure與AWS提供設(shè)備層級的驗證與激活功能。這亦意味著如果選擇谷歌云平臺，我們則需要自行開發(fā)此類功能。不過，AWS不提供相關(guān)管道的狀況則會在存儲輸入數(shù)據(jù)方面帶來難題。

　　三、所支持協(xié)議

　　考慮到設(shè)備與物聯(lián)網(wǎng)的特性，對HTTP之外廣泛協(xié)議的支持能力就變得非常重要。在這方面，AWS與Azure支持物聯(lián)網(wǎng)中頻繁使用的全部協(xié)議，包括MQTT、AMQPS以及HTTP。谷歌僅支持HTTP 2與gRPC。由于我們決定采用MQTT這一行業(yè)標(biāo)準(zhǔn)協(xié)議，因此我們無需進(jìn)一步測試MQTT、AMQPS以及gRPC之間的性能差異。在這種情況下，AWS與Azure的表現(xiàn)基本相當(dāng)。

　　四、開發(fā)難度(SDK可用性)

　　在我們的產(chǎn)品中，我們主要使用MQTT，而HTTP僅限于少數(shù)用例。Azure與AWS面向全部主流編程語言提供用于實現(xiàn)設(shè)備管理與物聯(lián)網(wǎng)消息傳遞(利用MQTT)的SDK。在HTTP方面，現(xiàn)有API與語言已經(jīng)足夠完成任務(wù)。谷歌亦為全部語言提供SDK，但其僅支持gRPC協(xié)議。在這項比較中，AWS與Azure仍然打了個平手。

　　五、支持完整堆棧

　　除了物聯(lián)網(wǎng)消息傳遞，我們亦有少數(shù)用例并非嚴(yán)格的物聯(lián)網(wǎng)特定機制(例如用戶登錄等)。我們希望利用部分無服務(wù)器計算功能執(zhí)行此類任務(wù)，在這方面三家供應(yīng)商皆提供支持。另外，我們還需要一套NoSQL數(shù)據(jù)庫，各供應(yīng)商同樣給出了自己的方案。在分析與機器學(xué)習(xí)(以及使用R、Spark等主流工具)方面，Azure與AWS的表現(xiàn)要比谷歌好一些(不過這一點暫時存疑，由于谷歌在前文提到的幾個方面較為落后，因此我們并未就此做出實際測試)。

　　六、價格

　　我們需要了解數(shù)據(jù)庫、運行時功能成本以及數(shù)據(jù)流分析等功能的具體使用價格。另外，我們還需要了解不同數(shù)據(jù)量及數(shù)據(jù)提取率情況下產(chǎn)生的實際支出(取決于具體設(shè)備數(shù)量)。在NoSQL數(shù)據(jù)庫方面，我們意識到谷歌的定價明顯更高。而在消息處理方面，AWS與Azure皆以消息數(shù)量為計費單位——不過二者對于一條消息的實際大小存在不同解讀。AWS的單一消息為1 KB，Azure則為4 KB。舉例來說，如果發(fā)送一條8 KB消息，其在AWS中將被視為8條消息，而Azure則僅為4條。根據(jù)我們的實際郵件大小以及近期用戶數(shù)量計算，Azure的消息收發(fā)成本比AWS便宜約50%。

　　因此權(quán)衡各方面因素，我們選擇了Azure作為自身物聯(lián)網(wǎng)平臺。

　　原文標(biāo)題：IoT Platform Selection: Azure vs. AWS vs. GCP，原文作者：Hariharan Anantharaman

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】