一、詳解高并發系統的關鍵指標

在設計一個軟件系統的時候，我們需要對系統性能進行整體的評估，下面就是需要我們在日常進行系統評估和調優分析的關鍵指標：

(1) RT(response time)：響應時間，它代表發送請求到響應數據所花費的時間，也可以理解我們web開發領域所謂的接口響應耗時，它反映了系統響應的快慢。

(2) throughput：也就是我們常說的吞吐量，它在不同的領域都有著不同的含義：

• 業務角度：吞吐量可以代表請求數/秒、人/天或者 處理的業務數/小時
• 網絡角度：從網絡角度來看，可直接用字節數/秒

針對廣義上互聯網領域，該指標更多反應的是系統的負載能力，在沒有性能瓶頸時，服務器吞吐量計算公式為：

F= VU(虛擬用戶數) * R(虛擬用戶發出請求數) /T (測試時花費的時間)

• QPS(每秒請求數）：指服務器一秒內處理了多少個請求，主要用于表示讀請求。
• TPS(每秒事務數): 以高并發系統中TPS中所指的事務數包括3個過程：客戶端請求服務端、服務端內部執行業務邏輯、服務端響應結果給客戶端，

這里很多讀者可能對于TPS和QPS的概念有寫混淆，實際上TPS相較于QPS來說更能反應服務點單位時間內的一個完整的原子的事務的處理能力。 例如我們現在有個web頁面，當用戶打開到完全加載查看到頁面內容時，這就可以理解為1個TPS，而這個頁面中所有請求的接口就應該計入QPS中。

• PV（訪問量）: 也就是page view，頁面瀏覽量的意思，用戶每對網站中一個完整的網頁進行一次瀏覽就可以視為PV+1。
• UV（獨立訪客）：unique visitor指代某個網站或者或者鏈接中出現的不同的IP的數量，我們可以把ip地址視為這個訪客的身份證，這意味著某個ip某天無論訪問網站多少次均視為一次，這也意味著UV代表著網站某天有多少獨立訪客進行訪問。

二、數據一體化模式

1. 詳解數據一體化模式

軟件發展初期，大部分軟件應用都以門戶、OA等系統為主，這些系統無論在訪問人數還是系統數據量都是有限的。所以單體服務器就可以輕松解決這些問題。所以此時的軟件架構著重追求的簡單和快速迭代、成本低，所以所有程序和數據庫等部署在一臺服務器上，因為這種架構是將應用和數據庫都存放在一臺服務器上，所以我們一般稱這種部署模式為數據一體化模式：

2. 監控時如何判定當前服務器是否正常

針對業務初期的數據一體化模式，性能瓶頸大概率要依賴與系統服務器指標監測，這里我們針對一個8C16G服務器并獨立部署和一個單體應用和數據庫的場景，給出一個比較合理的指標參考：

• CPU利用率：一般建議高負載情況下不要超70%。
• 負載：單核負載超過0.7就說明有問題，所以負載一般要求卡在5.6(8核*0.7)以內算正常。
• 磁盤利用率：一般來說超過70%時就需要考慮清理一些過期的無用的垃圾數據了。
• 堆內存占用：一般建議堆內存不要分配超過機器的一半，可以適當多一些。
• 內存使用率：結合上述堆內存的配置，一般來說內存使用率不要超過70%超過則說明可能有內存泄漏或者程序吞吐量下降的風險。
• GC次數和時長：這個更多是經驗之談，理論來說full gc不要在也為高峰期出現就行了，而每次垃圾回收時常stw一般不要超過200ms，這樣對用戶來說是無感知的，而minor gc最壞的場景一般要求每分鐘不能超過1次，每次50ms以內比較合理。

關于系統負載情況的評估可以參考這篇文章：Understanding Linux CPU Load - when should you be worried?：https://scoutapm.com/blog/understanding-load-averages

三、應用與數據分離模式

1. 應用與數據分離架構簡介

基于這個架構我們的業務體量有所增加，此時無論是活躍用戶數量還是數據量都有所上升，這時候我們一般都會考慮增加資源，于是我們將應用和數據庫分離。

這樣做的好處是讓軟件和數據庫可以專注于各自維度的優化，即應用是對外提供服務的，更著重追求CPU和內存。而數據庫因為需要堆數據進行存儲和索引等IO操作，更著重的是IO性能以及磁盤轉速，當然對于內存要求也是有的，所以將數據庫從應用服務器中分離將其部署在一臺磁盤空間更大、IO性能更好的服務器上，由此提升應用整體吞吐量：

2. 關于單體應用啟動前系統指標飆升問題

通過數據與應用分離，我們得到了一個更加存粹的應用系統服務器，此時調優工作會更著重于應用，假如應用啟動后前幾分鐘，Load、RT、CPU等飆高，如何定位，可能的原因是什么？

注意問題所強調的啟動后的幾分鐘，說明這些問題大部分是發生在啟動前，一般來說服務啟動可能存在如下問題：

• 灰度發布
• 資源初始化預熱

針對問題1，這是分布式場景的問題，我們簡單說明一下，假如我們日常100臺服務器剛好承載業務流量，灰度發布是批次升級，這期間就可能存在不到100臺服務承載100臺服務器的流量，在灰度升級期間就可能存在上述指標飆高的情況。

這對問題2，就是我們的單體架構的場景了，我們的服務啟動前都需要連接池、線程池、緩存預熱的預熱等工作，針對這種情況我們可以用例如arthas等工具進行定位排查，確保這些工作完成后再將服務暴露出去。

除了上述情況，還有可能和java語言本身的JIT機制優化，在服務初始化時，大部分代碼執行過程都是通過解釋后在運行的，只有在運行一段時間成為熱點代碼后才會生成機器碼緩存，由此提升程序運行效率，針對該問題解決思路也有很多，例如：

• 提前在業務上運行這段代碼進行預熱。
• 使用JwarmUp技術保證上一次啟動后的信息存儲到文件中，確保下次啟動時通過讀取該文件提前完成JIT優化。

四、緩存與性能的提升

業務體量還在增加，特定場景下某些數據是被用戶頻繁查詢的熱點數據，在之前的架構下，獲取這些信息的方式都是通過數據庫查詢獲取，因此數據庫在這個節點很可能稱為系統的瓶頸。所以我們就考慮引入一個緩存中間件，針對熱點數據或是通過預加載或是數據庫查詢后緩存的方式存放到內存中，從而提升熱點數據的查詢性能。

需要了解的是，一般情況下，緩存中間件可以和應用程序放在一起，但還是本著獨立自治且合理利用資源的原則，我們一般建議將緩存也專門部署到一臺服務器上，讓其享有較大的內存空間以加載更多的數據：

有了緩存中間件之后，我們除了可以在服務啟動時提前加載熱點數據，對于某些不可提前預知的數據，我們可以通過如下步驟完成：

• 查看redis是否有熱點數據，如果有則直接返回，如果沒有則進入步驟2。
• 數據庫查詢，如果有則加載至緩存中，并將結果返回。

因為緩存數據位于內存，相較于數據庫那種需要通過磁盤IO(大部分情況下，其實數據也有buffer pool)響應速度會更快一些。 但是隨之而來的就是可用性和一致性等問題，例如：

• 緩存中間掛了怎么辦？
• 緩存服務器宕機怎么辦？
• 如何解決數據庫和緩存中間件數據一致性問題。

這些筆者都會在后續系列文章中補充說明。

五、分布式負載均衡

1. 分布式負載均衡架構模式

引入緩存中間件進一步提升了系統吞吐量，這時候就要考慮高并發請求性能瓶頸了，隨著業務發展用戶的請求量也會不斷的提升，這也就是我們常說的高并發問題了，

此時我們的應用只單臺服務器上，盡管各種通過各種參數調優和程序優化提升系統整體吞吐量，但畢竟應用是依賴于系統服務器的，最終都會在一個閾值上進入瓶頸而無法進一步優化，所以我們還是采用水平拓展的方式構成服務器集群，即通過更多的服務器承載單位時間內的并發請求，從而提升系統整體的吞吐量。

如下圖可以看到，本次架構本質上是通過橫向拓展的方式讓負載均衡器通過負載均衡算法將請求分散到不同的應用服務器上，借著負載均衡器，我們還可以針對系統整體做流控、鑒權、反向代理等統一請求管理，保證系統整體安全和穩定：

2. 系統的QPS與服務器數量評估

針對分布式負載均衡，進行橫向拓展時我們必須結合業務場景獲得一個比較準確的估值進行服務器部署，假設每日有500w的請求，按照業界的二八原則即80%的流量都發生在20%的時間段，對此我們的推算系統QPS的步驟為：

一天24小時，而流量基本都發生在白天，所以我們實際要關注的時間段應該是12h。 對應20%的時間段即指代12*0.2即某個時間段的2h承載80%的流量，所以我們可以得到如下的計算：

(流量*80%)/(高峰時間段小時)/(每小時有多少秒)
(500_0000 * 0.8) / (12 * 0.2)/(60 * 60) ≈ 460

由此我們可以推算出系統日常情況下是QPS為460，為預防突發流量，所以峰值應該是平均高峰值的2~3倍數，所以我們認為當前場景下QPS最高應該是1500左右。 假設單臺機器可承受的QPS為300，換算一下1500/300，我們大約需要5臺左右的服務器，然后基于這個基準的值提前設置一下限流、熔斷策略，由此高性能和高可用。

3. 服務器選型

有了上述的服務器配算方案之后，我們就需要針對性選擇何時的服務器，假設我們有4C8G *16臺 和 8C16G*8臺，我們該選擇那種方案呢？

兩者服務器各有各的優勢，對此我們可以從以下幾個角度考慮問題：

• 單機瓶頸：這一點很明顯后者表現更加出色，假如遇到某些功能場景需要更多的核心數和內存，前者則會力不從心。
• 容錯：前者機器更多，及時單臺機器出現故障，對于系統的整體影響面相較于后者會小些。
• 負載均衡：因為前者有著更多的機器，所以對于負載均衡這種橫向拓展問題發揮的空間會更大一些。
• 連接數：MySQL分配給單機的連接數是固定的，且大公司企業都不允許調整連接數，這也就意味著有著更多的機器總的連接數也就越多。
• GC效率：從垃圾回收器來說掃描垃圾的開銷遠小于回收垃圾的開銷，單機有著更大的內存空間減少垃圾回收次數自然是更好的做法。

總體來說，4C8G *16臺更符合現代微服務的理念，服務器更加輕量級，通過堆疊更多的服務器分散壓力，對于并發處理能力、容錯能力、負載均衡、連接數等方面更加友好，但還是需要考慮單機性能瓶頸和GC次數和擴容效率帶來的影響。

4. 分布式架構一定比單體架構要好

單體架構也就是我們上說數據一體化模式及其進階版本，一般發生在企業創業初期，為了快速進入市場時所誕生的系統，它要求系統越簡單越好，搭建過程也是越快越好，一般來說單體架構標配為：

• 一個應用程序
• 一個數據
• 一個文件服務器

它的優點如下：

• 開發、測試、部署成本都非常低，只需針對一個項目開展，基本上可以做到前腳修改吼叫直接打包部署上線。
• 單體程序網絡基本都是數據庫、redis等，不需要通過RPC與其他服務做交互，大大降低網絡延遲。
• 因為業務邏輯全部打包在單體上，不需考慮分布式鎖、分布式事務、分布式id問題，只需專注解決單機并發問題即可。

由此缺點也很明顯：

• 單體架構在業務量增加后容易導致性能瓶頸。
• 單體架構所有業務都耦合在一個程序上，隨著業務演進，多人協作開發時代碼耦合度非常高，測試回歸成本也會急劇增加，隨著時間推移可能導致開發節奏混亂、業務邊界不清晰、分支合并各種沖突導致各種潛在的風險。
• 單點故障會導致業務全癱。
• 這也是最為嚴重的一點，單體架構隨著業務的拓展，按照用戶展示層、業務邏輯層、數據訪問層這種模式進行分層邏輯，在業務不斷迭代之后，系統調用會構成下圖所示的網狀結構，在水平方向上來看確實比較精簡，但是從垂直的角度來看，各層之間相互錯中復雜的調用，導致各層都會存在依賴一個或者多個模塊的情況，這對于后續的功能復用、維護、甚至是不同模塊間的技術棧升級都是異常困難的。

而分布式架構對應的優點有：

• 不同服務分布在不同的服務器上，橫向拓展方便，將一個復雜的問題拆解到不同的服務上，業務邊界更加清晰，降低團隊的協作成本。
• 可以靈活結合業務場景進行服務拆分、堆加服務器，快速拓展以抗住高并發流量。
• 模塊化開發，易于功能拓展和維護。
• 單點故障問題相較于單體架構來說會相對少一些。

對應缺點：

• 運維成本高，分布式場景我們需要針對多個服務進行部署、監控、日志、故障恢復，增加系統的復雜度，且對于分布式場景風險眾多，需要考慮的問題場景相較于前者更多，對于運維、開發要求會更高。
• 故障定位，分布式架構相較于前者更復雜，一個請求需要經過很多個服務，出現問題時的排查成本相較于單體架構來說會更高，由此還得借助分布式鏈路追蹤。
• 服務邊界拆分維度也很困難，拆分粒度小了對于多服務運維和監控成本會增加，拆分粒度過粗又會導致服務后期變為一個臃腫的單體。
• 分布式一致性問題，臨界資源考慮的維度都是面向分布式場景，這其中就會面臨分布式事務和分布式鎖一致性問題。

所以對于開發周期短、業務量小、追求快速上線優先考慮使用單體架構，只有業務增長，需要考慮高并發和高可用的場景才需要考慮分布式和微服務這些。

六、讀寫分離

我們通過緩存中間件解決了熱點數據問題，但是緩存中間件的容量畢竟是有限的，對于非熱點數據我們還是需要通過數據庫進行統一維護管理為了避免數據庫寫操作(update、insert、delete)阻塞其他事務讀操作(select)，因為現代主流系統架構基本都是讀多寫少的，所以我們更傾向于引入讀寫分離的方案，即讓所有寫操作都都面向master服務器，而讀操作都通過slave服務器完成，slave通過訂閱master庫的bin.log進行數據實時同步操作。

在此基礎上我們針對表進行優化設計，減小應用請求進行寫操作時上X鎖的粒度，保證寫操作的吞吐量，與此同時因為讀操作上的都是S鎖，而S鎖之間都是彼此兼容，由此通過讀寫分離加S鎖兼容性，更進一步提升系統整體吞吐量。

七、引入CDN緩存

實際上，我們進行web網站瀏覽時，大部分都是基本不變的靜態數據例如：JS腳本、HTML、圖片文件等，考慮到訪問的用戶位于不同的城市，在針對這些系統資源加載的時可能會經過好幾個網絡路由轉發才能完成資源下載，所以我們提出CDN技術即資源分發網絡（Content Delivery Network），而CDN的大體工作流程是：

• 用戶通過域名針對網站發起資源請求，首先向LDNS(本地DNS)進行域名請求。
• DNS解析域名得到對應的CNAME對應的IP地址，從而定位到對應的服務商的服務器。
• 重點來了，服務提供商通過DNS調取系統返回給用戶最佳IP地址。
• 查看該服務器是否有請求的靜態資源，如果沒有則緩存并返回，若有則直接返回。

可以看到，通過CDN減輕了應用服務器的壓力，大大提升的web頁面的響應速度，保證了可用性和高性能：

八、分庫分表

1. 詳解分庫分表理論思路

經過上述幾輪的架構演進，軟件的系統架構已經趨于穩定，隨著時間的推移數據庫中的數據體量也會隨之逐步增加，即使通過讀寫分離單表數據體量已無法保證大表的快速檢索，同時也考慮到并發請求的體量也在逐步增加每個數據庫所能承受的最大連接數也已經無法滿足現有的業務需求，所以我們又不得不考慮更進一輪的水平拓展。即分庫分表方案將大表拆小，增加幾臺數據庫服務器來分攤這些數據管理。

因為數據庫分散部署，所以在進行分庫分表設計時我們還需要結合一定的算法保證數據維護和檢索的開銷，為此我們可能還需要引入分庫分表中間件來管理應用程序的數據庫訪問工作：

2. 如果單表數據量大，只能考慮分庫分表嗎

分庫分表是綜合解決并發和數據檢索效率的綜合方案，但是分庫分表后會帶來問題：

• 跨庫表分頁
• 分布式事務
• 非分片鍵值的數據查詢
• 跨庫表join關聯查詢

針對單表數據量大，我們可以從以下幾個維度進行排查和按需設計：

• 并發量不是很大的場景下，針對單表做好設計，建立何時的索引并采取相對簡單的輕量級分區設計保證查詢檢索效率即可。

• 單表數據量大，但是特定業務下這張表每日只有一些相對局限的熱點數據查詢請求，針對這些請求條件建立好表索引，然后借助緩存中間件來存儲這些熱點數據。

• 如果需要保證高并發和高吞吐量，我們則需要借助分庫分表來分散并發量和單表體量提升檢索性能。

九、分布式架構

1. 詳解分布式結構模式

此時我們就已經具備了一個性能性能較為出色的分布式系統架構，但是我們所有的業務都耦合在一個應用程序上，無法針對單個原子業務進行管理和優化，甚至說在高并發場景下，一些訪問量和體量都比較小的業務會因為一些熱點業務導致整體癱瘓，無法對外提供服務。

于是我們會嘗試通過圈表并結合實際業務場景針對性的進行業務拆分，將不同的業務部署到不同的服務器上，因為這些應用之間還是存在的關聯，相互之間還會存在著調用關系，所以我們還會考慮引入注冊中心、配置中心、消息隊列等中間件協調應用之間的通信：

2. 分布式業務架構流量突增問題

分布式系統架構下勢必存在的訪問量暴增的特點，假設QPS突增100倍你會怎么處理？一般來說在上文中我們已經針對系統可承受的范圍內做了評估并預設了指定數量服務器來承載這些流量，對于突增的流量大部分情況下都可以拒絕掉，以保證部分用戶可用以及保證系統能夠維穩運行。

對此該問題，一般出現業務流量突增我們必須考慮以下兩種情況：

• 異常情況：服務被ddos攻擊了。
• 正常情況：引流或者某些原因導致業務量暴增。

針對第一種情況，我們必須采取相應防護手段處理，例如：

• 識別攻擊源。在防火墻服務器調整ACL(訪問控制列表)阻斷這些攻擊源。
• nginx進行限流
• 適當增加服務器通過負載均衡分擔流量。
• 針對帶寬消耗型的攻擊，增加帶寬適當緩解問題。
• 路由器或防火墻啟用一些反IP欺騙的功能，保證對所有IP源可見。
• 增加對該服務的網絡和web流量監控，時刻觀察變化。

針對正常的業務場景則考慮從高并發系統角度進行不斷拓展優化了，大抵可以從以下幾個角度考慮：

• 分布式：通過將服務拆分到不同的服務上構成分布式架構，分散管理不同業務的流量壓力，進行針對性的優化，同時還能避免單功能導致服務宕機的影響面，也能提升系統的可伸縮性。
• 集群部署：通過集群部署分散單業務服務請求的流量，結合負載均衡技術提升服務的吞吐量和響應速度，提升系統性能和可用性。
• 緩存：對于熱點數據提前緩存，提高程序讀寫性能和可靠性。
• 異步處理：采用異步處理機制，例如消息隊列、事件等系統，減少響應耗時、提升系統吞吐量。
• 資源預熱：將系統常見流量數據提前加載預熱，減少請求的等待時間。
• 程序優化：針對每個功能代碼進行功能優化，例如：異步IO、檢索鎖粒度提升并發性能、減少循環遞歸，減少事務的粒度等。
• 數據庫優化：合理設計數據表索引、字段，以及對于一些需要join查詢，我們可以結合場景進行冗余。
• 讀寫分離：大部分場景都是讀多寫少，所以我們的數據庫一般建議采用讀寫分離的方式，將寫請求打到主庫，讀取請求分散到讀服務器上，提升程序并發度和可擴展性，同時即時主庫出現故障，從庫依然可以提供服務。
• 分庫分表：為避免慢查詢SQL和大量讀請求，我們建議采用分庫分表分散垂直和水平拆分分散請求流量和單表性能瓶頸。
• 通過使用限流、熔斷、降級等技術，防止某個組件故障導致系統崩潰的雪崩效用。
• 監控：針對各種可能存在的風險點，通過監控建議監控觀察，以保證能夠及時針對做出調整和觀察。

3. 關于服務限流的探討

為什么針對流量需要進行特定的服務限流，增加服務器承載更多的流量不是更好嗎？

原則上服務優先，針對這個問題要從以下兩個角度考慮：

• 服務好客戶沒有錯，但是我們要知曉客戶是否是正常客戶，請求突增的原因不一定是業務量上漲，也可能是被攻擊了。
• 突發流量：出問題一般是由于突發流量，例如我們系統最高qps為1000，但是突發流量是遠遠高于這個數的，如果沒有提前預測不做限流，服務可能直接被打卦了。

限流本質要做的就是自我保護，是系統的最后一道防線，只有通過限流保證服務器正常，然后在針對性排查流量來源，針對性擴容。

十、分布式微服務

1. 詳解分布式微服務架構特點

很多讀者對于分布式和微服務兩個概念會有所混淆，實際上微服務相較于分布式架構做了更精細的切割，通過拆分成精細的子模塊保證模塊之間的高內聚低耦合，讓每個模塊獨立存在并拆解到不同團隊進行專門的維護，各個模塊按照自己協定開發進行開發，公開各自的協議實現和標準，某些熱點模塊也可以類似于分布式架構一樣進行水平拓展，保證高性能和高可用。

在部署架構上，因為微服務拆分原則是分布式架構有所不同，它拆分的目的還包含模塊間的解耦和團隊自治維護，所以進行模塊部署的時候，多個模塊以容器化的方式部署在單臺服務器，也可以多個模塊部署上不同服務器上，相較于分布式架構有著更加靈活的搭配和管理。

總的來說微服務架構相較于分布式架構有著更精細的拆分、有著更獨立的自治性和服務異構性等特點：

2. 服務拆分后的接口機器預估

微服務架構通過更細粒度的拆分，使之業務維度有著更細粒度的解耦，所以對于特定服務的優化，我們甚至可以是針對到更細粒度的核心接口上，例如我們現在有一個查詢接口，按照評估它大約是有5000QPS，經過優化后接口RT為大約是200ms，此時如果我們需要針對該模塊進行水平拓展，請問需要增加幾臺服務器？

基于上述指標，我們首先需要針對單機性能進行大體的預估，首先接口響應實踐大約是200ms，按照單臺服務器單線程維護來看，每個線程在1s內可以處理5個請求：

完成線程處理能力大體評估之后，我們就需要從處理的維度進行更進一步的評估，假設這個接口CPU處理時間為2ms，而IO等待耗時為150ms，其余時間作為網絡讀寫的耗時(讀寫redis數據等)，這也就意味著一個線程在單位時間內只占用CPU大約10ms，也就是說單個CPU大約可以處理100個線程，也就是每個核心在理想情況下，每秒可以處理500個請求。

我們繼續，默認情況下tomcat分配的線程是200，按照當前CPU處理能力每秒可以處理100個線程，所以2個核心即可在單位時間內處理掉這些線程，CPU使用率也不算很高，這個評估是合理的。 所以單機性能的核心計算還是回到了線程上，一共200個線程，每個處理5個請求，所以單機處理能力為1000QPS。

當然如果我們允許更高的CPU使用率，就可以開始使用更多的線程更高的QPS。

所以在理想情況下3000qps只需要3臺服務器即可，但是我們的理論指標是基于所有理想情況，并沒有考慮到應用GC情況、網絡組件通信效率等綜合考量做增減。

3. 微服務界面長耗時問題

通過微服務拆解，我們得到了更加靈活組合式實現高性能、高吞吐、高可用的軟件架構，假設線上出現用戶進入緩慢，監控服務器cpu和緩存沒有什么壓力，可以從哪些方面排查？

針對線上服務器多節點分布，但是在cpu和緩存沒有任何壓力瓶頸的情況下出現訪問速度緩慢，我們大體可以從以下幾個角度考慮：

• 明確是否是用戶端瀏覽器、網絡問題。
• 檢查服務器網絡帶寬等，明確是否存在網絡延遲丟包或者帶寬限制。
• 是否使用CDN，也有可能是CDN某個節點有問題導致用戶資源加載慢。
• 檢查復雜均衡是否正確，用戶請求是否打到有問題的節點上。
• 查看期間是否存在進行耗時的GC。
• 查看應用此時是否存在耗時的IO操作。