隨著社會數(shù)字化進程不斷的提升，數(shù)字技術(shù)正在以新方式、新理念、新形態(tài)逐漸融入我們的經(jīng)濟、文化、生產(chǎn)生活等各個領(lǐng)域乃至全過程。而在這背后涌現(xiàn)出的是海量數(shù)據(jù)以及海量設(shè)備高并發(fā)等問題，這也使業(yè)務(wù)系統(tǒng)面臨前所未有的巨大的挑戰(zhàn)。目前OneNET城市物聯(lián)網(wǎng)平臺面對大連接的應(yīng)用場景，經(jīng)受住了海量數(shù)據(jù)和高并發(fā)的挑戰(zhàn)。那么，如此高的性能挑戰(zhàn)，平臺是如何進行應(yīng)對的？

　　作者：張?zhí)熘?/span>

　　單位：中移物聯(lián)網(wǎng)有限公司

　　Part 01

　　●  高并發(fā)框架 ●

　　高并發(fā)是一種在“同一時間點或極短時間內(nèi)出現(xiàn)大量的操作請求”的場景。而傳統(tǒng)的網(wǎng)絡(luò)通信模型，在面對海量數(shù)據(jù)高并發(fā)場景，已經(jīng)顯得力不從心；一款優(yōu)秀的高并發(fā)框架是現(xiàn)階段網(wǎng)絡(luò)通信必不可少的一環(huán)，如：Grizzly、Netty，Mina。平臺在面對海量設(shè)備接入場景，選擇了Netty成為整個接入能力的核心框架。其單節(jié)點百萬級接入，集群千萬級的海量接入能力成為了當(dāng)前平臺在高并發(fā)場景下的解決方案。

　　- Netty是什么?

　　是一個異步事件驅(qū)動的Java開源網(wǎng)絡(luò)應(yīng)用程序框架，用于快速開發(fā)可維護的高性能協(xié)議服務(wù)器和客戶端。

　　- 為什么要選用Netty？

　　相較于傳統(tǒng)的IO模型，Netty的IO線程NioEventLoop 聚合了多路復(fù)用器Selector，可以同時并發(fā)處理成千上萬個客戶端連接，在線程從客戶端讀寫數(shù)據(jù)閑暇時，線程可以進行其他任務(wù)，而無需等待讀寫數(shù)據(jù)。在線程模型上，Netty的線程模型也叫Reactor模型，核心是基于事件驅(qū)動的方式來處理事件；其分布式的異步架構(gòu)，使得事件處理器之間高度解耦，可以方便擴展事件處理邏輯；同時通過隊列暫存事件，線程消費事件，能方便并行異步處理事件。

　　- Netty的優(yōu)勢是什么？

　　Netty適用于各種傳輸類型的統(tǒng)一API阻塞和非阻塞Socket；基于靈活且可擴展的事件模型，可以清晰地讓開發(fā)者專注于業(yè)務(wù)而無需關(guān)注底層架構(gòu)，提升了開發(fā)效率；具備高度可定制的線程模型-單線程，一個或多個線程池；真正的無連接數(shù)據(jù)報套接字的支持。Zero-Copy技術(shù)使得Netty有更低的資源消耗，以及不必要的內(nèi)存拷貝。

　　Part 02

　　●  微服務(wù)架構(gòu) ●

　　“一根筷子易折斷，一把筷子難折斷”。對于平臺也是一樣，巨大的單體式服務(wù)總會到達一個性能瓶頸。平臺面對千萬級，乃至億級的接入，單體服務(wù)只能進行橫向擴展，部署更多的單體式服務(wù)；而單體式服務(wù)包含了全量的服務(wù)功能，任何一個功能出現(xiàn)問題，會面臨所有的功能都不可用；同樣單體式服務(wù)代碼復(fù)雜度也非常高，在服務(wù)中包含了大量的業(yè)務(wù)邏輯。隨著時間推移，需求不斷增多，代碼也越來越復(fù)雜，維護成本也越來越高，甚至對于修復(fù)bug和新增功能都要非常謹(jǐn)慎，可謂牽一發(fā)而動全身。

　　平臺選擇微服務(wù)的整體架構(gòu)設(shè)計，采用分布式部署的方式完美的解決了單體服務(wù)所面對的窘境。

　　- 功能原子化，高可維護性

　　將復(fù)雜的單體式服務(wù)以功能點拆分為專注單一功能的微服務(wù)，并通過定義良好的接口清晰地表述服務(wù)邊界，由于體積小、復(fù)雜度低，易于保持高可維護性，并提高了研發(fā)效率。

　　- 服務(wù)獨立性，部署風(fēng)險低

　　微服務(wù)具備獨立的運行進程，可以單獨進行部署。當(dāng)某個微服務(wù)發(fā)生變更時無需部署整個應(yīng)用的服務(wù)，只需要對變更的微服務(wù)進行重新部署。使得發(fā)布更加高效，降低了對正式環(huán)境所造成的部署風(fēng)險，最終縮短應(yīng)用受影響的時間。

