七牛架構師實踐日：構建高可用、可擴展的IoT云服務

七牛云存儲

2015-11-05 16:34 21459

在由七牛云主辦的架構師實踐日（深圳站）物聯網與智能硬件架構技術沙龍上，來自AbleCloud的技術合伙人孫志東進行了題為《構建高可用、可擴展的IoT云服務》的分享。以下是他的演講內容整理。

深圳2015年11月5日電 /美通社/ -- 在由七牛云主辦的架構師實踐日（深圳站）物聯網與智能硬件架構技術沙龍上，來自AbleCloud的技術合伙人孫志東進行了題為《構建高可用、可擴展的IoT云服務》的分享。以下是他的演講內容整理。

IoT的難題 -- 機遇與挑戰

IoT時代已來，這是大家都清楚的，里面有挑戰也有機遇。機遇是用戶對產品認知度越來越高，另外是產業、產品都要升級，包括互聯網思維引入，

怎么運營我的產品和我的客戶，怎么指導后續產品的發展方向和營銷方向等等。互聯網+的東風到了，但是我們面對這樣的東風，面對這樣一個完全未知的東西內心多少會有一些恐懼，恐懼在哪兒？就是里面充滿了很多挑戰。這些挑戰從傳統角度來講，第一它們的時間周期沒有那么長，因為現在正是一個最追求速度的時代，你的產品迭代速度跟不上，可能市場上就沒有先機，而且這是快速變革的時代，沒有辦法。第二是我們的廠商缺少互聯網開發的相關團隊，對架構這一塊理解可能沒有那么多有經驗，理解上沒有那么深。另外，設備智能化了之后干什么？從用戶角度來講給他提供了更豐富的體驗，其次更多的是對廠商而言的，通過設備跟用戶有了更多關聯。這種關聯除了是直接用戶行為數據能夠獲取到，設備本身的運行情況也能拿到，根據這些數據怎么運營、怎么發揮更多的價值，這是后續智能硬件要有長遠發展必須考慮的問題，這是對于廠商的挑戰。

對于一個創業團隊來講也有挑戰。創業團隊有互聯網思維和產品迭代的常規的方法論，開發團隊可能也有，但是對整個硬件的供應鏈以及傳統這一塊可能也不是很了解，所以就需要一種結合，這種結合就是硬件團隊發揮自己的專長，能夠選一個更加合適自己的云平臺或者有一個理想的云端的總體架構，這樣可以避免走一些彎路。互聯網發展到現在，你會看到無論是淘寶還是其他BAT公司都會一步一步迭代下來，曾經走過的彎路基本上是雷同或者類似的。我們物聯網時代是不是也重蹈那樣的覆轍呢？是不是一定按部就班的把他們走過的坑再走一遍呢？這個答案大家是心知肚明的。

AWS的IoT基礎架構

正式開始之前，我們先看一下AWS的IoT的基礎架構，中間的黃色框是IoT的基礎服務，最外面的是設備上提供的SDK，然后幫助這個設備去聯網。最右側那邊可以是外部的應用，也可以是APP的應用，其次是有自定義的服務。中間看起來就是一個設備的安全的認證和設備鏈接的管理，提供一個通路、一個鏈接，幫助你把設備進行鏈接，其他沒有了，這是對IoT的基本構想。

七牛架構師實踐日

IoT的技術挑戰

根據從我們的客戶或者合作伙伴那邊進行一年多的探索，包括我們自己對整個行業的認識，認為IoT里面的技術挑戰其實不僅僅只是一個鏈接的問題，鏈接只是其中一小塊，這里面安全問題是大家最關注的。如果你現在不關注，有一天你必然會關注，所以我覺得不如提前關注。怎么防止設備被偽造，怎么防止設備被別人竊取了之后，被我沒有授權的人控制，怎么防止這些設備不會發起一個對云端的沖擊導致設備無法運轉，這是系統必須考慮的問題，不只是做一個設備認證就可以了，而是貫穿到整個技術體系中。設備的長鏈接管理要考慮這個設備是不是做認證，是不是合法可信的設備進入到服務中來，還要考慮用戶對設備有沒有控制權限，用戶數據、用戶密碼和賬號體系是不是完善的，這些是貫穿在整個體系中的。比如說賬號體系、OTA怎么做管理，包括綁定關系，什么人具有什么角色、什么權限都需要嚴格的定義清楚。還有一部分是數據怎么做存儲，IoT的數據跟互聯網完全不一樣，待會兒我們會展開來講。

