“世間可稱之為天經地義的事情沒幾樣，復雜的互聯網架構也是如此，萬丈高樓平地起，架構都是演變而來，那么演變的本質是什么？”

---

—?1?—?引子

? ? 軟件復雜性來源于幾個方面：高并發、高性能、高可用、可擴展、低成本、低規模、可維護、安全等。架構演化、發展都是為了試圖降低復雜性：

• 高并發、高性能：互聯網系統特點，用戶量大，請求量大，高并發高性能成為必備要求。性能差體驗會差，用戶會有別的選擇。

• 高可用：系統高可用可提升用戶體驗，也變為必備要求。十幾年前我們買股票都需要T+N操作，而現在通過手機可以實時辦理。

• 可擴展、易迭代：在產品初期，采用單體或簡單的架構。成熟期，演進為現在大中臺、小前臺的概念，把不變的和變的拆分開來。產品經理、架構師需避免無限放大需求，面向未來設計，進入尷尬境地。

• 低成本：是個過程。ROI投入產出比越往后越低。

• 低規模：規模小，成本肯定低，運維、擴展.... 都將方便。所以簡單、適用、演進架構設計原則很重要。

• 易運維：除了傳統運維方面。業務的快速發展，灰度發布、快速發布回滾、部分功能升級、ab測試等對架構層面提出了更高要求，也是現在容器化技術這么流行的原因之一。

? ? 本文主要從如何實現高并發、高性能系統角度，剖析網絡應用架構演進過程中，解決的那些關鍵點，并找到一些規律。也可指導我們在構建高并發、高性能系統時，應該注意哪些環節。

• 如何更有效的利用單機資源？開源軟件在高性能、高并發中做了哪些實踐。

• 如何在高并發前提下，利用跨機器遠程調用提升并發及“性能”。分布式服務如何拆分，怎么拆分才能達到高性能高可用，并不浪費資源？

注：太多的調用鏈路，性能是有很大損耗的。

... ...

篇幅有限，文章不會鋪開講所有細節。

---

—?2?—?從網絡連接開始

? ? 瀏覽器/app與后端通信一般使用http、https協議，底層都是使用TCP（Transmission Control Protocol 傳輸控制協議），而RPC遠程調用可直接使用TCP連接。我們從TCP連接開始文章。

? ? 大家都知道TCP 三次握手建立連接、四次揮手斷開連接，簡述如下：

• 建立連接都是客戶端主動發起，經過三次交替交互后（中間會有狀態），雙方狀態都變為 ESTABLISHED狀態，可以開始雙工數據傳送。

• 斷開連接雙方都可以主動發起， 分別發起、回復一共四次交互（中間會有狀態），關閉連接。

注：詳細細節請參閱相關文檔，Windows和Linux服務器都可以使用netstat -an命令查看。

網絡編程中，關于連接這塊我們一般會關注以下指標：

1、連接相關

? ? 服務端能保持，管理，處理多少客戶端的連接。

• 活躍連接數：所有ESTABLISHED狀態的TCP連接，某個瞬時，這些連接正在傳輸數據。如果您采用的是長連接的情況，一個連接會同時傳輸多個請求。也可以間接考察后端服務并發處理能力，注意不同于并發量。

• 非活躍連接數：表示除ESTABLISHED狀態的其它所有狀態的TCP連接數。

• 并發連接數：所有建立的TCP連接數量。并發連接數 = 活躍連接數 + 非活躍連接數。

• 新建連接數：在統計周期內，從客戶端連接到服務器端，新建立的連接請求的平均數。主要考察應對 突發流量或從正常到高峰流量的能力。如：秒殺、搶票場景。

• 丟棄連接數：每秒丟棄的連接數。如果連接服務器做了連接熔斷處理，這部分數據即熔斷的連接。

? ? 關于tcp連接數量，在linux下，跟文件句柄描述（fd）項有關，可以ulimit -n查看，也可修改。其它就是跟硬件資源cpu、內存、網絡帶寬有關。單機可以做到數十萬級的并發連接數，如何實現呢？后面IO模型時講解。

2、流量相關

? ? 主要是網絡帶寬的配置。

• 流入流量：從外部訪問服務器所消耗的流量。

• 流出流量：服務器對外響應的流量。

3、數據包數?

? ? 數據包是TCP三次握手建立連接后，傳輸的內容封裝

• 流入數據包數：服務器每秒接到的請求數據包數量。

• 流出數據包數：服務器每秒發出的數據包數量。

