從本篇開始，我們一起深入分析架構(gòu)設(shè)計(jì)復(fù)雜度的 6 個(gè)來(lái)源，先來(lái)聊聊復(fù)雜度的來(lái)源之一高性能。

對(duì)性能孜孜不倦的追求是整個(gè)人類技術(shù)不斷發(fā)展的根本驅(qū)動(dòng)力。例如計(jì)算機(jī)，從電子管計(jì)算機(jī)到晶體管計(jì)算機(jī)再到集成電路計(jì)算機(jī)，運(yùn)算性能從每秒幾次提升到每秒幾億次。但伴隨性能越來(lái)越高，相應(yīng)的方法和系統(tǒng)復(fù)雜度也是越來(lái)越高?，F(xiàn)代的計(jì)算機(jī) CPU 集成了幾億顆晶體管，邏輯復(fù)雜度和制造復(fù)雜度相比最初的晶體管計(jì)算機(jī)，根本不可同日而語(yǔ)。

軟件系統(tǒng)也存在同樣的現(xiàn)象。最近幾十年軟件系統(tǒng)性能飛速發(fā)展，從最初的計(jì)算機(jī)只能進(jìn)行簡(jiǎn)單的科學(xué)計(jì)算，到現(xiàn)在 Google 能夠支撐每秒幾萬(wàn)次的搜索。與此同時(shí)，軟件系統(tǒng)規(guī)模也從單臺(tái)計(jì)算機(jī)擴(kuò)展到上萬(wàn)臺(tái)計(jì)算機(jī)；從最初的單用戶單工的字符界面 Dos 操作系統(tǒng)，到現(xiàn)在的多用戶多工的 Windows 10 圖形操作系統(tǒng)。

當(dāng)然，技術(shù)發(fā)展帶來(lái)了性能上的提升，不一定帶來(lái)復(fù)雜度的提升。例如，硬件存儲(chǔ)從紙帶→磁帶→磁盤→SSD，并沒有顯著帶來(lái)系統(tǒng)復(fù)雜度的增加。因?yàn)樾录夹g(shù)會(huì)逐步淘汰舊技術(shù)，這種情況下我們直接用新技術(shù)即可，不用擔(dān)心系統(tǒng)復(fù)雜度會(huì)隨之提升。只有那些并不是用來(lái)取代舊技術(shù)，而是開辟了一個(gè)全新領(lǐng)域的技術(shù)，才會(huì)給軟件系統(tǒng)帶來(lái)復(fù)雜度，因?yàn)檐浖到y(tǒng)在設(shè)計(jì)的時(shí)候就需要在這些技術(shù)之間進(jìn)行判斷選擇或者組合。就像汽車的發(fā)明無(wú)法取代火車，飛機(jī)的出現(xiàn)也并不能完全取代火車，所以我們?cè)诔鲂械臅r(shí)候，需要考慮選擇汽車、火車還是飛機(jī)，這個(gè)選擇的過程就比較復(fù)雜了，要考慮價(jià)格、時(shí)間、速度、舒適度等各種因素。

軟件系統(tǒng)中高性能帶來(lái)的復(fù)雜度主要體現(xiàn)在兩方面，一方面是單臺(tái)計(jì)算機(jī)內(nèi)部為了高性能帶來(lái)的復(fù)雜度；另一方面是多臺(tái)計(jì)算機(jī)集群為了高性能帶來(lái)的復(fù)雜度。

單機(jī)復(fù)雜度

計(jì)算機(jī)內(nèi)部復(fù)雜度最關(guān)鍵的地方就是操作系統(tǒng)。計(jì)算機(jī)性能的發(fā)展本質(zhì)上是由硬件發(fā)展驅(qū)動(dòng)的，尤其是 CPU 的性能發(fā)展。著名的“摩爾定律”表明了 CPU 的處理能力每隔 18 個(gè)月就翻一番；而將硬件性能充分發(fā)揮出來(lái)的關(guān)鍵就是操作系統(tǒng)，所以操作系統(tǒng)本身其實(shí)也是跟隨硬件的發(fā)展而發(fā)展的，操作系統(tǒng)是軟件系統(tǒng)的運(yùn)行環(huán)境，操作系統(tǒng)的復(fù)雜度直接決定了軟件系統(tǒng)的復(fù)雜度。

