世間可稱之為天經地義的事情沒幾樣，複雜的互聯網架構也是如此，萬丈高樓平地起，架構都是演變而來，那麼演變的本質是什麼？”
— 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下，跟文件句柄描述項有關，可以ulimit -n查看，也可修改。其它就是跟硬件資源cpu、內存、網絡帶寬有關。單機可以做到數十萬級的併發連接數，如何實現呢？後面IO模型時講解。
2、流量相關
主要是網絡帶寬的配置。
- 流入流量：從外部訪問服務器所消耗的流量。
- 流出流量：服務器對外響應的流量。
3、數據包數
數據包是TCP三次握手建立連接後，傳輸的內容封裝
- 流入數據包數：服務器每秒接到的請求數據包數量。
- 流出數據包數：服務器每秒發出的數據包數量。
關於TCP/IP包的細節請查閱相關文檔。但是有一點一定注意，我們單次請求可能會分成多個包發送，拆包、粘包問題網絡中間件都會為我們處理 （比如消息補齊、回車結尾、自定義消息頭體、自定義協議等解決方案） 。如果我們傳遞的用戶數據較小，那麼效率肯定會提升。反過來無限制的壓縮傳輸包的大小，解壓也會耗費cpu資源，需平衡處理。
4、應用傳輸協議
傳輸協議壓縮率好，傳輸性能好，對併發性能提升高。但是也需要看調用雙方的語言可以使用協議才行。可以自己定義，也可以使用成熟的傳輸協議。比如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模式，做了哪些細節調整。
注：實際實現肯定與圖差別很大。客戶端io及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線程池通信的，通過待處理請求隊列 。客戶端對服務器的請求，本來可以想象成一個請求隊列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（sub R eactor進程）進程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、hesssion、webservice、thrift、memached、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，放棄操作系統提供的緩存。
- ... .... 歡迎留言討論補充拍磚
注：脫離業務場景，很多隻能是紙上談兵。但不瞭解手段，遇到場景也會懵逼。 客戶端請求形成的超級隊列，後端如何分而治之、分散逐個擊破，是整體思想。
閱讀更多 努力的程序員 的文章