? ? 關于TCP/IP包的細節請查閱相關文檔。但是有一點一定注意，我們單次請求可能會分成多個包發送，拆包、粘包問題網絡中間件都會為我們處理（比如消息補齊、回車結尾、自定義消息頭體、自定義協議等解決方案）。如果我們傳遞的用戶數據較小，那么效率肯定會提升。反過來無限制的壓縮傳輸包的大小，解壓也會耗費cpu資源，需平衡處理。

4、應用傳輸協議

? ? 傳輸協議壓縮率好，傳輸性能好，對并發性能提升高。但是也需要看調用雙方的語言可以使用協議才行?？梢宰约憾x，也可以使用成熟的傳輸協議。比如redis的序列化傳輸協議、json傳輸協議、Protocol Buffers傳輸協議、http協議等。? 尤其在 rpc調用過程中，這個傳輸協議選擇需要仔細甄別選型。

5、長、短連接

• 長連接是指在一個TCP連接上，可以重用多次發送數據包，在TCP連接保持期間，如果沒有數據包發送，需要雙方發檢測包以維持此連接。?

• 半開連接的處理：當客戶端與服務器建立起正常的TCP連接后，如果客戶主機掉線（網線斷開）、電源掉電、或系統崩潰，服務器將永遠不會知道。長連接中間件，需要處理這個細節。linux默認配置2小時，可以通過配置修改。

• 短連接是指通信雙方有數據交互時，就建立一個TCP連接，數據發送完成后，則斷開此TCP連接。但是每次建立連接需要三次握手、斷開連接需要四次揮手。

• 關閉連接最好由客戶端主動發起，TIME_WAIT這個狀態最好不要在服務器端，減少占用資源。

??? 選擇建議：

• 在客戶端數量少場景一般使用長連接。后端中間件、微服務之間通信最好使用長連接。如：數據庫連接，duboo默認協議等。?

• 而大型web、app應用，使用http短連接（http1.1的keep alive變相的支持長連接，但還是串行請求/響應交互）。http2.0支持真正的長連接。

• 長連接會對服務端耗費更多的資源，上百萬用戶，每個用戶獨占一個連接，對服務端壓力多大，成本多高。IM、push應用會使用長連接，但是會做很多優化工作。

• 由于https需要加解密運算等，最好使用http2.0（強制ssl），傳輸性能很好。但是服務端需要維持更多的連接。

6、關于并發連接與并發量

• 并發連接數：= 活躍連接數 + 非活躍連接數。所有建立的TCP連接數量。網絡服務器能并行管理的連接數。

• 活躍連接數：所有ESTABLISHED狀態的TCP連接。

• 并發量：瞬時通過活躍連接傳輸數據的量，這個量一般在處理端好評估。跟活躍連接數沒有絕對的關系。網絡服務器能并行處理的業務請求數。

• rt響應時間：各類操作單機rt肯定不相同。比如：從cache中讀數據和分布式事務寫數據庫，資源的消耗不同，操作時間本身就不同。

• 吞吐量：QPS/TPS，每秒可以處理的查詢或事務數，這個是關鍵指標。

從系統整體層面、各個服務個體、服務中某個方法都需綜合考慮。

舉例如下：

• 打開商品詳情頁操作，需要動靜分離。后續一連串的動態服務、cache機制，整體rt本身會短，單機可以支持的qps較高。（服務間、方法間也有差別）

• 而提交訂單操作需要分布式事務、分布式鎖等，rt本身會長，單機可支持的qps較低。

• 那是否我們就會針對訂單提交的服務部署更多機器呢？答案是不一定。因為用戶瀏覽商品的頻度會很高，而提交訂單的頻度很低。如何正確的評估呢？

• 需要服務分類：關鍵服務/非關鍵服務、高峰各服務的qps需求，來均衡考慮。

? ? 系統整體吞吐量、RT響應時間、支持并發數 是由小的操作、微服務組成的，各個微服務、操作也需要分別評估。平衡組合后，形成系統整體的各項指標。

7、小節

首先看一個典型的互聯網服務端處理網絡請求的典型過程：

注：另外關于用戶態、內核態數據轉換，有些特殊場景中，中間件如kafka可以使用zero copy技術，避免兩態切換開銷。

a、（1，2，3 ）三個步驟表示客戶端網絡請求，建立連接（管理連接），發送請求，服務器接收請求數據。

b、（4）構建響應，在用戶空間處理客戶端的請求，構建響應完成。