除了標準化、通用化的東西之外，我們還要提供一個完全不一樣的產品，它的核心不是在賬號體系是怎樣的，不是在于綁定關系是怎樣的，而在于它提供的內容，也就是非標準化的部分怎么體現，智能硬件云端智慧的地方在哪里，這是我們所有做產品的應該更深入思考的問題。關于APP賬號和推送等，比如說我去淘寶、騰訊肯定不是因為賬號有什么區別，而是看內容和自定義有什么區別。我們真正去運維、管理這些自定義組建服務的時候涉及到專業的問題，這些服務怎么架構和設計，每個模塊直接的邊界應該怎么劃分，它們之間的關聯關系應該管理。如果物聯網發展成互聯網那么大規模的時候運營怎么做，互聯網里面較大的問題就是運營、版本依賴，這里面有沒有什么思路可以幫助我們提前做一些規劃，讓大家遇到這些問題的時候可以借鑒這些先進技術解決這些問題，至少提供一些思考和幫助。

最后一部分就是數據的分析。我們看一個完整的架構，基本上是這樣的，最底下是IaaS層，上面是PaaS層，比如說賬號等這些東西都不需要做過多的產品上的深入的研究，更多的還是在SaaS這一層，怎么開發、怎么快速迭代產品，迭代云端的智能的邏輯部分。除此之外就是最上層，上層這一部分就是我的接入層，包括兩部分，設備的接入和APP的接入，還有外部的控制臺等。其次，考慮到未來互聯網的架構肯定是云之間是互通的，我們要構造的是開放的。基于Google為對云的設想，認為所有設備都是為人服務，它不是一個設備，而是一個服務。基于這種設想，首先云是開放的，我的設備才是開放的。現在我們做很多硬件，比如京東、國美、蘇寧都做這樣的事情，我的渠道需要跟他的云對接，否則他們可能不允許在他們渠道鋪貨。

做一個簡單的總結，架構分層主要是這樣。首先是訪問的接入層，這部分要考慮設備的安全性認證，第二部分設備接入要考慮負載性，考慮服務負載是怎樣的，延時怎樣、吞吐怎樣，第三方面是流式處理。設備就是兩個通道，控制流講究的是實時、雙向，數據流主要是流式的，一個是對資源消耗比較大，另外是對延時要求并沒有那么強，可能要求100毫秒以內給我應答，但是用戶沒有要求那么強，1、2秒延時還是可以接受的。

除了云端還有一個是APP的，就是通用服務層，幫助賬號綁定和消息推送等等的管理。其次是真正核心的部分，就是整個云端的架構核心的部分，云端的邏輯、云端的智能怎么開發、怎么運行、怎么運維。

主要問題應對

接下來我會更細致的針對剛才提到的那些挑戰和問題做一些總結，每個問題再稍微的展開一下，提一些我們常用的方法，大家可以去借鑒和參考。

1.多重安全保證

安全方面的保證，我的設備接入云端，云端要驗證設備，首先設備也要驗證云端，因為DNS劫持不是沒有發生過，如果被劫持了，你的內容會流到別人的設備上。基于這一塊的想法就是做RSA非對稱加密。數據加密也有很多種，因為網絡也不是可靠的，我們需要做一些認證。網絡不可靠包含幾個層次，一個是網絡可能被別人攻擊，別人的請求可能發過來，雖然不知道我的協議，但是數據可能會發過來，所以我們各個層次要做防攻擊的準備，校驗我們的數據是不是合法的。還有一個是設備的綁定，比如說最簡單的方式，用戶知道一個ID就可以做綁定，這種方式肯定是不安全的。比如說我隨便把你的設備ID變一下，所以就要考慮綁定碼的機制。一個是設備上，被云端激活之后，云端給他一得動態的綁定碼，APP綁定的時候通過局域網做通信拿到綁定碼，如果這個人沒有對設備完全控制拿不到這個綁定碼，這個綁定是時效的。還有給設備辦法一個P碼，你要知道這個設備跟P碼是怎樣的一一對應管理，防止被誤綁。一般設備不是某一個人的，而是家庭里所有成員能共享的，所以必須要有分享機制，分享的時候綁定碼要有時效的考慮。