操作系統(tǒng)和性能最相關(guān)的就是進(jìn)程和線程。最早的計(jì)算機(jī)其實(shí)是沒有操作系統(tǒng)的，只有輸入、計(jì)算和輸出功能，用戶輸入一個(gè)指令，計(jì)算機(jī)完成操作，大部分時(shí)候計(jì)算機(jī)都在等待用戶輸入指令，這樣的處理性能很顯然是很低效的，因?yàn)槿说妮斎胨俣仁沁h(yuǎn)遠(yuǎn)比不上計(jì)算機(jī)的運(yùn)算速度的。

為了解決手工操作帶來(lái)的低效，批處理操作系統(tǒng)應(yīng)運(yùn)而生。批處理簡(jiǎn)單來(lái)說就是先把要執(zhí)行的指令預(yù)先寫下來(lái)（寫到紙帶、磁帶、磁盤等），形成一個(gè)指令清單，這個(gè)指令清單就是我們常說的“任務(wù)”，然后將任務(wù)交給計(jì)算機(jī)去執(zhí)行，批處理操作系統(tǒng)負(fù)責(zé)讀取“任務(wù)”中的指令清單并進(jìn)行處理，計(jì)算機(jī)執(zhí)行的過程中無(wú)須等待人工手工操作，這樣性能就有了很大的提升。

批處理程序大大提升了處理性能，但有一個(gè)很明顯的缺點(diǎn)：計(jì)算機(jī)一次只能執(zhí)行一個(gè)任務(wù)，如果某個(gè)任務(wù)需要從 I/O 設(shè)備（例如磁帶）讀取大量的數(shù)據(jù)，在 I/O 操作的過程中，CPU 其實(shí)是空閑的，而這個(gè)空閑時(shí)間本來(lái)是可以進(jìn)行其他計(jì)算的。

為了進(jìn)一步提升性能，人們發(fā)明了“進(jìn)程”，用進(jìn)程來(lái)對(duì)應(yīng)一個(gè)任務(wù)，每個(gè)任務(wù)都有自己獨(dú)立的內(nèi)存空間，進(jìn)程間互不相關(guān)，由操作系統(tǒng)來(lái)進(jìn)行調(diào)度。此時(shí)的 CPU 還沒有多核和多線程的概念，為了達(dá)到多進(jìn)程并行運(yùn)行的目的，采取了分時(shí)的方式，即把 CPU 的時(shí)間分成很多片段，每個(gè)片段只能執(zhí)行某個(gè)進(jìn)程中的指令。雖然從操作系統(tǒng)和 CPU 的角度來(lái)說還是串行處理的，但是由于 CPU 的處理速度很快，從用戶的角度來(lái)看，感覺是多進(jìn)程在并行處理。

多進(jìn)程雖然要求每個(gè)任務(wù)都有獨(dú)立的內(nèi)存空間，進(jìn)程間互不相關(guān)，但從用戶的角度來(lái)看，兩個(gè)任務(wù)之間能夠在運(yùn)行過程中就進(jìn)行通信，會(huì)讓任務(wù)設(shè)計(jì)變得更加靈活高效。否則如果兩個(gè)任務(wù)運(yùn)行過程中不能通信，只能是 A 任務(wù)將結(jié)果寫到存儲(chǔ)，B 任務(wù)再?gòu)拇鎯?chǔ)讀取進(jìn)行處理，不僅效率低，而且任務(wù)設(shè)計(jì)更加復(fù)雜。為了解決這個(gè)問題，進(jìn)程間通信的各種方式被設(shè)計(jì)出來(lái)了，包括管道、消息隊(duì)列、信號(hào)量、共享存儲(chǔ)等。

