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