c、（5，6，7） 服務器把響應，通過a中fd連接，send發送響應客戶端。

? ? 可以把上面分為兩個關鍵點：

• a和c 服務器如何管理網絡連接，從客戶端獲得輸入數據，為客戶端響應數據。

• b服務器如處理請求。

網絡應用應該考慮平衡a+c和b，處理這些連接的能力 與 能管理的連接請求達到平衡。?

比如：有個應用并發連接數十萬；而這些連接大約每秒請求2萬次；需要管理10萬連接，每秒處理2萬請求能能力，才能達到平衡。如何達到處理高qps呢，兩個方向：

• 單機優化（見后中間件例子）

• 轉發到別的多臺機器處理（遠程調用）

注：一般系統管理連接能力遠遠大于處理能力。

如上圖，客戶端的請求會形成一個大隊列；服務器會處理這個大隊列中的任務。這個隊列能有多大，看連接管理能力；如何保證進入隊列任務的速率和處理移除任務的速度平衡，是關鍵。達到平衡是目的。

---

—?3?—?網絡編程中常用IO模型

? ? 客戶端與服務器的交互都會產生個連接，linux中在服務器端由文件描述項 fd、socket編程中socket連接、java語言api中channel等體現。而IO模型，可以理解為管理fd，并通過fd從客戶端read獲取數據（客戶端請求）和通過fd往客戶端write數據（響應客戶端）的機制。

? ? 關于同步，異步、阻塞、非阻塞 IO操作，網上、書籍上描述都不相同，也找不到準確描述。我們按照《UNIX網絡編程：卷一》第六章——I/O復用為標準。書中向我們提及了5種類UNIX下可用的I/O模型：阻塞式I/O、非阻塞式I/O、I/O復用(selece,poll,epoll)、信號驅動式I/O、異步I/O。（詳細可以查閱相關書籍資料）

1、阻塞式I/O：進程會卡在recvfrom的調用，等到最終結果數據返回。肯定屬于同步。?

? ? 2、非阻塞式I/O：進程反復輪詢調用recvfrom，直到最終結果數據返回。也是同步調用，但是IO內核處理是非阻塞的。沒什么實用意義，不討論應用。

? ? 3、I/O復用也屬于同步：進程卡在select、epoll調用上，不會卡在recvfrom上，直到最終結果返回。?

注：select 模型：把要管理的fd放到一個數組里，循環這個數組。數組大小1024，可管理連接有限。poll 與select類似，只是把數組類型改為鏈表，沒有1024大小限制。

? ? 而epoll 為 event poll，只會管理有事件發生的 fd，也就是只會處理活躍的連接。epoll通過內核和用戶空間共享一塊mmap()文件映射內存來實現的消息傳遞。參考? http://libevent.org/

? ? 4、信號驅動式I/O：也是同步。只有unix實現，不討論。

? ? 5、異步：只有異步I/O屬于真正的異步。底層操作系統只有window實現，不討論。nodejs中間件通過回調實現，java AIO也有實現。開發難度較大。

IO模型中同步/異步、阻塞/非阻塞的差別(好繞)：

• 同步異步：訪問數據的方式，同步需主動讀寫數據，要求被調用方IO返回最終的結果。而異步發出請求后，只需等待IO操作完成的通知，并不主動讀寫數據，由系統內核完成；

• 而阻塞和非租塞的區別在于，進程或線程要訪問的數據是否就緒，進程或線程是否需要等待；等待就是阻塞，不需要等待就是非阻塞。

而我們平時在編程、函數接口調用過程中，除了超時以外，都會返回一個結果。同步異步調用按照以下區分：

• 如果返回的結果是最終結果，就是同步調用，如：調用數據查詢sql。

• 如果返回的結果是個中間通知，那么是異步：如：發送消息給mq，只會返回ack信息。對于發消息來說，是同步；如果從系統架構層面看，算異步，因為處理結果由消息消費者來處理產生。如果發送成功，但是突然斷網沒有收到ack，這是屬于故障，不在討論范圍內。

• 同步調用，參數中可以傳遞一個回調函數的方式：需要語言或中間件引擎執行。如jvm支持，node v8引擎支持。（需要回調函數的執行，跟調用端在一個context內，共享棧變量等）