多進(jìn)程讓多任務(wù)能夠并行處理任務(wù)，但本身還有缺點(diǎn)，單個(gè)進(jìn)程內(nèi)部只能串行處理，而實(shí)際上很多進(jìn)程內(nèi)部的子任務(wù)并不要求是嚴(yán)格按照時(shí)間順序來(lái)執(zhí)行的，也需要并行處理。例如，一個(gè)餐館管理進(jìn)程，排位、點(diǎn)菜、買單、服務(wù)員調(diào)度等子任務(wù)必須能夠并行處理，否則就會(huì)出現(xiàn)某個(gè)客人買單時(shí)間比較長(zhǎng)（比如說信用卡刷不出來(lái)），其他客人都不能點(diǎn)菜的情況。為了解決這個(gè)問題，人們又發(fā)明了線程，線程是進(jìn)程內(nèi)部的子任務(wù)，但這些子任務(wù)都共享同一份進(jìn)程數(shù)據(jù)。為了保證數(shù)據(jù)的正確性，又發(fā)明了互斥鎖機(jī)制。有了多線程后，操作系統(tǒng)調(diào)度的最小單位就變成了線程，而進(jìn)程變成了操作系統(tǒng)分配資源的最小單位。

多進(jìn)程多線程雖然讓多任務(wù)并行處理的性能大大提升，但本質(zhì)上還是分時(shí)系統(tǒng)，并不能做到時(shí)間上真正的并行。解決這個(gè)問題的方式顯而易見，就是讓多個(gè) CPU 能夠同時(shí)執(zhí)行計(jì)算任務(wù)，從而實(shí)現(xiàn)真正意義上的多任務(wù)并行。目前這樣的解決方案有 3 種：SMP（Symmetric Multi-Processor，對(duì)稱多處理器結(jié)構(gòu)）、NUMA（Non-Uniform Memory Access，非一致存儲(chǔ)訪問結(jié)構(gòu)）、MPP（Massive Parallel Processing，海量并行處理結(jié)構(gòu)）。其中 SMP 是我們最常見的，目前流行的多核處理器就是 SMP 方案。

操作系統(tǒng)發(fā)展到現(xiàn)在，如果我們要完成一個(gè)高性能的軟件系統(tǒng)，需要考慮如多進(jìn)程、多線程、進(jìn)程間通信、多線程并發(fā)等技術(shù)點(diǎn)，而且這些技術(shù)并不是最新的就是最好的，也不是非此即彼的選擇。在做架構(gòu)設(shè)計(jì)的時(shí)候，需要花費(fèi)很大的精力來(lái)結(jié)合業(yè)務(wù)進(jìn)行分析、判斷、選擇、組合，這個(gè)過程同樣很復(fù)雜。舉一個(gè)最簡(jiǎn)單的例子：Nginx 可以用多進(jìn)程也可以用多線程，JBoss 采用的是多線程；Redis 采用的是單進(jìn)程，Memcache 采用的是多線程，這些系統(tǒng)都實(shí)現(xiàn)了高性能，但內(nèi)部實(shí)現(xiàn)差異卻很大。

集群的復(fù)雜度

雖然計(jì)算機(jī)硬件的性能快速發(fā)展，但和業(yè)務(wù)的發(fā)展速度相比，還是小巫見大巫了，尤其是進(jìn)入互聯(lián)網(wǎng)時(shí)代后，業(yè)務(wù)的發(fā)展速度遠(yuǎn)遠(yuǎn)超過了硬件的發(fā)展速度。例如：

• 2016 年“雙 11”支付寶每秒峰值達(dá) 12 萬(wàn)筆支付。

• 2017 年春節(jié)微信紅包收發(fā)紅包每秒達(dá)到 76 萬(wàn)個(gè)，很多人還依稀記得發(fā)紅包卡住的情況吧。

