隨著社會數字化進程不斷的提升，數字技術正在以新方式、新理念、新形態逐漸融入我們的經濟、文化、生產生活等各個領域乃至全過程。而在這背后涌現出的是海量數據以及海量設備高并發等問題，這也使業務系統面臨前所未有的巨大的挑戰。目前OneNET城市物聯網平臺(tai)面對大連接的(de)應用(yong)場景，經受住了(le)海(hai)量數據和高并發的(de)挑戰。那么，如(ru)此高的(de)性能(neng)挑戰，平臺(tai)是如(ru)何進行應對的(de)?
高并發框架
高(gao)并(bing)發(fa)(fa)(fa)是一(yi)(yi)(yi)種在(zai)(zai)“同一(yi)(yi)(yi)時間(jian)點(dian)(dian)或極短時間(jian)內出現(xian)大量(liang)的(de)(de)操作請求”的(de)(de)場(chang)(chang)景(jing)。而傳統的(de)(de)網(wang)絡通信(xin)模(mo)型，在(zai)(zai)面對海(hai)量(liang)數據高(gao)并(bing)發(fa)(fa)(fa)場(chang)(chang)景(jing)，已(yi)經顯得力不從心;一(yi)(yi)(yi)款優(you)秀的(de)(de)高(gao)并(bing)發(fa)(fa)(fa)框架(jia)是現(xian)階段網(wang)絡通信(xin)必不可少(shao)的(de)(de)一(yi)(yi)(yi)環，如：Grizzly、Netty，Mina。平臺在(zai)(zai)面對海(hai)量(liang)設備(bei)接入場(chang)(chang)景(jing)，選擇了Netty成為整個接入能(neng)力的(de)(de)核心框架(jia)。其(qi)單(dan)節點(dian)(dian)百萬(wan)級接入，集群千萬(wan)級的(de)(de)海(hai)量(liang)接入能(neng)力成為了當前(qian)平臺在(zai)(zai)高(gao)并(bing)發(fa)(fa)(fa)場(chang)(chang)景(jing)下的(de)(de)解(jie)決方案(an)。
Netty是什么?
是一個異步事件(jian)驅(qu)動的(de)Java開(kai)源網(wang)絡應用程序(xu)框架，用于快速開(kai)發可維護(hu)的(de)高性能協議(yi)服務(wu)器(qi)和客(ke)戶端。
為什么要選用Netty?
相較(jiao)于傳統(tong)的(de)IO模型(xing)(xing)，Netty的(de)IO線(xian)(xian)程NioEventLoop 聚合了多路復(fu)用器Selector，可以(yi)同時并(bing)發處(chu)理(li)(li)(li)成千上萬個客戶端連接，在線(xian)(xian)程從客戶端讀(du)寫(xie)數(shu)據(ju)(ju)閑暇(xia)時，線(xian)(xian)程可以(yi)進行其他(ta)任(ren)務，而(er)無需等(deng)待讀(du)寫(xie)數(shu)據(ju)(ju)。在線(xian)(xian)程模型(xing)(xing)上，Netty的(de)線(xian)(xian)程模型(xing)(xing)也叫Reactor模型(xing)(xing)，核心是基于事(shi)件(jian)驅(qu)動(dong)的(de)方(fang)式來處(chu)理(li)(li)(li)事(shi)件(jian);其分布式的(de)異步架(jia)構，使得事(shi)件(jian)處(chu)理(li)(li)(li)器之間高度解耦，可以(yi)方(fang)便(bian)擴展事(shi)件(jian)處(chu)理(li)(li)(li)邏輯;同時通過隊列暫存事(shi)件(jian)，線(xian)(xian)程消費事(shi)件(jian)，能方(fang)便(bian)并(bing)行異步處(chu)理(li)(li)(li)事(shi)件(jian)。
Netty的優勢是什么?
Netty適用于各種傳輸(shu)類型(xing)(xing)的(de)統一(yi)API阻塞和非阻塞Socket;基于靈(ling)活且可擴(kuo)展的(de)事件模型(xing)(xing)，可以(yi)(yi)清(qing)晰地讓開發者專注(zhu)于業務而(er)無(wu)需關(guan)注(zhu)底(di)層(ceng)架(jia)構，提升了開發效率;具備高度可定制的(de)線(xian)程模型(xing)(xing)-單線(xian)程，一(yi)個或(huo)多個線(xian)程池;真正的(de)無(wu)連接(jie)數據報套接(jie)字的(de)支持。Zero-Copy技術(shu)使得Netty有更低的(de)資源消耗，以(yi)(yi)及不(bu)必要的(de)內(nei)存(cun)拷貝。
微服務架構
“一根筷子易(yi)折斷(duan)，一把(ba)筷子難(nan)折斷(duan)”。對于(yu)平臺也是一樣(yang)，巨大(da)的(de)單體(ti)式服(fu)務(wu)(wu)總(zong)會(hui)到達一個性能(neng)(neng)瓶頸。平臺面對千萬級(ji)(ji)，乃至億級(ji)(ji)的(de)接入，單體(ti)服(fu)務(wu)(wu)只(zhi)能(neng)(neng)進(jin)行橫(heng)向(xiang)擴展，部(bu)署更多(duo)的(de)單體(ti)式服(fu)務(wu)(wu);而單體(ti)式服(fu)務(wu)(wu)包(bao)含了全(quan)量(liang)的(de)服(fu)務(wu)(wu)功(gong)能(neng)(neng)，任何一個功(gong)能(neng)(neng)出現問題(ti)，會(hui)面臨所有(you)的(de)功(gong)能(neng)(neng)都(dou)不可(ke)用(yong);同(tong)樣(yang)單體(ti)式服(fu)務(wu)(wu)代碼復(fu)雜度也非(fei)(fei)常(chang)高，在服(fu)務(wu)(wu)中包(bao)含了大(da)量(liang)的(de)業務(wu)(wu)邏輯。隨著時間推移，需(xu)求不斷(duan)增(zeng)多(duo)，代碼也越(yue)來(lai)越(yue)復(fu)雜，維護成本也越(yue)來(lai)越(yue)高，甚至對于(yu)修復(fu)bug和新增(zeng)功(gong)能(neng)(neng)都(dou)要非(fei)(fei)常(chang)謹慎，可(ke)謂牽(qian)一發而動全(quan)身。
平(ping)臺(tai)選(xuan)擇微(wei)服(fu)務的整體(ti)架構設計，采用分布式部署(shu)的方式完(wan)美的解決了單(dan)體(ti)服(fu)務所面對(dui)的窘境。
功能原子化，高可維護性
將復(fu)雜的單體式服(fu)(fu)務(wu)以功能點拆(chai)分為專注(zhu)單一(yi)功能的微服(fu)(fu)務(wu)，并(bing)通過定義良好(hao)的接口清(qing)晰地(di)表述服(fu)(fu)務(wu)邊(bian)界，由(you)于(yu)(yu)體積小、復(fu)雜度低，易于(yu)(yu)保(bao)持高(gao)可維護性，并(bing)提(ti)高(gao)了研發效率。
服務獨立性，部署風險低
微(wei)服務(wu)(wu)具備獨立的(de)(de)運行(xing)進程(cheng)，可以(yi)單獨進行(xing)部(bu)署(shu)。當某個微(wei)服務(wu)(wu)發(fa)(fa)生變更時無需(xu)部(bu)署(shu)整個應(ying)用的(de)(de)服務(wu)(wu)，只(zhi)需(xu)要對變更的(de)(de)微(wei)服務(wu)(wu)進行(xing)重新(xin)部(bu)署(shu)。使得發(fa)(fa)布(bu)更加高效，降低了對正式環境(jing)所造成(cheng)的(de)(de)部(bu)署(shu)風險(xian)，最終縮短應(ying)用受(shou)影響的(de)(de)時間。
高擴展，高容錯
微服(fu)務便于橫(heng)向擴展，不同微服(fu)務在擴展需求(qiu)存在差異時，可以(yi)根(gen)據微服(fu)務的(de)實際需求(qiu)進(jin)行獨立擴展，而不需要(yao)對整個應用進(jin)行擴展，節省了(le)(le)資源，提(ti)高了(le)(le)資源利用效率。
微(wei)服(fu)(fu)務(wu)也增加了應(ying)(ying)用(yong)(yong)的(de)(de)高容錯性，在單個微(wei)服(fu)(fu)務(wu)發生故障的(de)(de)情況下，不(bu)會(hui)(hui)影響(xiang)到其他微(wei)服(fu)(fu)務(wu)，導致整個應(ying)(ying)用(yong)(yong)不(bu)可用(yong)(yong)。具備(bei)多(duo)個節點的(de)(de)微(wei)服(fu)(fu)務(wu)，上層的(de)(de)微(wei)服(fu)(fu)務(wu)會(hui)(hui)通過重試可用(yong)(yong)微(wei)服(fu)(fu)務(wu)或(huo)者平(ping)穩(wen)的(de)(de)故障轉(zhuan)移機制實現(xian)應(ying)(ying)用(yong)(yong)層面的(de)(de)高容錯性。
負載均衡
面對大量(liang)(liang)的(de)(de)(de)(de)用戶訪問(wen)，高并發請求，海量(liang)(liang)的(de)(de)(de)(de)數(shu)據，即使是(shi)使用高性能(neng)框(kuang)架和微服務架構的(de)(de)(de)(de)設計(ji)也還(huan)不(bu)能(neng)完全解決應(ying)用服務的(de)(de)(de)(de)壓(ya)力。通常(chang)客戶端在請求服務端時會有一(yi)個統一(yi)的(de)(de)(de)(de)訪問(wen)入口，那這個統一(yi)的(de)(de)(de)(de)訪問(wen)入口是(shi)如何將(jiang)我們(men)的(de)(de)(de)(de)請求分發到(dao)壓(ya)力較(jiao)小的(de)(de)(de)(de)服務器(qi)上去的(de)(de)(de)(de)呢?答案就是(shi)“負載均衡(heng)”。
負載均衡，顧名思義就是將客戶端請求(qiu)進行平衡，分攤到多個服(fu)務器單(dan)元(yuan)，優化(hua)資源的(de)使用(yong)，最大化(hua)吞(tun)吐量(liang)，最小化(hua)響應時間并避免任何的(de)單(dan)一資源過載的(de)技術(shu)。
負載均衡(heng)的分(fen)類主要包(bao)含如下幾種：
二層負載均衡
采用(yong)虛擬(ni)mac的(de)形式(shi)，外部對(dui)虛擬(ni)mac地址請求，負載均衡接收后分(fen)配實際的(de)mac地址服務進行響應處理。
三層負載均衡
采(cai)用(yong)虛擬IP的(de)(de)方式，外(wai)部對(dui)虛擬IP的(de)(de)請求，負載均衡后分配到實際的(de)(de)IP地址進行(xing)響(xiang)應
四層負載均衡(TCP)
四(si)(si)(si)層(ceng)(ceng)負(fu)(fu)載均(jun)衡(heng)是(shi)基于三層(ceng)(ceng)負(fu)(fu)載均(jun)衡(heng)通(tong)過發布三層(ceng)(ceng)負(fu)(fu)載均(jun)衡(heng)的(de)IP地(di)址，加入四(si)(si)(si)層(ceng)(ceng)的(de)端口號，來決定哪些(xie)流量需要做負(fu)(fu)載均(jun)衡(heng);LVS在四(si)(si)(si)層(ceng)(ceng)負(fu)(fu)載均(jun)衡(heng)性能上高于Nginx的(de)。
七層負載均衡(HTTP)
七(qi)層(ceng)(ceng)負(fu)(fu)(fu)載均(jun)衡是在更高的應(ying)用層(ceng)(ceng)上執行負(fu)(fu)(fu)載均(jun)衡，會對每(mei)個(ge)消息(xi)實際(ji)內(nei)(nei)容進(jin)行處理，主要(yao)通過(guo)解析消息(xi)內(nei)(nei)容，得到消息(xi)內(nei)(nei)容的有效標識，最終決定選擇的內(nei)(nei)部服務;例如選用URL來(lai)做(zuo)出負(fu)(fu)(fu)載均(jun)衡決策;Nginx在功(gong)能性和便利性上是要(yao)好于(yu)LVS的。
平(ping)臺(tai)負(fu)載(zai)均(jun)衡(heng)采(cai)用(yong)LVS+Keepalived+Nginx對業(ye)(ye)務流進(jin)行(xing)分發，實(shi)現整體負(fu)載(zai)均(jun)衡(heng);支持TCP、UDP等協(xie)議的四層負(fu)載(zai)均(jun)衡(heng);支持HTTP/HTTPs等協(xie)議的七層負(fu)載(zai)均(jun)衡(heng);新(xin)增(zeng)或刪(shan)除后端(duan)服務后可重新(xin)負(fu)載(zai)業(ye)(ye)務流。
分布式中間件
高并發框架、微服(fu)務(wu)(wu)架構(gou)設計、負載均(jun)衡的使(shi)用解(jie)決了大(da)部(bu)分的服(fu)務(wu)(wu)端的并發壓(ya)力。但海量數(shu)據在磁盤(pan)中的讀寫(xie)，I/O的瓶頸(jing)也(ye)是非常(chang)明顯的。數(shu)據的存儲依舊也(ye)會造成應用服(fu)務(wu)(wu)的瓶頸(jing)。分布(bu)式(shi)中間(jian)件的使(shi)用就尤為重要(yao)了。
分布式緩存
緩存(cun)是(shi)(shi)一種用于(yu)(yu)提(ti)高系統(tong)(tong)響應速度(du)、改善(shan)系統(tong)(tong)運行性(xing)能(neng)的(de)技術。緩存(cun)通常是(shi)(shi)基(ji)于(yu)(yu)內存(cun)的(de)，數(shu)據庫中數(shu)據的(de)讀(du)(du)寫(xie)通常是(shi)(shi)基(ji)于(yu)(yu)磁(ci)盤，從緩存(cun)讀(du)(du)取數(shu)據比從磁(ci)盤讀(du)(du)取數(shu)據快兩(liang)個數(shu)量級(ji)。
分布式消息隊列
消(xiao)息隊列是(shi)一(yi)種用(yong)于(yu)解決應用(yong)耦合、異(yi)步消(xiao)息、流量(liang)削鋒等(deng)場景(jing)的(de)中間件技術。它(ta)可(ke)以實現(xian)高性能、高可(ke)用(yong)、可(ke)伸縮和最終一(yi)致性架構，是(shi)大型(xing)分布式系統(tong)不可(ke)缺少(shao)的(de)中間件。
平(ping)臺微(wei)服(fu)務(wu)架構設(she)計方面(mian)同樣會(hui)使用緩(huan)存-分布式Redis緩(huan)存，分布式Redis緩(huan)存具有高性(xing)能(neng)、動態擴展、高可用、易用性(xing)等特點，采(cai)用集群方式來滿足高讀(du)寫性(xing)能(neng)場景及容量需彈性(xing)變(bian)配(pei)的業務(wu)需求。也(ye)使用了分布式Kafka，其對于消息異步的處理，微(wei)服(fu)務(wu)之間的應用解耦(ou)也(ye)是不可或缺的部分。