認證訪問請求方面，首先是認證所有訪問請求，在訪問層確保所有用戶都是可信的，要驗證用戶是不是有訪問控制權限。其次要保證這些數據，這些數據包括賬號，賬號和密碼不能被泄露，如果是明文存儲的，一個是損失了用戶其他的系統安全性，另外是偽造成這個用戶對你所有的設備進行影響。

2.分布式長連接管理

長連接管理方面，這個話題不是所有智能硬件都需要的一個問題，只有這個設備需要被反向控制的時候才需要長連接的管理，如果沒有用戶控制或者沒有動態的控制的過程可能不需要，只需要這個設備能夠聯網，在需要上傳數據的時候跟云端建立連接不需要長連擊，大部分情況下，無論是智能家居還是其他都需要長連接管理。目前互聯網情況下你的設備IP不固定，因為有多層路由，還經過防火墻，所以一種方法是通過設備跟云端維護長連接，既可以做數據的上傳，也可以從云端找到這個設備，給這個設備下發一些控制。這里面要考慮的問題是可擴展性，當我有十萬臺的時候可能隨便寫一個程序，長連接維護不是那么困難的事情。但是我是常年維護，很多設備不是使用一年、兩年就壞掉了，所以我要考慮長遠發展，可能百萬、千萬級的設備都是可能的，所以較早寫這個協議的時候一定要考慮擴展。現在的通用擴展有兩種，水平擴展和垂直擴展。水平擴展是購買更多的機器來承載更多的負載，通過負載均衡的方式保證這個系統隨著設備規模增加不用改任何程序，設備不用做任何升級。還有一種方法是不斷的買更高性能的機器，這種是比較有短見的方式，而且是成本比較高昂的方式。互聯網都經過了這樣的發展路徑，較早是單機，過不了半年發現單機不行，然后做主備，然后主備不行做分布式，最后做一個最終的擴展性。

我們做可擴展性、分布性的目的還是更高的可用性。當規模和集群越變越大的時候，所有時效可能性就越變越大，當集群里面某一些臺設備發生故障的時候不能影響用戶或者降低對用戶的影響，所以要考慮怎么做時效的轉移，設備和云端怎么處理，這些都要考慮。

另外是防攻擊，在云端出現極端異常的時候怎么做降級，就是保證功能是基本正常的，保證用戶的體驗保證一部分的滿足，總比完全癱瘓好很多。其次是高效能，肯定要考慮節約成本，如果一臺機器只能承載十萬臺設備，我到一百萬、五百萬的時候，機器的成本也是非常高昂的，所以我們希望單機支撐百萬級的PC機，我們驗證過，我們做到兩百萬。講這個數字是說，大家構建云平臺的時候這也是可以作為一個基數。

3.設備TCP長連接管理

簡單講一下長連接怎么做負載均衡和時效轉移。首先，這是設備端，直接的做法是通過TCP連接，我們叫Gateway，就是一個網關，跟它進行長連接，防止設備異常斷電和云端斷電，所以要維護協調。怎么做擴展呢？就是通過一個Scheduler，相當于負載均衡的模塊，這也不是單點的，如果是單點系統性、可靠性也沒有那么高，所以這也是多點部署的，比如說我們通過DNS連接，通過它拿到一個真正的接入點，Gateway的連接信息，后面是在這上面做維護。Scheduler相當于Gateway的管理者，需要動態的拿到活著的位置。通過這樣的架構就保證設備不斷的增加模塊就可以了，讓設備通過負載均衡的方式按照連接數最小或者延時的分布去做負載均衡。這里面不展開了，里面有很多可以參考的東西。