要支持支付和紅包這種復(fù)雜的業(yè)務(wù)，單機(jī)的性能無(wú)論如何是無(wú)法支撐的，必須采用機(jī)器集群的方式來(lái)達(dá)到高性能。例如，支付寶和微信這種規(guī)模的業(yè)務(wù)系統(tǒng)，后臺(tái)系統(tǒng)的機(jī)器數(shù)量都是萬(wàn)臺(tái)級(jí)別的。

通過大量機(jī)器來(lái)提升性能，并不僅僅是增加機(jī)器這么簡(jiǎn)單，讓多臺(tái)機(jī)器配合起來(lái)達(dá)到高性能的目的，是一個(gè)復(fù)雜的任務(wù)，我針對(duì)常見的幾種方式簡(jiǎn)單分析一下。

1. 任務(wù)分配

任務(wù)分配的意思是指每臺(tái)機(jī)器都可以處理完整的業(yè)務(wù)任務(wù)，不同的任務(wù)分配到不同的機(jī)器上執(zhí)行。

我們先從最簡(jiǎn)單的一臺(tái)服務(wù)器變兩臺(tái)服務(wù)器開始，來(lái)講任務(wù)分配帶來(lái)的復(fù)雜性，整體架構(gòu)示意圖如下。

從圖中可以看到，1 臺(tái)服務(wù)器演變?yōu)?2 臺(tái)服務(wù)器后，架構(gòu)上明顯要復(fù)雜多了，主要體現(xiàn)在：

• 需要增加一個(gè)任務(wù)分配器，這個(gè)分配器可能是硬件網(wǎng)絡(luò)設(shè)備（例如，F(xiàn)5、交換機(jī)等），可能是軟件網(wǎng)絡(luò)設(shè)備（例如，LVS），也可能是負(fù)載均衡軟件（例如，Nginx、HAProxy），還可能是自己開發(fā)的系統(tǒng)。選擇合適的任務(wù)分配器也是一件復(fù)雜的事情，需要綜合考慮性能、成本、可維護(hù)性、可用性等各方面的因素。

• 任務(wù)分配器和真正的業(yè)務(wù)服務(wù)器之間有連接和交互（即圖中任務(wù)分配器到業(yè)務(wù)服務(wù)器的連接線），需要選擇合適的連接方式，并且對(duì)連接進(jìn)行管理。例如，連接建立、連接檢測(cè)、連接中斷后如何處理等。

• 任務(wù)分配器需要增加分配算法。例如，是采用輪詢算法，還是按權(quán)重分配，又或者按照負(fù)載進(jìn)行分配。如果按照服務(wù)器的負(fù)載進(jìn)行分配，則業(yè)務(wù)服務(wù)器還要能夠上報(bào)自己的狀態(tài)給任務(wù)分配器。

這一大段描述，即使你可能還看不懂，但也應(yīng)該感受到其中的復(fù)雜度了，更何況還要真正去實(shí)踐和實(shí)現(xiàn)。

上面這個(gè)架構(gòu)只是最簡(jiǎn)單地增加 1 臺(tái)業(yè)務(wù)機(jī)器，我們假設(shè)單臺(tái)業(yè)務(wù)服務(wù)器每秒能夠處理 5000 次業(yè)務(wù)請(qǐng)求，那么這個(gè)架構(gòu)理論上能夠支撐 10000 次請(qǐng)求，實(shí)際上的性能一般按照 8 折計(jì)算，大約是 8000 次左右。

如果我們的性能要求繼續(xù)提高，假設(shè)要求每秒提升到 10 萬(wàn)次，上面這個(gè)架構(gòu)會(huì)出現(xiàn)什么問題呢？是不是將業(yè)務(wù)服務(wù)器增加到 25 臺(tái)就可以了呢？顯然不是，因?yàn)殡S著性能的增加，任務(wù)分配器本身又會(huì)成為性能瓶頸，當(dāng)業(yè)務(wù)請(qǐng)求達(dá)到每秒 10 萬(wàn)次的時(shí)候，單臺(tái)任務(wù)分配器也不夠用了，任務(wù)分配器本身也需要擴(kuò)展為多臺(tái)機(jī)器，這時(shí)的架構(gòu)又會(huì)演變成這個(gè)樣子。