注：select關鍵字可別混淆！！！IO多路復用從技術實現上有多種：select、poll、epoll 詳細自己參閱資料，幾乎所有中間件都會使用epoll模式。另外由于各個操作系統對多路復用實現機制不同，epoll、kqueue、IOCP接口都有自己的特點，第三方庫封裝了這些差異，提供統一的API，如Libevent。另外如java語言，netty提供更高層面的封裝，javaNIO和netty使用保留了select方法，也引起一些混淆。?

小節：現在網絡中間件都是用 阻塞IO和IO多路復用這兩個模型來管理連接，通過網絡IO獲取數據。下節講解，使用IO模型的一些中間件案例。

---

—?4?—?同步阻塞IO模型的具體實現模型-PPC,TPC

? ? 服務器處理數據問題，從純網絡編程技術角度看，主要思路有兩個：

• 一個是對于每個連接處理分配一個獨立的進程/線程，直到處理完成。PPC,TPC模式；

• 另一個思路是用同一進程/線程來同時處理若干連接，處理連接中數據，通過多線程、多進程技術。Reactor模式；

每個進程/線程處理一個連接，叫PPC或TPC。PPC是Process Per Connection， TPC是Thread Per Conection ，傳統阻塞IO模型實現的網絡服務器采用這種模式。

? ??注：close特指主進程對連接的計數，連接實際在子進程中關閉。而多線程實現中，主線程不需要close操作，因為父子線程共享存儲。如：java中jmm

注：pre模式，預先創建線程和進程，連接進來，分配到預先創建好的線程或進程。多進程時有驚群現象。

申請線程或進程會占用很多系統資源,操作系統cpu、內存有限度，能同時管理的線程有限，處理連接的線程不能太多。雖然可以提前建立好進程或線程來處理數據（prefork/prethead）或通過線程池來減少線程建立壓力。但是線程池的大小是個天花板。另外父子進程通信也比較復雜。

apache MPM prefork（ppc），可支持256的并發連接，tomcat 同步IO（tpc）采用阻塞IO方式工作，可支持500個并發連接。java可以創建線程池來降低一定創建線程資源開銷來處理。

網絡連接fd可以支持上萬個，但是每個線程需要占有系統內存，線程同時存在的總數有限。linux下用命令ulimit -s可以查看棧內存分配。線程多了對cup的資源調度開銷。失衡情況發生，如何解決呢？

小節：ppc、tpc瓶頸是能夠管理的連接數少。本來多線程處理業務能力夠，這下與fd綁定了，線程生命周期與fd一樣了，限定了線程處理能力。拆分：把fd生命周期與線程的生命周期拆分開來。

---

—?5?—?IO模型的具體實現模型-Reactor

? ? 每個進程/線程同時處理多個連接（IO多路復用），多個連接共用一個阻塞對象，應用程序只需要在一個阻塞對象上等待，無需阻塞等待所有連接。當某條連接有新的數據可以處理時，操作系統通知應用程序，線程從阻塞狀態返回（還有更好優化，見下小節），開始進行業務處理；就是Reactor模式思想。

? ??Reactor 模式，是指通過一個或多個輸入同時傳遞給服務處理器的服務請求的事件驅動處理模式。服務端程序處理客戶端傳入的多路請求，并將它們同步分派給請求對應的處理線程，Reactor 模式也叫 Dispatcher 模式。即 I/O 多路復用統一監聽事件，收到事件后分發(Dispatch 給某進程)，是編寫高性能網絡服務器的必備技術之一。很多優秀的網絡中間件都是基于該思想的實現。

注：由于epoll比select管理的連接數大了好多，libevent,netty等框架中底層實現都是epoll方式，但是編程API保留了select關鍵字。所以文章中epoll_wait跟select等同。

Reactor模式有幾個關鍵的組成：

• Reactor：Reactor在一個單獨的線程運行，負責監聽fd事件，分發給適當的處理程序對IO事件做出反應。建立連接事件分發給Acceptor；分發read/write處理事件給Handler。

• Acceptor：負責處理建立連接事件，并建立對應的Handler對象。

• Handlers：負責處理read和write事件。從fd中獲取請求數據；處理數據得到相應數據；send相應數據。處理程序執行IO事件要完成的實際事情。

? ? 對于IO密集型（IO bound）場景，可以使用Reactor場景，但是ThreadLocal將不能使用。開發調試難度較大，一般不建議自己實現，使用現有框架即可。

小節：Reactor解決可管理的網絡連接數量提升到幾十萬。但是如此多連接上請求任務，還是需要通過多線程、多進程機制處理。甚至負載轉發到其它服務器處理。

---

—?6?—?Reactor模式實踐案例（C語言）

