顧名思義，高并發就是在指定時間內，系統同時能夠處理大量的請求(連接數)。

那么如何衡量高并發呢?

高并發衡量指標

• 響應時間：系統對請求做出響應的時間，即一個http請求返回所用的時間;
• 吞吐量：單位時間內處理的請求數量;
• QPS(TPS)：每秒可以處理的請求數或事務數;
• 并發用戶數：同時承載正常使用系統功能的用戶數量，即多少人同時使用，系統還能正常運行的用戶數量;

根據上面衡量指標可以看到，提高并發能力必須解決如下幾個問題：

1. 如何提高并發連接數?
2. 那么多的連接數怎么進行業務處理?
3. 應用服務器的處理水平又該怎么提高?
4. 如何使用微服務架構提升高并發邏輯?

別著急，這么多問題我們一個一個來分析解決!

1)、如何提高并發連接數?

如下圖所示，常規的單一網絡連接模型只能1個連接對應1個線程，壓力都集中在內存，導致內存開銷非常大，肯定支撐的連接數有限!(直接掛掉)

單一網絡連接模型

有道是業務寫的再好不如一臺高性能服務器，這個鍋不一定要開發人員背的哦!!!服務器的連接入口就那么大(比如tomcat只有幾千的連接數)，那么處理的能力也只局限于幾千。

怎么解決呢?選用合適的網絡IO模型或者selector，通過使用一個線程輪詢或者事件觸發的方式，能支持幾萬甚至更多的連接數，再配合上nginx做負載就更完美了。

2)那么多的連接數怎么進行業務處理?

大家都知道nginx只是具有反向代理和負載均衡的功能，并不能處理具體的業務邏輯，不能擔當應用服務器來使用。例如webSphere 、tomcat和jetty等，但是我們可以利用nginx將接受到的大量連接通過均衡的方式(輪詢，權重，hash)分配到不同的應用服務器中進行業務處理!

nginx負載

3)應用服務器的處理水平又該怎么提高?

要提高應用服務器的處理水平就要了解自己的應用服務器的瓶頸在哪里，一般有兩個：

數據庫壓力：數據庫是支撐產品業務的核心模塊，系統的高并發的主要壓力也是來源于數據庫。處理方式有如下這些：

數據庫本身：建立有效索引、讀寫分離、雙主互備、分庫分表(sharding-jdbc等實現)等策略，提高數據庫處理能力，減少壓力!

結合內存數據庫：例如redid、memcached等，根據業務需要緩存一些數據字典、枚舉變量和頻繁使用數據等減少數據庫訪問次數，提升數據庫處理能力。

web集群架構圖

如上圖web集群架構圖所示：

• 用nginx負載多臺應用服務器;
• 使用redid/memcached做業務緩存;
• 再加上數據庫集群;

組成了經典的web高并發集群架構。

• 代碼中的業務邏輯：
• 大家可以 參考阿里巴巴java開發手冊 中的開發規范來做就好了，總代來說少創建線程、少創建對象、少加鎖、防止死鎖、少創建線程、注意內存回收等策略，來提升代碼性能。
• 開發中可以采用前后端分離的架構模式，動靜分離、松耦合等提升前后端處理能力。

4)如何使用微服務架構提升高并發邏輯?

先看一下非?；鸬倪@張微服務架構圖：

微服務架構圖

主要包含11大核心組件，分別是：

核心支撐組件

• 服務網關Zuul
• 服務注冊發現Eureka+Ribbon
• 服務配置中心Apollo
• 認證授權中心Spring Security OAuth
• 服務框架Spring MVC/Boot
• 監控反饋組件

數據總線Kafka

• 日志監控ELK
• 調用鏈監控CAT
• Metrics監控KairosDB
• 健康檢查和告警ZMon
• 限流熔斷和流聚合Hystrix/Turbine

總結

出來上述幾點解決高并發服務器邏輯處理瓶頸外，還要考慮網絡因素，例如采用CDN加速，將不同地點的請求分發到不同的服務集群上，避免網絡對速度的影響!

總之，根據自身實際業務在合理范圍內盡可能的拆分，拆分以后同類服務可以通過水平擴展達到整體的高性能高并發，同時將越脆弱的資源放置在鏈路的越末端，訪問的時候盡量將訪問鏈接縮短，降低每次訪問的資源消耗。服務之間直接restful模型使用http調用，或者redis，kafka類的消息中間件通信。單個服務直接使用nginx做負載集群，同時前后端分離，數據庫分庫分表等一整套分布式服務系統!

前后端分離前后端分離