這個(gè)架構(gòu)比 2 臺(tái)業(yè)務(wù)服務(wù)器的架構(gòu)要復(fù)雜，主要體現(xiàn)在：

• 任務(wù)分配器從 1 臺(tái)變成了多臺(tái)（對(duì)應(yīng)圖中的任務(wù)分配器 1 到任務(wù)分配器 M），這個(gè)變化帶來(lái)的復(fù)雜度就是需要將不同的用戶分配到不同的任務(wù)分配器上（即圖中的虛線“用戶分配”部分），常見的方法包括 DNS 輪詢、智能 DNS、CDN（Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)）、GSLB 設(shè)備（Global Server Load Balance，全局負(fù)載均衡）等。

• 任務(wù)分配器和業(yè)務(wù)服務(wù)器的連接從簡(jiǎn)單的“1 對(duì)多”（1 臺(tái)任務(wù)分配器連接多臺(tái)業(yè)務(wù)服務(wù)器）變成了“多對(duì)多”（多臺(tái)任務(wù)分配器連接多臺(tái)業(yè)務(wù)服務(wù)器）的網(wǎng)狀結(jié)構(gòu)。

• 機(jī)器數(shù)量從 3 臺(tái)擴(kuò)展到 30 臺(tái)（一般任務(wù)分配器數(shù)量比業(yè)務(wù)服務(wù)器要少，這里我們假設(shè)業(yè)務(wù)服務(wù)器為 25 臺(tái)，任務(wù)分配器為 5 臺(tái)），狀態(tài)管理、故障處理復(fù)雜度也大大增加。

上面這兩個(gè)例子都是以業(yè)務(wù)處理為例，實(shí)際上“任務(wù)”涵蓋的范圍很廣，可以指完整的業(yè)務(wù)處理，也可以單指某個(gè)具體的任務(wù)。例如，“存儲(chǔ)”“運(yùn)算”“緩存”等都可以作為一項(xiàng)任務(wù)，因此存儲(chǔ)系統(tǒng)、運(yùn)算系統(tǒng)、緩存系統(tǒng)都可以按照任務(wù)分配的方式來(lái)搭建架構(gòu)。此外，“任務(wù)分配器”也并不一定只能是物理上存在的機(jī)器或者一個(gè)獨(dú)立運(yùn)行的程序，也可以是嵌入在其他程序中的算法，例如 Memcache 的集群架構(gòu)。

2. 任務(wù)分解

通過任務(wù)分配的方式，我們能夠突破單臺(tái)機(jī)器處理性能的瓶頸，通過增加更多的機(jī)器來(lái)滿足業(yè)務(wù)的性能需求，但如果業(yè)務(wù)本身也越來(lái)越復(fù)雜，單純只通過任務(wù)分配的方式來(lái)擴(kuò)展性能，收益會(huì)越來(lái)越低。例如，業(yè)務(wù)簡(jiǎn)單的時(shí)候 1 臺(tái)機(jī)器擴(kuò)展到 10 臺(tái)機(jī)器，性能能夠提升 8 倍（需要扣除機(jī)器群帶來(lái)的部分性能損耗，因此無(wú)法達(dá)到理論上的 10 倍那么高），但如果業(yè)務(wù)越來(lái)越復(fù)雜，1 臺(tái)機(jī)器擴(kuò)展到 10 臺(tái)，性能可能只能提升 5 倍。造成這種現(xiàn)象的主要原因是業(yè)務(wù)越來(lái)越復(fù)雜，單臺(tái)機(jī)器處理的性能會(huì)越來(lái)越低。為了能夠繼續(xù)提升性能，我們需要采取第二種方式：任務(wù)分解。