? ? 通過幾個開源框架的例子，了解不同場景下的網絡框架，是如何使用Reactor模式，做了哪些細節調整。

注：實際實現肯定與圖差別很大?？蛻舳薸o及send比較簡單，圖中省略。

A、單Reactor+單線程處理（整體一個線程）redis為代表

如圖所示：

客戶端請求->Reactor對象接受請求，并通過select(epoll_wait)監聽請求事件->通過dispatch分發事件；

如果是連接請求事件->dispatch->Acceptor(accept建立連接)->為這個連接創建一個Handler 對象等待后續業務處理。

如果不是建立連接事件->dispatch分發事件->觸發到為這個連接創建的那個Handler對象（read、業務處理、send），形成一個任務/命令隊列。

Handler對象完成read->業務處理->send整體流程。

把請求轉化為命令隊列，單進程處理。注意圖中 隊列，單線程處理，是沒有競爭的。

優點：

• 模型簡單。這個模型是最簡單的，代碼實現方便，適合計算密集型應用

• 不用考慮并發問題。模型本身是單線程的，使得服務的主邏輯也是單線程的，那么就不用考慮許多并發的問題，比如鎖和同步

• 適合短耗時服務。對于像redis這種每個事件基本都是查內存，是十分適合的，一來并發量可以接受，二來redis內部眾多數據結構都是非常簡單地實現

缺點：

• 性能問題，只有一個線程，無法完全發揮多核 CPU 的性能。

• 順序執行影響后續事件。因為所有處理都是順序執行的，所以如果面對長耗時的事件，會延遲后續的所有任務，特別對于io密集型的應用，是無法承受的

• 這也是為什么redis禁止大家使用耗時命令? ??

? ??注：redis是自己實現的io多路復用，沒有使用libevent，實現與圖不符，更加輕巧。

這種模型對于處理讀寫事件操作很短很短時間內執行完。大約可達到10萬QPS吞吐量(redis各種命令差別很大)。

注：redis發布版本中自帶了redis-benchmark性能測試工具，可以使用它計算qps。示例：使用50個并發連接，發出100000個請求，每個請求的數據為2kb，測試host為127.0.0.1端口為6379的redis服務器性能：./redis-benchmark -h127.0.0.1 -p 6379 -c 50 -n 100000 -d 2

對于客戶端數量多的網絡系統，強調多客戶端，也就是并發連接數。? 對于后端連接數少的的網絡系統，采用長連接，并發連接數少，但是每個連接發起的請求數多。

B、單 Reactor+單隊列+業務線程池

? ? 如圖所示，我們按把真正的業務處理從 Reactor線程中剝離出來，通過業務線程池來實現。那么Reactor中每個fd的Handler對象如何與 Worker線程池通信的，通過待處理請求隊列 ?？蛻舳藢Ψ掌鞯恼埱?#xff0c;本來可以想象成一個請求隊列IO， 這里經過Reactor(多路復用)處理后，（拆分）轉化為一個待處理工作任務的隊列。?

注：處處是拆分啊！

? ? 業務線程池分配獨立的線程池，從隊列中拿到數據進行真正的業務處理，將結果返回Handler。Handler收到響應結果后，send結果給客戶端。

與A模型相比，利用線程池技術加快了客戶端請求處理能力。例如：thrift0.10.0版本中 nonblocking server ?采用這種模型，能達到幾萬級別的QPS。

缺點：這種模型的缺點就在于這個隊列上，是性能瓶頸。線程池從隊列獲取任務需要加鎖，會采用高性能的讀寫鎖實現隊列。

C、單 Reactor+N隊列+N線程

這種模型是 A和B的變種模型，memcached采用這種模型。待處理工作隊列分為多個，每個隊列綁定一個線程來處理，這樣最大的發揮了IO多路復用對網絡連接的管理，把單隊列引起的瓶頸得到釋放。QPS估計可達到20萬。

但是這種方案有個很大的缺點，負載均衡可能導致有些隊列忙，有些空閑。好在memcached 也是內存的操作，對負載問題不是很敏感，可以使用該模型。

D、單進程Reactor監聽+N進程（accept+epoll_wait+處理）模型

流程：

master（Reactor主進程）進程監聽新連接的到來，并讓其中一個worker進程accept。這里需要處理驚群效應問題，詳見nginx的accept_mutex設計

worker（subReactor進程）進程accept到fd之后，把fd注冊到到本進程的epoll句柄里面，由本進程處理這個fd的后續讀寫事件

