CTI論壇(ctiforum)11月6日消息（記者 李文杰):在由七牛云主辦的架構(gòu)師實踐日（深圳站）物聯(lián)網(wǎng)與智能硬件架構(gòu)技術(shù)沙龍上，來自AbleCloud的技術(shù)合伙人孫志東進行了題為《構(gòu)建高可用、可擴展的IoT云服務》的分享。以下是他的演講內(nèi)容整理。
IoT的難題 -- 機遇與挑戰(zhàn)
IoT時代已來，這是大家都清楚的，里面有挑戰(zhàn)也有機遇。機遇是用戶對產(chǎn)品認知度越來越高，另外是產(chǎn)業(yè)、產(chǎn)品都要升級，包括互聯(lián)網(wǎng)思維引入，
怎么運營我的產(chǎn)品和我的客戶，怎么指導后續(xù)產(chǎn)品的發(fā)展方向和營銷方向等等�；ヂ�(lián)網(wǎng)+的東風到了，但是我們面對這樣的東風，面對這樣一個完全未知的東西內(nèi)心多少會有一些恐懼，恐懼在哪兒？就是里面充滿了很多挑戰(zhàn)。這些挑戰(zhàn)從傳統(tǒng)角度來講，第一它們的時間周期沒有那么長，因為現(xiàn)在正是一個最追求速度的時代，你的產(chǎn)品迭代速度跟不上，可能市場上就沒有先機，而且這是快速變革的時代，沒有辦法。第二是我們的廠商缺少互聯(lián)網(wǎng)開發(fā)的相關(guān)團隊，對架構(gòu)這一塊理解可能沒有那么多有經(jīng)驗，理解上沒有那么深。另外，設(shè)備智能化了之后干什么？從用戶角度來講給他提供了更豐富的體驗，其次更多的是對廠商而言的，通過設(shè)備跟用戶有了更多關(guān)聯(lián)。這種關(guān)聯(lián)除了是直接用戶行為數(shù)據(jù)能夠獲取到，設(shè)備本身的運行情況也能拿到，根據(jù)這些數(shù)據(jù)怎么運營、怎么發(fā)揮更多的價值，這是后續(xù)智能硬件要有長遠發(fā)展必須考慮的問題，這是對于廠商的挑戰(zhàn)。
對于一個創(chuàng)業(yè)團隊來講也有挑戰(zhàn)。創(chuàng)業(yè)團隊有互聯(lián)網(wǎng)思維和產(chǎn)品迭代的常規(guī)的方法論，開發(fā)團隊可能也有，但是對整個硬件的供應鏈以及傳統(tǒng)這一塊可能也不是很了解，所以就需要一種結(jié)合，這種結(jié)合就是硬件團隊發(fā)揮自己的專長，能夠選一個更加合適自己的云平臺或者有一個理想的云端的總體架構(gòu)，這樣可以避免走一些彎路�；ヂ�(lián)網(wǎng)發(fā)展到現(xiàn)在，你會看到無論是淘寶還是其他BAT公司都會一步一步迭代下來，曾經(jīng)走過的彎路基本上是雷同或者類似的。我們物聯(lián)網(wǎng)時代是不是也重蹈那樣的覆轍呢？是不是一定按部就班的把他們走過的坑再走一遍呢？這個答案大家是心知肚明的。
AWS的IoT基礎(chǔ)架構(gòu)
正式開始之前，我們先看一下AWS的IoT的基礎(chǔ)架構(gòu)，中間的黃色框是IoT的基礎(chǔ)服務，最外面的是設(shè)備上提供的SDK，然后幫助這個設(shè)備去聯(lián)網(wǎng)。最右側(cè)那邊可以是外部的應用，也可以是APP的應用，其次是有自定義的服務。中間看起來就是一個設(shè)備的安全的認證和設(shè)備鏈接的管理，提供一個通路、一個鏈接，幫助你把設(shè)備進行鏈接，其他沒有了，這是對IoT的基本構(gòu)想。
七牛架構(gòu)師實踐日
IoT的技術(shù)挑戰(zhàn)
根據(jù)從我們的客戶或者合作伙伴那邊進行一年多的探索，包括我們自己對整個行業(yè)的認識，認為IoT里面的技術(shù)挑戰(zhàn)其實不僅僅只是一個鏈接的問題，鏈接只是其中一小塊，這里面安全問題是大家最關(guān)注的。如果你現(xiàn)在不關(guān)注，有一天你必然會關(guān)注，所以我覺得不如提前關(guān)注。怎么防止設(shè)備被偽造，怎么防止設(shè)備被別人竊取了之后，被我沒有授權(quán)的人控制，怎么防止這些設(shè)備不會發(fā)起一個對云端的沖擊導致設(shè)備無法運轉(zhuǎn)，這是系統(tǒng)必須考慮的問題，不只是做一個設(shè)備認證就可以了，而是貫穿到整個技術(shù)體系中。設(shè)備的長鏈接管理要考慮這個設(shè)備是不是做認證，是不是合法可信的設(shè)備進入到服務中來，還要考慮用戶對設(shè)備有沒有控制權(quán)限，用戶數(shù)據(jù)、用戶密碼和賬號體系是不是完善的，這些是貫穿在整個體系中的。比如說賬號體系、OTA怎么做管理，包括綁定關(guān)系，什么人具有什么角色、什么權(quán)限都需要嚴格的定義清楚。還有一部分是數(shù)據(jù)怎么做存儲，IoT的數(shù)據(jù)跟互聯(lián)網(wǎng)完全不一樣，待會兒我們會展開來講。
除了標準化、通用化的東西之外，我們還要提供一個完全不一樣的產(chǎn)品，它的核心不是在賬號體系是怎樣的，不是在于綁定關(guān)系是怎樣的，而在于它提供的內(nèi)容，也就是非標準化的部分怎么體現(xiàn)，智能硬件云端智慧的地方在哪里，這是我們所有做產(chǎn)品的應該更深入思考的問題。關(guān)于APP賬號和推送等，比如說我去淘寶、騰訊肯定不是因為賬號有什么區(qū)別，而是看內(nèi)容和自定義有什么區(qū)別。我們真正去運維、管理這些自定義組建服務的時候涉及到專業(yè)的問題，這些服務怎么架構(gòu)和設(shè)計，每個模塊直接的邊界應該怎么劃分，它們之間的關(guān)聯(lián)關(guān)系應該管理。如果物聯(lián)網(wǎng)發(fā)展成互聯(lián)網(wǎng)那么大規(guī)模的時候運營怎么做，互聯(lián)網(wǎng)里面最大的問題就是運營、版本依賴，這里面有沒有什么思路可以幫助我們提前做一些規(guī)劃，讓大家遇到這些問題的時候可以借鑒這些先進技術(shù)解決這些問題，至少提供一些思考和幫助。
最后一部分就是數(shù)據(jù)的分析。我們看一個完整的架構(gòu)，基本上是這樣的，最底下是IaaS層，上面是PaaS層，比如說賬號等這些東西都不需要做過多的產(chǎn)品上的深入的研究，更多的還是在SaaS這一層，怎么開發(fā)、怎么快速迭代產(chǎn)品，迭代云端的智能的邏輯部分。除此之外就是最上層，上層這一部分就是我的接入層，包括兩部分，設(shè)備的接入和APP的接入，還有外部的控制臺等。其次，考慮到未來互聯(lián)網(wǎng)的架構(gòu)肯定是云之間是互通的，我們要構(gòu)造的是開放的�；贕oogle為對云的設(shè)想，認為所有設(shè)備都是為人服務，它不是一個設(shè)備，而是一個服務�；谶@種設(shè)想，首先云是開放的，我的設(shè)備才是開放的�，F(xiàn)在我們做很多硬件，比如京東、國美、蘇寧都做這樣的事情，我的渠道需要跟他的云對接，否則他們可能不允許在他們渠道鋪貨。
做一個簡單的總結(jié)，架構(gòu)分層主要是這樣。首先是訪問的接入層，這部分要考慮設(shè)備的安全性認證，第二部分設(shè)備接入要考慮負載性，考慮服務負載是怎樣的，延時怎樣、吞吐怎樣，第三方面是流式處理。設(shè)備就是兩個通道，控制流講究的是實時、雙向，數(shù)據(jù)流主要是流式的，一個是對資源消耗比較大，另外是對延時要求并沒有那么強，可能要求100毫秒以內(nèi)給我應答，但是用戶沒有要求那么強，1、2秒延時還是可以接受的。
除了云端還有一個是APP的，就是通用服務層，幫助賬號綁定和消息推送等等的管理。其次是真正核心的部分，就是整個云端的架構(gòu)最核心的部分，云端的邏輯、云端的智能怎么開發(fā)、怎么運行、怎么運維。
主要問題應對
接下來我會更細致的針對剛才提到的那些挑戰(zhàn)和問題做一些總結(jié)，每個問題再稍微的展開一下，提一些我們常用的方法，大家可以去借鑒和參考。
1.多重安全保證
安全方面的保證，我的設(shè)備接入云端，云端要驗證設(shè)備，首先設(shè)備也要驗證云端，因為DNS劫持不是沒有發(fā)生過，如果被劫持了，你的內(nèi)容會流到別人的設(shè)備上。基于這一塊的想法就是做RSA非對稱加密。數(shù)據(jù)加密也有很多種，因為網(wǎng)絡(luò)也不是可靠的，我們需要做一些認證。網(wǎng)絡(luò)不可靠包含幾個層次，一個是網(wǎng)絡(luò)可能被別人攻擊，別人的請求可能發(fā)過來，雖然不知道我的協(xié)議，但是數(shù)據(jù)可能會發(fā)過來，所以我們各個層次要做防攻擊的準備，校驗我們的數(shù)據(jù)是不是合法的。還有一個是設(shè)備的綁定，比如說最簡單的方式，用戶知道一個ID就可以做綁定，這種方式肯定是不安全的。比如說我隨便把你的設(shè)備ID變一下，所以就要考慮綁定碼的機制。一個是設(shè)備上，被云端激活之后，云端給他一得動態(tài)的綁定碼，APP綁定的時候通過局域網(wǎng)做通信拿到綁定碼，如果這個人沒有對設(shè)備完全控制拿不到這個綁定碼，這個綁定是時效的。還有給設(shè)備辦法一個P碼，你要知道這個設(shè)備跟P碼是怎樣的一一對應管理，防止被誤綁。一般設(shè)備不是某一個人的，而是家庭里所有成員能共享的，所以必須要有分享機制，分享的時候綁定碼要有時效的考慮。
認證訪問請求方面，首先是認證所有訪問請求，在訪問層確保所有用戶都是可信的，要驗證用戶是不是有訪問控制權(quán)限。其次要保證這些數(shù)據(jù)，這些數(shù)據(jù)包括賬號，賬號和密碼不能被泄露，如果是明文存儲的，一個是損失了用戶其他的系統(tǒng)安全性，另外是偽造成這個用戶對你所有的設(shè)備進行影響。
2.分布式長連接管理
長連接管理方面，這個話題不是所有智能硬件都需要的一個問題，只有這個設(shè)備需要被反向控制的時候才需要長連接的管理，如果沒有用戶控制或者沒有動態(tài)的控制的過程可能不需要，只需要這個設(shè)備能夠聯(lián)網(wǎng)，在需要上傳數(shù)據(jù)的時候跟云端建立連接不需要長連擊，大部分情況下，無論是智能家居還是其他都需要長連接管理。目前互聯(lián)網(wǎng)情況下你的設(shè)備IP不固定，因為有多層路由，還經(jīng)過防火墻，所以一種方法是通過設(shè)備跟云端維護長連接，既可以做數(shù)據(jù)的上傳，也可以從云端找到這個設(shè)備，給這個設(shè)備下發(fā)一些控制。這里面要考慮的問題是可擴展性，當我有十萬臺的時候可能隨便寫一個程序，長連接維護不是那么困難的事情。但是我是常年維護，很多設(shè)備不是使用一年、兩年就壞掉了，所以我要考慮長遠發(fā)展，可能百萬、千萬級的設(shè)備都是可能的，所以最早寫這個協(xié)議的時候一定要考慮擴展�，F(xiàn)在的通用擴展有兩種，水平擴展和垂直擴展。水平擴展是購買更多的機器來承載更多的負載，通過負載均衡的方式保證這個系統(tǒng)隨著設(shè)備規(guī)模增加不用改任何程序，設(shè)備不用做任何升級。還有一種方法是不斷的買更高性能的機器，這種是比較有短見的方式，而且是成本比較高昂的方式�；ヂ�(lián)網(wǎng)都經(jīng)過了這樣的發(fā)展路徑，最早是單機，過不了半年發(fā)現(xiàn)單機不行，然后做主備，然后主備不行做分布式，最后做一個最終的擴展性。
我們做可擴展性、分布性的目的還是更高的可用性。當規(guī)模和集群越變越大的時候，所有時效可能性就越變越大，當集群里面某一些臺設(shè)備發(fā)生故障的時候不能影響用戶或者降低對用戶的影響，所以要考慮怎么做時效的轉(zhuǎn)移，設(shè)備和云端怎么處理，這些都要考慮。
另外是防攻擊，在云端出現(xiàn)極端異常的時候怎么做降級，就是保證功能是基本正常的，保證用戶的體驗保證一部分的滿足，總比完全癱瘓好很多。其次是高效能，肯定要考慮節(jié)約成本，如果一臺機器只能承載十萬臺設(shè)備，我到一百萬、五百萬的時候，機器的成本也是非常高昂的，所以我們希望單機支撐百萬級的PC機，我們驗證過，我們做到兩百萬。講這個數(shù)字是說，大家構(gòu)建云平臺的時候這也是可以作為一個基數(shù)。
3.設(shè)備TCP長連接管理
簡單講一下長連接怎么做負載均衡和時效轉(zhuǎn)移。首先，這是設(shè)備端，直接的做法是通過TCP連接，我們叫Gateway，就是一個網(wǎng)關(guān)，跟它進行長連接，防止設(shè)備異常斷電和云端斷電，所以要維護協(xié)調(diào)。怎么做擴展呢？就是通過一個Scheduler，相當于負載均衡的模塊，這也不是單點的，如果是單點系統(tǒng)性、可靠性也沒有那么高，所以這也是多點部署的，比如說我們通過DNS連接，通過它拿到一個真正的接入點，Gateway的連接信息，后面是在這上面做維護。Scheduler相當于Gateway的管理者，需要動態(tài)的拿到活著的位置。通過這樣的架構(gòu)就保證設(shè)備不斷的增加模塊就可以了，讓設(shè)備通過負載均衡的方式按照連接數(shù)最小或者延時的分布去做負載均衡。這里面不展開了，里面有很多可以參考的東西。
4.云端存儲
接下來就是存儲的問題，大家知道一個應用里存儲是瓶頸，或者說遲早是瓶頸。所有的計算、帶寬都可以通過擴展方式解決，即不斷增加服務器，但是存儲是一個單點，所有的產(chǎn)品都會落到存儲上。IoT和互聯(lián)網(wǎng)最大的區(qū)別在哪兒？互聯(lián)網(wǎng)是讀多寫少型，IoT則是反過來的，用戶看這個設(shè)備的數(shù)據(jù)沒有那么頻繁，或者用戶都不會看原始的數(shù)據(jù)，只需要看匯總的數(shù)據(jù)、云計算的結(jié)果，而不是原始的數(shù)據(jù)。用戶看到的數(shù)據(jù)量或者他看的頻率實際上沒有那么高，設(shè)備是7×24小時不間斷，而人總有4萬秒休息的時間，所以跟互聯(lián)網(wǎng)是完全不一樣的。這種情況下我們怎么選擇存儲？用傳統(tǒng)的那種引擎肯定是不合理的。這里推薦一種LevelDB的解決方案，它是基于IoT的模型做優(yōu)化，是寫入密集型的存儲。最早提出這個模型解決的問題是什么呢？既然要解決寫入密集型的預算，對寫入的延時要求是非常低的，這樣單次的延時變小了，我的吞吐才能承載這么多設(shè)備同時并發(fā)的寫入，所以優(yōu)化寫。傳統(tǒng)的磁盤對順序?qū)懯怯押玫模瑢﹄S機寫是不友好的，一塊盤承載的每秒鐘的寫入量是160次，假設(shè)有一百萬設(shè)備，設(shè)備每一分鐘傳一次，你想象一下這個每秒種寫出來至少有上萬，接近兩萬。兩萬是什么概念？Twitter兩三年前最高峰也就是三四萬，所以這個很難想象。兩萬是一個什么概念？我們放在一天就是幾億的PV，在百度一天也就是幾億的PV。如果我們的設(shè)備量真正到達這樣的規(guī)模必須要考慮這樣的問題，而且我們有很多廠商經(jīng)過半年的發(fā)展就已經(jīng)遇到了這樣的問題，有很多數(shù)據(jù)存儲方面遇到很多問題。如果你是考慮做這樣一個產(chǎn)品，有數(shù)據(jù)存儲的需求，需要考慮這樣一個選型的問題。
繼續(xù)回到這個模型，所有的寫入都沒有隨機寫，都是順序?qū)�，因為對順序�(qū)懯怯押玫摹ｍ樞驅(qū)懼饕紤]吞吐的問題，沒有旋轉(zhuǎn)、延時這些問題，所以可以做一個合并，合并以后再順序?qū)懙酱疟P上。內(nèi)存的數(shù)據(jù)首先凍結(jié)，這些數(shù)據(jù)順序?qū)懙酱疟P里，它是一個新的文件，不存在隨機寫入。底下做了很多分層來優(yōu)化它的寫，如果不做分層，所有內(nèi)存文件不斷的打開，相當于一個一個的模塊，每一次把內(nèi)存里面相同行的寫入合并到一行，這樣就造成讀一個數(shù)據(jù)的時候需要回訪歷史上所有的塊才能找到真正的數(shù)據(jù)，所以要做優(yōu)化，要把小塊的文件合并成大文件。本來需要讀五個文件，現(xiàn)在合并到一個文件里面，這樣只需要一次就可以了，所以性能也是足夠的。它的缺點是讀會慢一些，因為畢竟還是要寫到磁盤上，還是要犧牲一點讀的延時性，來保證它的寫入是高效的。
剛才講到的其實還是一個單機的問題，就是怎么提高單機的存儲，你做一個存儲引擎的選型來保證單機的寫入性能是最高的。但是我們發(fā)現(xiàn)單機肯定也是不夠長遠的，淘寶也好、百度也好都經(jīng)過了這樣一個過程，所有的數(shù)據(jù)庫經(jīng)過一段時間之后都得做分片，搞成一個分布式的寫入。而且這里面有很多的坑，基本上做一次數(shù)據(jù)的調(diào)整、做一次分片，整個研發(fā)部基本上半年甚至一年時間都沒有任何進展，因為這里面有數(shù)據(jù)的遷移和校驗等非常復雜的事情，看起來是簡單的架構(gòu)調(diào)整就完成了，實際上工作非常多。我自己切身的體會，在百度我們做廣告庫的分片，做了至少半年。在阿里做分片的時候基本上做了一年多，因為阿里是純粹的業(yè)務型公司，對數(shù)據(jù)庫依賴非常高，業(yè)務邏輯非常復雜，所以做梳理是非常耗時間的，而且坦白講這個事情對公司是沒有任何價值的。所以，我覺得大家在第一次選型的時候就應該考慮這樣一種架構(gòu)，我們對數(shù)據(jù)自動做分片。分片解決兩個問題，一個是讀可以做擴展，一個是寫做擴展。所有的寫入都可以在每一個分片上做，這樣的話我的寫入吞吐可以成倍的增加，而且延時肯定比單機還要好。單機還有一個問題，很多數(shù)據(jù)庫都有一些限制的，比如說有的單秒存儲有限制，當超過兩三千萬的時候性能會出現(xiàn)急劇的下降。
另外，基本的模型是這樣的，首先最外層是查詢的接入層，所有的客戶端無論是通過SDK還是通過客戶端上自己做一些路由，然后到QueryRouter，這上面所有的分片都可以看到，這個就是做數(shù)據(jù)的路由，它的狀態(tài)可以任意擴展，只要客戶端能訪問到這個結(jié)點就可以了。還有一個是QueryRouter是所有請求都經(jīng)過它，它可以做更多數(shù)據(jù)，這一層可以做更多緩存，比如說只服務一二三結(jié)點，這上面的緩存只有一二三的，如果做所有的，這上面的緩存會降低很多。NoSQL大概是三年前興起的，這種模型有好處，它的模型非常簡單，它是沒有任何模式的，不需要像數(shù)據(jù)庫那樣優(yōu)先定義所有的字段和類型。另外是可擴展性強、性能高，它的性能高的原因是什么呢？它把本來服務器做的事情交給客戶端，比如說不做索引和預算，純粹提供就是單純的數(shù)據(jù)存儲，專注于存儲方面的東西，你需要在上層做更多的預算。當然這也是一個趨勢，因為也會發(fā)現(xiàn)我們的應用性降低了，因為這個很容易寫，很容易被大家利用起來，所以慢慢往這方面轉(zhuǎn)型，開始往上層做SQL這種類型。對于大部分業(yè)務型的數(shù)據(jù)，比如說賬號這些用SQL型的也夠了，就沒有必要用NoSQL，畢竟它是一個新的東西，而且有很多程度沒有那么高，尤其是出問題的時候很難把這個東西完全駕馭，所以要適當?shù)淖鲆恍┻x型，根據(jù)不同業(yè)務的復雜度做一個選型。
5.微服務架構(gòu)設(shè)計
數(shù)據(jù)存儲講完了，剩下的就是核心的關(guān)于智能硬件本身業(yè)務邏輯的部分應該怎么做架構(gòu)。除了通用的服務，剩下的就是自定義的服務，這些服務也會越來越多，一個龐大的系統(tǒng)，一個智能硬件需要的后端是需要大量的非通用的服務做承載的。這些服務之間怎么去定義邊界，怎么去做服務的一些定義？這些是我們在做架構(gòu)的時候必須考慮的，包括模塊之間的依賴關(guān)系是什么樣子的，當服務越來越多的時候怎么做運維，服務之間的依賴怎么梳理，我怎么判斷哪一個模塊出了問題或者結(jié)點在哪兒、怎么快速響應，這是越來越頭疼的問題。還有一個最頭疼的問題，我管的服務越來越多，每次要做服務器的更換或者服務器的遷移，每次還要重新做一些測試，因為用的機器可能完全不一樣，有沒有一種機制讓我測試一次，然后把它分發(fā)到任何一個結(jié)點上都可以和我期望的運作模式是一樣的，有沒有這樣的技術(shù)來幫助我們。
這里是我們提供的一個微服務和基于Docker容器化的方式解決剛才提到的幾個問題的。Docker本身是一個容器，它的好處是可以在機器上虛擬出一些，不論物理依賴的環(huán)境是什么樣的，我可以虛擬出一個一樣的環(huán)境，在這個基礎(chǔ)之上做操作版本，這樣可以把服務和環(huán)境打包，通過容器把這些服務一次性的加載起來，保證在任何一臺機器上所有的運行環(huán)境一致，這就解決了運維人員非常頭疼的問題。
其次微服務跟我們的架構(gòu)沒有太大關(guān)系，之所以在這里講就是因為微服務在互聯(lián)網(wǎng)公司里面都是非常提倡的，但是“微服務”這個名詞互聯(lián)網(wǎng)架構(gòu)里面不會提，因為大家都覺得這是理所應當?shù)�，沒有什么新鮮的事情。為什么這個名詞近兩年又火起來了呢？因為它要進入非互聯(lián)網(wǎng)公司企業(yè)，這種理念一定要給到大家。做編程的時候要知道模塊怎么劃分類，怎么去寫這個類的職責，包括基本的原則怎么在代碼里體現(xiàn)，這樣來保證我的服務是穩(wěn)定的、可測試的、能夠容易可讀的，這樣的思想上升到另外一個層次就是服務，把所有模塊拆成服務，每一個服務都依賴于以前在編碼層次的經(jīng)驗，來保證每一個服務是簡單的、功能獨立的，同時這個服務是任意升級的。我在做小的服務升級的時候以前可能需要做大量回歸驗證，可能不知道影響到底有哪些，做起來可能影響很大，但是通過這種微服務把所有服務做很好的拆分，每個服務交給不同的團隊，只需要這個團隊專注自己的業(yè)務，有一些相對的明確接口也可以綁定。
怎么做容器化的管理呢？從這幅圖來講，前面是集群化的管理，這里是最簡單的Docker的框架。首先它是基于Linux，在這上面用戶可以自己在上面做一些開發(fā)，把這一整套可以做一個運作。Docker可以提供一個統(tǒng)一的運行環(huán)境，還有一個好處是資源的地方率很高。在BAT里面最前端的承載大家的所有網(wǎng)頁瀏覽等常規(guī)操作的時候是第一層，這一層是無狀態(tài)的，所有的業(yè)務邏輯都需要路由到后面一層，所以前面的CPU利用率都不高，非常低。無論是騰訊還是阿里，都是靠容器化的方案。當然最早的時候Docker還沒有出來，都是各家公司做一些開發(fā)提供類似的方案。Docker現(xiàn)在已經(jīng)開始被大家所接受了，而且從前年開始已經(jīng)逐漸慢慢的成熟，有好多大的公司已經(jīng)把這個技術(shù)引進來。
七牛架構(gòu)師實踐日Docker解決了單機的問題，但是我考慮到一個系統(tǒng)肯定是一個集群，這個集群怎么做管理，當機器掛掉之后怎么做管理，怎么把負載均衡和時效轉(zhuǎn)移到其他機器上，這就涉及到集群管理的問題�；旧暇褪沁@樣一個思路，首先有一個服務發(fā)現(xiàn)，這個agent是在一臺物理機上有一個容器，然后把這些容器統(tǒng)一匯集到Schedule這一層，然后重新分布到另外的ETCD模式，然后收到中控結(jié)點的命令，然后收到命令之后會重新加載agent。這里面有一個儲備的選取，保證Schedule這方面是高可靠的服務，因為任何一個點都可能down掉，所以需要有這樣一個機制。
最后，在服務管理、運營管理上還要考慮怎么做調(diào)度、怎么做擴容。當服務是無狀態(tài)的時候，可以通過Docker容器把服務加載起來做水平的擴展，應對更大的流量、更大的負載。其次，我的版本如何管理？是不是所有的工程師寫的程序都要自己去操作，SSH到一臺機器上做部署，寫那么多配置，其實我們完全可以有一個方案做可操作的界面，用戶直接上傳，由這個系統(tǒng)來選擇在哪臺機器上做部署、做監(jiān)控，都由這個系統(tǒng)來做。
6.大數(shù)據(jù)分析
最后一部分是數(shù)據(jù)分析，由于時間關(guān)系不做太多展開。IOT的數(shù)據(jù)肯定是越來越大，因為它是機器產(chǎn)生的數(shù)據(jù)，不是人產(chǎn)生的數(shù)據(jù)。當然用戶的數(shù)據(jù)也有，所以這個分析模型比互聯(lián)網(wǎng)的模型還要復雜，不僅是用戶的數(shù)據(jù)，還有機器的數(shù)據(jù)。數(shù)據(jù)分析包含幾層，一個是怎么做數(shù)據(jù)的收集和采樣，另外一個是數(shù)據(jù)的存儲，這個存儲跟剛才講到的業(yè)務分布式存儲不太一樣，分布系統(tǒng)處理的數(shù)據(jù)規(guī)模比在線的應用多很多，所以在存儲選型上一般選擇列存，一般可以把數(shù)據(jù)做很好的壓縮，把相同列的數(shù)據(jù)存儲到一起。相同列的數(shù)據(jù)一般來講具有很好的特新，所以壓縮比非常高，占用的磁盤空間就小，當讀取數(shù)據(jù)的時候在磁盤上的空間也比較小。
大數(shù)據(jù)分析引擎架構(gòu)有幾部分，首先是有一個可視化的api，然后還有一個分析模型，包括漏斗模型等等，在這個存儲之上還可以做一個緩存。存儲層寫入是比較密集的，列存寫入效率不是特別高，就通過做消息隊列的模型，這樣跟我們剛才講的模型一樣，可以把寫入效率提高。其次，可以把數(shù)據(jù)通過內(nèi)部處理寫入到最終的列存里面。最終就產(chǎn)生了這樣一個可視化的效果，可以做地域分析、用戶行為分析，也可以做設(shè)備活動狀態(tài)的分析、故障率的分析，這樣來指導我的產(chǎn)品、指導我的硬件后面怎么做迭代層、怎么做升級，包括知道用戶喜歡用什么功能、用戶在什么時間段喜歡用這個功能，知道后面營銷策略針對哪些地域作為重點。
七牛架構(gòu)師實踐日謝謝大家！