4.云端存儲

接下來就是存儲的問題，大家知道一個應用里存儲是瓶頸，或者說遲早是瓶頸。所有的計算、帶寬都可以通過擴展方式解決，即不斷增加服務器，但是存儲是一個單點，所有的產品都會落到存儲上。IoT和互聯網較大的區別在哪兒？互聯網是讀多寫少型，IoT則是反過來的，用戶看這個設備的數據沒有那么頻繁，或者用戶都不會看原始的數據，只需要看匯總的數據、云計算的結果，而不是原始的數據。用戶看到的數據量或者他看的頻率實際上沒有那么高，設備是7×24小時不間斷，而人總有4萬秒休息的時間，所以跟互聯網是完全不一樣的。這種情況下我們怎么選擇存儲？用傳統的那種引擎肯定是不合理的。這里推薦一種LevelDB的解決方案，它是基于IoT的模型做優化，是寫入密集型的存儲。較早提出這個模型解決的問題是什么呢？既然要解決寫入密集型的預算，對寫入的延時要求是非常低的，這樣單次的延時變小了，我的吞吐才能承載這么多設備同時并發的寫入，所以優化寫。傳統的磁盤對順序寫是友好的，對隨機寫是不友好的，一塊盤承載的每秒鐘的寫入量是160次，假設有一百萬設備，設備每一分鐘傳一次，你想象一下這個每秒種寫出來至少有上萬，接近兩萬。兩萬是什么概念？Twitter兩三年前較高峰也就是三四萬，所以這個很難想象。兩萬是一個什么概念？我們放在一天就是幾億的PV，在百度一天也就是幾億的PV。如果我們的設備量真正到達這樣的規模必須要考慮這樣的問題，而且我們有很多廠商經過半年的發展就已經遇到了這樣的問題，有很多數據存儲方面遇到很多問題。如果你是考慮做這樣一個產品，有數據存儲的需求，需要考慮這樣一個選型的問題。

繼續回到這個模型，所有的寫入都沒有隨機寫，都是順序寫，因為對順序寫是友好的。順序寫主要考慮吞吐的問題，沒有旋轉、延時這些問題，所以可以做一個合并，合并以后再順序寫到磁盤上。內存的數據首先凍結，這些數據順序寫到磁盤里，它是一個新的文件，不存在隨機寫入。底下做了很多分層來優化它的寫，如果不做分層，所有內存文件不斷的打開，相當于一個一個的模塊，每一次把內存里面相同行的寫入合并到一行，這樣就造成讀一個數據的時候需要回訪歷史上所有的塊才能找到真正的數據，所以要做優化，要把小塊的文件合并成大文件。本來需要讀五個文件，現在合并到一個文件里面，這樣只需要一次就可以了，所以性能也是足夠的。它的缺點是讀會慢一些，因為畢竟還是要寫到磁盤上，還是要犧牲一點讀的延時性，來保證它的寫入是高效的。

剛才講到的其實還是一個單機的問題，就是怎么提高單機的存儲，你做一個存儲引擎的選型來保證單機的寫入性能是較高的。但是我們發現單機肯定也是不夠長遠的，淘寶也好、百度也好都經過了這樣一個過程，所有的數據庫經過一段時間之后都得做分片，搞成一個分布式的寫入。而且這里面有很多的坑，基本上做一次數據的調整、做一次分片，整個研發部基本上半年甚至一年時間都沒有任何進展，因為這里面有數據的遷移和校驗等非常復雜的事情，看起來是簡單的架構調整就完成了，實際上工作非常多。我自己切身的體會，在百度我們做廣告庫的分片，做了至少半年。在阿里做分片的時候基本上做了一年多，因為阿里是純粹的業務型公司，對數據庫依賴非常高，業務邏輯非常復雜，所以做梳理是非常耗時間的，而且坦白講這個事情對公司是沒有任何價值的。所以，我覺得大家在第一次選型的時候就應該考慮這樣一種架構，我們對數據自動做分片。分片解決兩個問題，一個是讀可以做擴展，一個是寫做擴展。所有的寫入都可以在每一個分片上做，這樣的話我的寫入吞吐可以成倍的增加，而且延時肯定比單機還要好。單機還有一個問題，很多數據庫都有一些限制的，比如說有的單秒存儲有限制，當超過兩三千萬的時候性能會出現急劇的下降。