worker進程根據自身負載情況，選擇性地不去accept新fd，從而實現負載均衡

優點：

• 進程掛掉不會影響這個服務

• 是由worker主動實現負載均衡的，這種負載均衡方式比由master來處理更簡單

缺點：

• 多進程模型編程比較復雜，進程間同步沒有線程那么簡單

• 進程的開銷比線程更多

nginx使用這種模型，由于nginx主要提供反向代理與靜態內容web服務功能，qps指標與被nginx代理的處理服務器有關系。

注：nodejs多進程部署方式與nginx方式類似。

小節：期望從這幾個 Reactor的實例中，找到拆分解決了哪些問題，引起了哪些問題。

---

—?7?—?Reactor模式實踐案例（Java語言Netty）

? ? Netty是 一個異步事件驅動的網絡應用程序框架，用于快速開發可維護的高性能協議服務器和客戶端，java語言的很多開源網絡中間件使用了netty，本文只描述針對NIO多路復用相關部分，很多拆包粘包、定時任務心跳監測、序列化鉤子等等可參閱資料。如圖所示：

netty可以通過配置，來實現各個模塊在哪個線程（池）中運行：

1、單Reactor單線程

EventLoopGroup?bossGroup?=?new?NioEventLoopGroup(1);//netty默認只會單Reactor EventLoopGroup?workerGroup?=?bossGroup?;//監聽線程和工作線程使用一個 ServerBootstrap?server?=?new?ServerBootstrap(); server.group(bossGroup, workerGroup)；

2、單Reactor多線程subReactor

EventLoopGroup bossGroup = new NioEventLoopGroup(1); EventLoopGroup workerGroup = new NioEventLoopGroup();//默認cup核心*2 ServerBootstrap server = new ServerBootstrap(); server.group(bossGroup, workerGroup)；//主線程和工作線程分開

3、單Reactor、多線程subReactor、指定線程池處理業務

https://netty.io/4.1/api/io/netty/channel/ChannelPipeline.html

? ? 我們在一個pipeline中定義多個ChannelHandler，用以接收I / O事件（例如，讀取）和請求I / O操作（例如，寫入和關閉）。例如，典型的服務器在每channel的pipiline中，都有以下Handler：（具體取決于使用的協議和業務邏輯的復雜性和特征）：

• Protocol Decoder - 將二進制數據（例如ByteBuf）轉換為Java對象。

• Protocol Encoder - 將Java對象轉換為二進制數據。

• Business Logic Handler - 執行實際的業務邏輯（例如數據庫訪問）。

如下例所示：

static final EventExecutorGroupgroup = new DefaultEventExecutorGroup（16）;...ChannelPipeline pipeline = ch.pipeline（）;pipeline.addLast（“decoder”，new MyProtocolDecoder（））;pipeline.addLast（“encoder”，new MyProtocolEncoder（））;//告訴這個MyBusinessLogicHandler的事件處理程序方法不在I / O線程中，//以便I?/?O線程不被阻塞，一項耗時的任務運行在自定義線程組（池）//如果您的業務邏輯完全異步或很快完成，則不需要額外指定一個線程組。pipeline.addLast（group，“handler”，new MyBusinessLogicHandler（））;

? ? 前文中提到過，web應用程序接受百萬、千萬的網絡連接，并管理轉化為請求、響應，就像一個大隊列一樣，如何更好的處理隊列里面的任務，牽扯到負載均衡分配、鎖、阻塞、線程池、多進程、轉發、同步異步等一系列負載問題。? 單機及分布式都要優化，netty做了很多優化，這部分netty源碼不好讀懂：

業務處理與IO任務公用線程池 自定義線程池處理業務

如圖所示：netty中, 不固定數量的channel、固定的NioEventLoop、可外置線程池的EventExecutor，在眾多channel不定時的事件驅動下，如何協調線程很是復雜。

留個問題：基于netty的spring webflux 、nodejs，為什么能支撐大量連接，而cpu成為瓶頸？

小節：這樣我們從 客戶端發起請求->到服務端建立連接->服務端非阻塞監聽傳輸->業務處理->響應? 整個流程，通過IO多路復用、線程池、業務線程池 讓整個處理鏈條沒有處理瓶頸、處理短板，達到整體高性能、高吞吐。

? ? 但是耗時處理能力遠遠低于IO連接的管理能力，單機都會達到天花板，繼續拆分（專業中間件干專業事），RPC、微服務調用是解決策略。

---