繼續(xù)以上面“任務(wù)分配”中的架構(gòu)為例，“業(yè)務(wù)服務(wù)器”如果越來(lái)越復(fù)雜，我們可以將其拆分為更多的組成部分，我以微信的后臺(tái)架構(gòu)為例。

通過上面的架構(gòu)示意圖可以看出，微信后臺(tái)架構(gòu)從邏輯上將各個(gè)子業(yè)務(wù)進(jìn)行了拆分，包括：接入、注冊(cè)登錄、消息、LBS、搖一搖、漂流瓶、其他業(yè)務(wù)（聊天、視頻、朋友圈等）。

通過這種任務(wù)分解的方式，能夠把原來(lái)大一統(tǒng)但復(fù)雜的業(yè)務(wù)系統(tǒng)，拆分成小而簡(jiǎn)單但需要多個(gè)系統(tǒng)配合的業(yè)務(wù)系統(tǒng)。從業(yè)務(wù)的角度來(lái)看，任務(wù)分解既不會(huì)減少功能，也不會(huì)減少代碼量（事實(shí)上代碼量可能還會(huì)增加，因?yàn)閺拇a內(nèi)部調(diào)用改為通過服務(wù)器之間的接口調(diào)用），那為何通過任務(wù)分解就能夠提升性能呢？

主要有幾方面的因素：

• 簡(jiǎn)單的系統(tǒng)更加容易做到高性能
  系統(tǒng)的功能越簡(jiǎn)單，影響性能的點(diǎn)就越少，就更加容易進(jìn)行有針對(duì)性的優(yōu)化。而系統(tǒng)很復(fù)雜的情況下，首先是比較難以找到關(guān)鍵性能點(diǎn)，因?yàn)樾枰紤]和驗(yàn)證的點(diǎn)太多；其次是即使花費(fèi)很大力氣找到了，修改起來(lái)也不容易，因?yàn)榭赡軐?A 關(guān)鍵性能點(diǎn)提升了，但卻無(wú)意中將 B 點(diǎn)的性能降低了，整個(gè)系統(tǒng)的性能不但沒有提升，還有可能會(huì)下降。

• 可以針對(duì)單個(gè)任務(wù)進(jìn)行擴(kuò)展
  當(dāng)各個(gè)邏輯任務(wù)分解到獨(dú)立的子系統(tǒng)后，整個(gè)系統(tǒng)的性能瓶頸更加容易發(fā)現(xiàn)，而且發(fā)現(xiàn)后只需要針對(duì)有瓶頸的子系統(tǒng)進(jìn)行性能優(yōu)化或者提升，不需要改動(dòng)整個(gè)系統(tǒng)，風(fēng)險(xiǎn)會(huì)小很多。以微信的后臺(tái)架構(gòu)為例，如果用戶數(shù)增長(zhǎng)太快，注冊(cè)登錄子系統(tǒng)性能出現(xiàn)瓶頸的時(shí)候，只需要優(yōu)化登錄注冊(cè)子系統(tǒng)的性能（可以是代碼優(yōu)化，也可以簡(jiǎn)單粗暴地加機(jī)器），消息邏輯、LBS 邏輯等其他子系統(tǒng)完全不需要改動(dòng)。

既然將一個(gè)大一統(tǒng)的系統(tǒng)分解為多個(gè)子系統(tǒng)能夠提升性能，那是不是劃分得越細(xì)越好呢？例如，上面的微信后臺(tái)目前是 7 個(gè)邏輯子系統(tǒng)，如果我們把這 7 個(gè)邏輯子系統(tǒng)再細(xì)分，劃分為 100 個(gè)邏輯子系統(tǒng)，性能是不是會(huì)更高呢？

