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

　　一）Azure

　　二）Google Cloud Platform

　　三）AWS

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

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

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

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

　　二、現(xiàn)成功能

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

　　三、所支持協(xié)議

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

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

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

　　五、支持完整堆棧

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

　　六、價(jià)格

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

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

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

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