—?8?—?分布式遠程調用（不是結尾才是開始）

? ? 由前文看出，單機的最終瓶頸會出在業務處理上。對java語言來說，線程數量不可能無限擴大。就算使用go語言更小開銷的協程，cpu也會成為單機瓶頸。所以跨機器的分布式遠程調用肯定是解決問題的方向。業內已經有很多實踐，我們從三個典型架構圖，看看演進解決的問題是什么，靠什么解決的：
注：本文不從soa，rpc，微服務等方面討論，只關注拆分的依據和目標。

A、單體應用

B、把網絡連接管理和靜態內容拆分

C、業務功能性拆分

A:典型單體應用。
A->B：連接管理與業務處理拆分。使用網絡連接管理能力強大的nginx，業務處理單獨拆分為多臺機器。

B->C：業務處理從功能角度拆分。有些業務側重協議解析、有些側重業務判斷、有些側重數據庫操作，繼續拆分。

通過圖C，從高性能角度，看服務分層（各層技術選型也有很多）的準則及需要注意點：

1、反向代理層（關聯https連接）

• 可以通過nginx集群實現，也可以通過lvs,f5實現。

• 通過上層nginx實現，可以知道該層應對的是大量http或https請求。

• 核心指標是：并發連接數、活躍連接數、出入流量、出入包數、吞吐量等。

• 內部關于協議解析模塊、壓縮模塊、包處理模塊優化等。關鍵反向代理出去的請求吞吐量，也就是nginx轉發到后端應用服務器的處理能力，決定整體吞吐量。

• 靜態文件都走cdn。

• 關于https認證比較費時，建議使用http2.0，或保持連接時間長點。但這也與業務情況有關。如：每個app與后端交互是否頻繁。畢竟維護太多連接，成本也很高，影響多路復用性能。

2、網關層(通用無業務的操作)

反向代理層通過http協議連接網關層，二者之間通過內網ip通信，效率高很多。我們假定網關層往下游都使用tcp長連接，java語言中dobbo等rpc框架都可以實現。

網關層主要做幾個事情：

• 鑒權

• 數據包完整性檢查

• http json 傳輸協議轉化為java對象

• 路由轉義（轉化為微服務調用）

• 服務治理相關（限流、降級、熔斷等）功能

• 負載均衡

? ? 網關層可以由：有開源的Zuul，spring cloud gateway，nodejs等實現。nginx也可以做網關需要定制開發，與反向代理層物理上合并。

3、業務邏輯層（業務層面的操作）

? ? 從這層可以考慮按照業務邏輯垂直分層。例如：用戶邏輯層、訂單邏輯層等。如果這樣拆分，可能會抽象一層通過的業務邏輯層。我們盡量保證業務邏輯層不橫向調用，只上游調用下游。

• 業務邏輯判斷

• 業務邏輯處理（組合）

• 分布式事務實現

• 分布式鎖實現

• 業務緩存

4、數據訪問層（數據庫存儲相關的操作）

• 專注數據增刪改查操作。

• orm封裝

• 隱藏分庫分表的細節。

• 緩存設計

• 屏蔽存儲層差異

• 數據存儲冪等實現

注：本節引用了孫玄老師《百萬年薪架構師課程》中一些觀點，推薦一下這門課，從架構實踐、微服務實現、服務治理等方面，從本質到實戰面面俱到。

網關層以下，數據庫以上，RPC中間件技術選型及技術指標如下（來源dubbo官網）：

• 核心指標是：并發量、TQps、Rt響應時間。

• 選擇協議因素：dubbo、rmi、hession、webservice、thrift、memcached、redis、rest

• 連接個數：長連接一般單個；短連接需要多個

• 是否長連接：長短連接

• 傳輸協議：TCP、http

• 傳輸方式：：同步、NIO非阻塞

• 序列化：二進制（hessian）

• 使用范圍：大文件、超大字符串、短字符串等

• 根據應用場景選擇，一般默認dubbo即可。

小節：

單機時代：從每個線程管理一個網絡連接；再到通過io多路復用，單個線程管理網絡連接，騰出資源處理業務；再到io線程池和業務線程池分離；大家能發現個規律，客戶端連接請求是總起點->后端處理能力逐步平衡加強的過程。業務處理能力總是趕不上接受處理的能力。

反向代理時代：nginx能夠管理的連接足夠的多了，后端可以轉發到N臺應用服務器tomcat。從某種程度上，更加有效的利用的資源，通過硬件、軟件選型，把 管理連接（功能）和處理連接（功能）物理上拆分開，軟件和硬件配合處理自己更擅長的事情。