　　- 高擴展，高容錯

　　微服務(wù)便于橫向擴展，不同微服務(wù)在擴展需求存在差異時，可以根據(jù)微服務(wù)的實際需求進行獨立擴展，而不需要對整個應(yīng)用進行擴展，節(jié)省了資源，提高了資源利用效率。

　　微服務(wù)也增加了應(yīng)用的高容錯性，在單個微服務(wù)發(fā)生故障的情況下，不會影響到其他微服務(wù)，導(dǎo)致整個應(yīng)用不可用。具備多個節(jié)點的微服務(wù)，上層的微服務(wù)會通過重試可用微服務(wù)或者平穩(wěn)的故障轉(zhuǎn)移機制實現(xiàn)應(yīng)用層面的高容錯性。

　　Part 03

　　●  負(fù)載均衡 ●

　　面對大量的用戶訪問，高并發(fā)請求，海量的數(shù)據(jù)，即使是使用高性能框架和微服務(wù)架構(gòu)的設(shè)計也還不能完全解決應(yīng)用服務(wù)的壓力。通常客戶端在請求服務(wù)端時會有一個統(tǒng)一的訪問入口，那這個統(tǒng)一的訪問入口是如何將我們的請求分發(fā)到壓力較小的服務(wù)器上去的呢？答案就是“負(fù)載均衡”。

　　負(fù)載均衡，顧名思義就是將客戶端請求進行平衡，分?jǐn)偟蕉鄠€服務(wù)器單元，優(yōu)化資源的使用，最大化吞吐量，最小化響應(yīng)時間并避免任何的單一資源過載的技術(shù)。

　　負(fù)載均衡的分類主要包含如下幾種：

　　二層負(fù)載均衡

　　采用虛擬mac的形式，外部對虛擬mac地址請求，負(fù)載均衡接收后分配實際的mac地址服務(wù)進行響應(yīng)處理。

　　三層負(fù)載均衡

　　采用虛擬IP的方式，外部對虛擬IP的請求，負(fù)載均衡后分配到實際的IP地址進行響應(yīng)

　　四層負(fù)載均衡(TCP)

　　四層負(fù)載均衡是基于三層負(fù)載均衡通過發(fā)布三層負(fù)載均衡的IP地址，加入四層的端口號，來決定哪些流量需要做負(fù)載均衡；LVS在四層負(fù)載均衡性能上高于Nginx的。

　　七層負(fù)載均衡(HTTP)

　　七層負(fù)載均衡是在更高的應(yīng)用層上執(zhí)行負(fù)載均衡，會對每個消息實際內(nèi)容進行處理，主要通過解析消息內(nèi)容，得到消息內(nèi)容的有效標(biāo)識，最終決定選擇的內(nèi)部服務(wù)；例如選用URL來做出負(fù)載均衡決策；Nginx在功能性和便利性上是要好于LVS的。

　　平臺負(fù)載均衡采用LVS+Keepalived+Nginx對業(yè)務(wù)流進行分發(fā)，實現(xiàn)整體負(fù)載均衡；支持TCP、UDP等協(xié)議的四層負(fù)載均衡；支持HTTP/HTTPs等協(xié)議的七層負(fù)載均衡；新增或刪除后端服務(wù)后可重新負(fù)載業(yè)務(wù)流。

　　Part 04

　　●  分布式中間件 ●

　　高并發(fā)框架、微服務(wù)架構(gòu)設(shè)計、負(fù)載均衡的使用解決了大部分的服務(wù)端的并發(fā)壓力。但海量數(shù)據(jù)在磁盤中的讀寫，I/O的瓶頸也是非常明顯的。數(shù)據(jù)的存儲依舊也會造成應(yīng)用服務(wù)的瓶頸。分布式中間件的使用就尤為重要了。

　　- 分布式緩存

　　緩存是一種用于提高系統(tǒng)響應(yīng)速度、改善系統(tǒng)運行性能的技術(shù)。緩存通常是基于內(nèi)存的，數(shù)據(jù)庫中數(shù)據(jù)的讀寫通常是基于磁盤，從緩存讀取數(shù)據(jù)比從磁盤讀取數(shù)據(jù)快兩個數(shù)量級。

　　- 分布式消息隊列

　　消息隊列是一種用于解決應(yīng)用耦合、異步消息、流量削鋒等場景的中間件技術(shù)。它可以實現(xiàn)高性能、高可用、可伸縮和最終一致性架構(gòu)，是大型分布式系統(tǒng)不可缺少的中間件。

　　平臺微服務(wù)架構(gòu)設(shè)計方面同樣會使用緩存-分布式Redis緩存，分布式Redis緩存具有高性能、動態(tài)擴展、高可用、易用性等特點，采用集群方式來滿足高讀寫性能場景及容量需彈性變配的業(yè)務(wù)需求。也使用了分布式Kafka，其對于消息異步的處理，微服務(wù)之間的應(yīng)用解耦也是不可或缺的部分。