另外，基本的模型是這樣的，首先最外層是查詢的接入層，所有的客戶端無論是通過SDK還是通過客戶端上自己做一些路由，然后到QueryRouter，這上面所有的分片都可以看到，這個就是做數據的路由，它的狀態可以任意擴展，只要客戶端能訪問到這個結點就可以了。還有一個是QueryRouter是所有請求都經過它，它可以做更多數據，這一層可以做更多緩存，比如說只服務一二三結點，這上面的緩存只有一二三的，如果做所有的，這上面的緩存會降低很多。NoSQL大概是三年前興起的，這種模型有好處，它的模型非常簡單，它是沒有任何模式的，不需要像數據庫那樣優先定義所有的字段和類型。另外是可擴展性強、性能高，它的性能高的原因是什么呢？它把本來服務器做的事情交給客戶端，比如說不做索引和預算，純粹提供就是單純的數據存儲，專注于存儲方面的東西，你需要在上層做更多的預算。當然這也是一個趨勢，因為也會發現我們的應用性降低了，因為這個很容易寫，很容易被大家利用起來，所以慢慢往這方面轉型，開始往上層做SQL這種類型。對于大部分業務型的數據，比如說賬號這些用SQL型的也夠了，就沒有必要用NoSQL，畢竟它是一個新的東西，而且有很多程度沒有那么高，尤其是出問題的時候很難把這個東西完全駕馭，所以要適當的做一些選型，根據不同業務的復雜度做一個選型。

5.微服務架構設計

數據存儲講完了，剩下的就是核心的關于智能硬件本身業務邏輯的部分應該怎么做架構。除了通用的服務，剩下的就是自定義的服務，這些服務也會越來越多，一個龐大的系統，一個智能硬件需要的后端是需要大量的非通用的服務做承載的。這些服務之間怎么去定義邊界，怎么去做服務的一些定義？這些是我們在做架構的時候必須考慮的，包括模塊之間的依賴關系是什么樣子的，當服務越來越多的時候怎么做運維，服務之間的依賴怎么梳理，我怎么判斷哪一個模塊出了問題或者結點在哪兒、怎么快速響應，這是越來越頭疼的問題。還有一個最頭疼的問題，我管的服務越來越多，每次要做服務器的更換或者服務器的遷移，每次還要重新做一些測試，因為用的機器可能完全不一樣，有沒有一種機制讓我測試一次，然后把它分發到任何一個結點上都可以和我期望的運作模式是一樣的，有沒有這樣的技術來幫助我們。

這里是我們提供的一個微服務和基于Docker容器化的方式解決剛才提到的幾個問題的。Docker本身是一個容器，它的好處是可以在機器上虛擬出一些，不論物理依賴的環境是什么樣的，我可以虛擬出一個一樣的環境，在這個基礎之上做操作版本，這樣可以把服務和環境打包，通過容器把這些服務一次性的加載起來，保證在任何一臺機器上所有的運行環境一致，這就解決了運維人員非常頭疼的問題。

其次微服務跟我們的架構沒有太大關系，之所以在這里講就是因為微服務在互聯網公司里面都是非常提倡的，但是“微服務”這個名詞互聯網架構里面不會提，因為大家都覺得這是理所應當的，沒有什么新鮮的事情。為什么這個名詞近兩年又火起來了呢？因為它要進入非互聯網公司企業，這種理念一定要給到大家。做編程的時候要知道模塊怎么劃分類，怎么去寫這個類的職責，包括基本的原則怎么在代碼里體現，這樣來保證我的服務是穩定的、可測試的、能夠容易可讀的，這樣的思想上升到另外一個層次就是服務，把所有模塊拆成服務，每一個服務都依賴于以前在編碼層次的經驗，來保證每一個服務是簡單的、功能獨立的，同時這個服務是任意升級的。我在做小的服務升級的時候以前可能需要做大量回歸驗證，可能不知道影響到底有哪些，做起來可能影響很大，但是通過這種微服務把所有服務做很好的拆分，每個服務交給不同的團隊，只需要這個團隊專注自己的業務，有一些相對的明確接口也可以綁定。

