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