SOA、微服務時代：（SOA的出現其實是為了低耦合，跟高性能高并發關系不大）業務處理有很多種類型。有的是運算密集型；有的需要操作數據庫；有的只需從cache讀一些數據；有些業務使用率很高；有些使用頻度很低。為了更好利用又有了兩種拆分機制。把操作數據庫的服務單獨拆出來（數據訪問層），把業務邏輯處理的拆分出來（業務邏輯層）；按照以上邏輯推斷：可能一臺nginx+3臺tomcat網關+5臺duboo業務邏輯+10臺duboo數據訪問配置合適。? 我們配置的目的是，各層處理的專屬的業務都能把服務器壓到60%資源占用。

注：文章只關注了功能層面的水平分層。而垂直層面也需要分層。例如：用戶管理和訂單管理是兩類不同的業務，業務技術特點、訪問頻次也不同。存儲層面也需要垂直分庫、分表。本文暫且略過。?

單機階段，多線程多進程其實相當于一種垂直并發拆分，盡量保證無狀態，盡量避免鎖等，跟微服務無狀態、分布式鎖原理上是一致的。

---

—?9?—?總結

? ? 回顧前文，客戶端連接到服務器端后都要干什么呢？性能瓶頸是維護這么多連接？還是針對每個連接的處理達不到要求失衡？如何破局？從單機內部、再到物理機器拆分的描述看來，有三點及其重要：

關注平衡：達到平衡的架構，才可能是高性能、高并發架構。任何性能問題都會由某個點引起。甚至泛指業務需求與復雜度也要平衡。

拆分之道：合適的事情，讓合適的技術、合適的中間件解決。具體：如何橫向、縱向拆分還需分析場景。

了解業務場景、問題本質&&了解常用場景下解決方案：按照發現問題、分析問題、解決問題思路來看，我們把彈藥庫備齊，解決問題的過程，就是個匹配的過程。

除了文中提到的技術以及拆分方案，很多技術點，都可以提升吞吐及性能，列舉如下：

• IO多路復用：管理更多的連接

• 線程池技術：挖掘多核cpu的潛力

• zero-copy：減少用戶態和內核態交互次數。如java中transferTo，linux中sendfile系統接口；

• 磁盤順序寫：降低尋址開銷。消息隊列或數據庫日志，都會采用此技術。

• 壓縮更好的協議：網絡傳輸上減少開支，如：自定義或二進制傳輸協議；

• 分區：在存儲系統中，分庫分表都算分區；而微服務中，設計服務無狀態，本身也可以理解為分區。

• 批量傳輸：典型數據庫 batch技術。很多網絡中間件也可以使用，如消息隊列中。

• 索引技術：這里不是特指數據庫的索引技術。而是我們設計切合業務場景的索引，提高效率。例如：kafka針對文件的存儲，采用一些hack的索引技巧。

• 緩存設計：當數據生命修改不頻繁、變更規律性很強、生成一次成本太高時，可以考慮緩存

• 空間換時間：其實分區、索引技術、緩存技術都可歸為這類。例如：我們使用倒排索引存儲數據、使用多份數據多份節點提供服務等。

• 網絡連接的選型：長短連接，可靠、非可靠協議等。

• 拆包粘包：batch、協議選型于此有些關系。

• 高性能分布式鎖：并發編程中，鎖不可避免。盡量使用高性能的分布式鎖，能cas樂觀鎖，盡量避免悲觀鎖。如果業務允許，盡量異步鎖，不要同步阻塞鎖，減少鎖競爭。

• 柔性事務代替剛性事務：有些異常或者故障，試圖通過重試是恢復不了的。

• 最終一致性：如果業務場景允許，盡量保證數據最終一致性。

• 非核心業務異步化：把某些任務轉化為另外一個隊列（消息隊列），消費端可以批量、多消費者處理。

• direct IO：例如數據庫等自己構建緩存機制的應用程序，直接使用directIO，放棄操作系統提供的緩存。

• ... .... 歡迎留言討論補充拍磚

注：脫離業務場景，很多只能是紙上談兵。但不了解手段，遇到場景也會懵逼?？蛻舳苏埱笮纬傻某夑犃?#xff0c;后端如何分而治之、分散逐個擊破，是整體思想。

總結

以上是生活随笔為你收集整理的如何设计真正高性能高并发分布式系统（万字长文）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。