怎么做容器化的管理呢？從這幅圖來講，前面是集群化的管理，這里是最簡單的Docker的框架。首先它是基于Linux，在這上面用戶可以自己在上面做一些開發，把這一整套可以做一個運作。Docker可以提供一個統一的運行環境，還有一個好處是資源的地方率很高。在BAT里面最前端的承載大家的所有網頁瀏覽等常規操作的時候是第一層，這一層是無狀態的，所有的業務邏輯都需要路由到后面一層，所以前面的CPU利用率都不高，非常低。無論是騰訊還是阿里，都是靠容器化的方案。當然較早的時候Docker還沒有出來，都是各家公司做一些開發提供類似的方案。Docker現在已經開始被大家所接受了，而且從前年開始已經逐漸慢慢的成熟，有好多大的公司已經把這個技術引進來。

七牛架構師實踐日

Docker解決了單機的問題，但是我考慮到一個系統肯定是一個集群，這個集群怎么做管理，當機器掛掉之后怎么做管理，怎么把負載均衡和時效轉移到其他機器上，這就涉及到集群管理的問題。基本上就是這樣一個思路，首先有一個服務發現，這個agent是在一臺物理機上有一個容器，然后把這些容器統一匯集到Schedule這一層，然后重新分布到另外的ETCD模式，然后收到中控結點的命令，然后收到命令之后會重新加載agent。這里面有一個儲備的選取，保證Schedule這方面是高可靠的服務，因為任何一個點都可能down掉，所以需要有這樣一個機制。

最后，在服務管理、運營管理上還要考慮怎么做調度、怎么做擴容。當服務是無狀態的時候，可以通過Docker容器把服務加載起來做水平的擴展，應對更大的流量、更大的負載。其次，我的版本如何管理？是不是所有的工程師寫的程序都要自己去操作，SSH到一臺機器上做部署，寫那么多配置，其實我們完全可以有一個方案做可操作的界面，用戶直接上傳，由這個系統來選擇在哪臺機器上做部署、做監控，都由這個系統來做。

6.大數據分析

最后一部分是數據分析，由于時間關系不做太多展開。IOT的數據肯定是越來越大，因為它是機器產生的數據，不是人產生的數據。當然用戶的數據也有，所以這個分析模型比互聯網的模型還要復雜，不僅是用戶的數據，還有機器的數據。數據分析包含幾層，一個是怎么做數據的收集和采樣，另外一個是數據的存儲，這個存儲跟剛才講到的業務分布式存儲不太一樣，分布系統處理的數據規模比在線的應用多很多，所以在存儲選型上一般選擇列存，一般可以把數據做很好的壓縮，把相同列的數據存儲到一起。相同列的數據一般來講具有很好的特新，所以壓縮比非常高，占用的磁盤空間就小，當讀取數據的時候在磁盤上的空間也比較小。

大數據分析引擎架構有幾部分，首先是有一個可視化的api，然后還有一個分析模型，包括漏斗模型等等，在這個存儲之上還可以做一個緩存。存儲層寫入是比較密集的，列存寫入效率不是特別高，就通過做消息隊列的模型，這樣跟我們剛才講的模型一樣，可以把寫入效率提高。其次，可以把數據通過內部處理寫入到最終的列存里面。最終就產生了這樣一個可視化的效果，可以做地域分析、用戶行為分析，也可以做設備活動狀態的分析、故障率的分析，這樣來指導我的產品、指導我的硬件后面怎么做迭代層、怎么做升級，包括知道用戶喜歡用什么功能、用戶在什么時間段喜歡用這個功能，知道后面營銷策略針對哪些地域作為重點。