其實(shí)不然，這樣做性能不僅不會(huì)提升，反而還會(huì)下降，最主要的原因是如果系統(tǒng)拆分得太細(xì)，為了完成某個(gè)業(yè)務(wù)，系統(tǒng)間的調(diào)用次數(shù)會(huì)呈指數(shù)級(jí)別上升，而系統(tǒng)間的調(diào)用通道目前都是通過網(wǎng)絡(luò)傳輸?shù)姆绞?，性能遠(yuǎn)比系統(tǒng)內(nèi)的函數(shù)調(diào)用要低得多。我們以一個(gè)簡(jiǎn)單的圖示來(lái)說明。

從圖中可以看到，當(dāng)系統(tǒng)拆分 2 個(gè)子系統(tǒng)的時(shí)候，用戶訪問需要 1 次系統(tǒng)間的請(qǐng)求和 1 次響應(yīng)；當(dāng)系統(tǒng)拆分為 4 個(gè)子系統(tǒng)的時(shí)候，系統(tǒng)間的請(qǐng)求次數(shù)從 1 次增長(zhǎng)到 3 次；假如繼續(xù)拆分下去為 100 個(gè)子系統(tǒng)，為了完成某次用戶訪問，系統(tǒng)間的請(qǐng)求次數(shù)變成了 99 次。

為了描述簡(jiǎn)單，我抽象出來(lái)一個(gè)最簡(jiǎn)單的模型：假設(shè)這些系統(tǒng)采用 IP 網(wǎng)絡(luò)連接，理想情況下一次請(qǐng)求和響應(yīng)在網(wǎng)絡(luò)上耗費(fèi)為 1ms，業(yè)務(wù)處理本身耗時(shí)為 50ms。我們也假設(shè)系統(tǒng)拆分對(duì)單個(gè)業(yè)務(wù)請(qǐng)求性能沒有影響，那么系統(tǒng)拆分為 2 個(gè)子系統(tǒng)的時(shí)候，處理一次用戶訪問耗時(shí)為 51ms；而系統(tǒng)拆分為 100 個(gè)子系統(tǒng)的時(shí)候，處理一次用戶訪問耗時(shí)竟然達(dá)到了 149ms。

雖然系統(tǒng)拆分可能在某種程度上能提升業(yè)務(wù)處理性能，但提升性能也是有限的，不可能系統(tǒng)不拆分的時(shí)候業(yè)務(wù)處理耗時(shí)為 50ms，系統(tǒng)拆分后業(yè)務(wù)處理耗時(shí)只要 1ms，因?yàn)樽罱K決定業(yè)務(wù)處理性能的還是業(yè)務(wù)邏輯本身，業(yè)務(wù)邏輯本身沒有發(fā)生大的變化下，理論上的性能是有一個(gè)上限的，系統(tǒng)拆分能夠讓性能逼近這個(gè)極限，但無(wú)法突破這個(gè)極限。因此，任務(wù)分解帶來(lái)的性能收益是有一個(gè)度的，并不是任務(wù)分解越細(xì)越好，而對(duì)于架構(gòu)設(shè)計(jì)來(lái)說，如何把握這個(gè)粒度就非常關(guān)鍵了。

小結(jié)

今天我們分析了軟件系統(tǒng)中高性能帶來(lái)的復(fù)雜度主要體現(xiàn)的兩方面：

• 一是單臺(tái)計(jì)算機(jī)內(nèi)部為了高性能帶來(lái)的復(fù)雜度；
• 二是是多臺(tái)計(jì)算機(jī)集群為了高性能帶來(lái)的復(fù)雜度

希望對(duì)你有所幫助。

【星猿雜談】：在這里我們共同探索科技新趨勢(shì)，分享積累的點(diǎn)滴，從編程語(yǔ)言到系統(tǒng)架構(gòu)，從人工智能到高性能計(jì)算，我們追求技術(shù)的進(jìn)步，同時(shí)珍視分享的力量。歡迎關(guān)注我們，在技術(shù)的精彩世界中一起遨游，發(fā)現(xiàn)更多未知！文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-816108.html

到了這里，關(guān)于架構(gòu)篇04：復(fù)雜度來(lái)源 - 高性能的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！