https://mp.weixin.qq.com/s/GHHHvgURdZpNJ1Ec6RHgPg
高並發衡量指標
響應時間：系統對請求做出響應的時間，即一個http請求返回所用的時間；
吞吐量：單位時間內處理的請求數量；
QPS（TPS）：每秒可以處理的請求數或事務數；
並發用戶數：同時承載正常使用系統功能的用戶數量，即多少人同時使用，系統還能正常運行的用戶數量；
根據上面衡量指標可以看到，提高並發能力必須解決如下幾個問題：
-
如何提高並發連接數？
-
那么多的連接數怎么進行業務處理？
-
應用服務器的處理水平又該怎么提高？
-
如何使用微服務架構提升高並發邏輯？
1）、如何提高並發連接數？
如下圖所示，常規的單一網絡連接模型只能1個連接對應1個線程，壓力都集中在內存，導致內存開銷非常大，肯定支撐的連接數有限！（直接掛掉）
單一網絡連接模型
選用合適的網絡IO模型或者selector，通過使用一個線程輪詢或者事件觸發的方式，能支持幾萬甚至更多的連接數，再配合上nginx做負載就更完美了。
那么多的連接數怎么進行業務處理？
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做負載集群，同時前后端分離，數據庫分庫分表等一整套分布式服務系統！
