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