web架構性能優化假象

對於web架構優化我們的最終方向有兩點
1：提高系統的吞吐量
2：提高系統的處理邏輯能力。
大體的流程圖如下
解釋下這個張流程圖
1：netty是維護客戶端連接負責把請求的內容拿到(是不能阻塞的)
2：disouptor是用來堆放netty放過來的請求與把任務向下放（它只要把請求給到邏輯層處理），可以理解成任務。
3：前面兩部都是去堆放大量請求與任務，而第三步的邏輯處理層處理正真的邏輯，第一步到第二步到第三步，都是一個異步的過程，第三步把數據處理好了，存放到一個結果池，然後結果池把數據推給netty，netty然後返回給對應的客戶端。
說下傳統單體架構的理解
1：普通我們的單體架構項目能容納的吞吐量很有限，其實在tomcat中也是有一個連接池，然後不停堆任務然後創建線程執行。這樣的話，每一個請求我們都需要一個線程去執行。這樣至上而下的話，我的線程數量越多cpu壓力越大，不停的切換上下文，這樣很容易達到硬件所能處理的瓶頸，線程數越多棧的佔用量就越大。這樣我們系統能容納喝提供吞吐量並不多傳統項目也是採用的bio。
2：這樣的架構適合用於controller層支撐收集大量請求，service處理具體業務耗時。然後再利用mq把結果返回給controller層。其實並沒讓處理請求耗時變短，只是讓一個單體的controller層，變得能容納更多得請求了。
3：針對單體架構而言可以做到邏輯資源不需要考慮鎖。
4:針對微服務架構可以這樣設計
netty+disouptor （流量層）rpc給到->service（邏輯層）->結果體（可以使用mq）->流量層。這樣改變了以前普通的調用過程。現在變成了一個環形執行鏈，每個部位都是異步的過程。也對cpu與線程用到了極致。
微服務的調用鏈路圖