高並發系統架構常用案例
通用場景
日用戶流量大，但是比較分散，偶爾會有用戶高聚的情況；
解決思路
通過服務器架構和代碼分流，系統架構設計保證它能夠同時並行處理很多請求
場景特征
高並發相關常用的一些指標有響應時間（Response Time），吞吐量（Throughput），每秒查詢率 QPS（Query Per Second）,每秒事務處理量(TPS),並發用戶數等
測試模擬工具
1. Apache Jmeter
2.Visual Studio性能負載測試
3.Microsoft Web Application Stress Tool
分布式
1. 分布式應用和服務,將分層或者分割后的業務分布式部署，獨立的應用服務器，數據庫，緩存服務器
2. 當業務達到一定用戶量的時候，再進行服務器均衡負載，數據庫，緩存主從集群
3. 分布式靜態資源，比如：靜態資源上傳cdn
4. 分布式計算，比如：使用hadoop進行大數據的分布式計算
5. 分布式數據和存儲,比如：各分布節點根據哈希算法或其他算法分散存儲數據。
緩存
分析:高並發業務接口多數都是進行業務數據的查詢，如：商品列表，商品信息，用戶信息，紅包信息等，這些數據都是不會經常變化，並且持久化在數據庫中. 高並發的情況下直接連接從庫做查詢操作，多台從庫服務器也抗不住這么大量的連接請求數（前面說過，單台數據庫服務器允許的最大連接數量是有限的）。 結論:緩存將是一個不錯的選擇。浪費內存。
異步
分析:在高並發業務中如果涉及到數據庫操作，主要壓力都是在數據庫服務器上面，雖然使用主從分離，但是數據庫操作都是在主庫上操作，單台數據庫服務器連接池允許的最大連接數量是有限的 。當連接數量達到最大值的時候，其他需要連接數據操作的請求就需要等待有空閑的連接，這樣高並發的時候很多請求就會出現connection time out 的情況 。 結論:異步將是一個不錯的選擇
分層/隔
1.分層，將系統在橫向維度上切分成幾個部分，每個部門負責一部分相對簡單並比較單一的職責，然后通過上層對下層的依賴和調度組成一個完整的系統.
2.分隔，在縱向方面對業務進行切分，將一塊相對復雜的業務分割成不同的模塊單元.
3.包裝成高內聚低耦合的模塊不僅有助於軟件的開發維護，也便於不同模塊的分布式部署，提高網站的並發處理能力和功能擴展. 比如用戶中心可以分割成：賬戶信息模塊，訂單模塊，充值模塊，提現模塊，優惠券模塊等。
面向服務
使用服務化思維，將核心業務或者通用的業務功能抽離成服務獨立部署，對外提供接口的方式提供功能
- SOA--面向服務架構設計
- 微服務更細粒度服務化，一系列的獨立的服務共同組成系統
集群
分析:對於用戶訪問集中的業務獨立部署服務器，應用服務器，數據庫，nosql數據庫。通過負載均衡設備共同對外提供服務， 服務器集群能夠為相同的服務提供更多的並發支持
應用服務器集群
- nginx 反向代理
- Slb負載均衡
數據庫集群
- 主從分離，從庫集群
高可用系統架構常用案例
可用性是什么
- 保密性（Confidentiality）
- 完整性（Intergrity）
- 可用性（Availablility）
高可用的目的
對於大型網站來說，網站可用性越高越好。 可用性量化指標：系統能正常運行的時間占總時間的百分比。99%的可用性就表示系統保證在99%的時間內正常服務。
如：通常99.99%四個九稱為高可用，載人航天中，這一標准是99.9999%。
高可用的實現方式
互聯網架構的高可用設計可以從物理層、服務層、測試層三個方面去考慮
高可用--物理層
1. 服務器故障轉移
對於業務邏輯服務，一般會設計成無狀態化的服務，無狀態化也就是服務模塊只處理業務邏輯，而無需關心業務請求的上下文信息。所以無狀態化的服務器之間是相互平等和獨立的。
故障轉移就是在某一個應用服務器不能服務用戶請求的時候，通過一定的技術實現用戶請求轉移到其他應用服務器上來進行業務邏輯處理
同時有三台服務器組成一個集群來對外提供服務，三台服務器之間是相互備份的關系，只是三台服務器是在同一機房。
2. 服務器冗余備份
為了達到更高的可用性，我們還可以考慮通過多機房的冗余備份，如左圖所示。正常情況下，負載均衡器將請求都分發到機房1的服務器上去，在機房1處理故障，或者處理性能比較高時，負載均衡器可以將請求切換到機房2上來，從而達到機房之間的容災備份。
冗余備份可以達到避免單點，系統容量備份，多方式容災等目的。
高可用--服務層
1.超時設置
一般網站服務都會有主調服務和被調服務之分。超時設置就是主調服務在調用被調服務的時候設置一個超時等待時間Timeout，主調服務發現超時后，主動進入超時處理流程。
例如：主調服務A調用被調服務B時，設置超時等待時間為3秒，可能由於B服務宕機、網絡情況不好或程序BUG而導致B服務不能及時回復A服務的調用，此時A服務在等待3秒后，將觸發超時邏輯而不再關心B服務的回復情況。A服務的超時邏輯可以依據情況而定，比如可以采取重試，或到另一個對等的B服務去請求，或直接放棄直接對外進行回包。
超時設置的好處在於當某個服務不可用時，不至於整個系統發生連鎖反應。快速失敗。
2.異步調用
采用異步調用的方式調用被調服務，有利於將主調服務和被調服務進行解耦，同時提高系統的處理性能。
例如：當你在微信發布朋友圈時，微信APP的后台服務器需要把文字和圖片存儲到不同的服務模塊上去，這時后台服務收到請求后，將兩種不同的數據以異步調用的方式分發到不同的功能模塊，這樣的后台服務處理會更高效，同時即使圖片存儲模塊響應時間長也不會影響到文字存儲過程。
3.服務降級
在一個大系統中，一般會有核心服務和次要服務之分，那么對於不同的服務可以采用不同的處理方案，出現故障時應該優先保證核心服務的運行。
4.監控警告
大型網站系統的服務模塊眾多，經常會因為各種原因出現進程core掉，網絡質量不好，機器宕機等現象，我們設計的系統應該具備監控上報和告警的能力，運維和開發能夠通過監控報表實時的查看系統的運行狀態。服務一旦出現問題能夠及時發現，通過自動化處理，或者人工介入處理，從而達到縮短系統的不可用時間，提高可用性。
常見的監控指標有：CPU、帶寬、內存使用率、網絡連接狀態，系統調用錯誤，成功率，PV，UV等。
5.防雪崩機制
對於設計的任何一個系統，都需要進行容量的預估和最大容量設置，當外部請求量超過最大容量時，應該啟動防雪崩機制，以避免大量外部請求把服務壓跨而不能對外提供服務。
例如A服務的最大QPS是5W/S，那么當外部請求達到5W/S時，A服務只服務5W/S的QPS，超過的部分直接拒絕服務，而不是強吞下導致A服務完全不可用。
6.流量緩沖機制
在服務內可以建立隊列，當流量過大時，儲存一定的用戶請求到隊列，當流量偏小時再拿出來快速處理，從而達到削峰填谷的作用。在請求數據庫時，這個方案使用得很多，避免寫入高峰時壓跨數據庫。
高可用—測試層
1.自動化測試
對於每一次代碼的提交，都能通過自動測試程序對整個服務進行整體的回歸測試，這樣可以快速地避免代碼修改引入新的問題，而導致服務不穩定
2.灰度發布和回滾機制
對於網站系統要發布的服務，可以采用灰度發布的方式來進行發布。所謂灰度發布就是先在生產環境中選取一小部分機器進行發布，然后再測試驗證，驗證成功后再繼續加大發布范圍。如果遇到發布的版本存在重大BUG需要能快速的啟動服務回滾機制，迅速恢復到發布前的穩定版本
3.版本控制
對於大型系統來說，一般會有多個團隊或者工程師同時進行開發。需要對相同的代碼庫進行版本管理和發布管理。目前大部分開發團隊都采用SVN和Git等工具來進行代碼管理和發布。
如：GitLab/GitEE/GitHub
高並發—分布式架構（橫向分層）
什么是分布式架構：簡單的說，“分工協作，專人做專事”。
分布式架構怎么實現高可用：軟件系統架構分層冗余。
高並發—CQRS架構(分隔)
架構分隔的好處：簡單的說，“分工協作，以時間換空間”。讀寫分離/削峰，為了高可用而生
分布式架構怎么實現高並發：軟件系統架構通過異步或緩存削弱並發波峰。
高並發—異步架構(分隔)
設計考慮
- 逆向思維，壓力在數據庫，那業務接口就不進行數據庫操作不就沒壓力了
- 數據持久化是否允許延遲？
- 如何讓業務接口不直接操作DB，又可以讓數據持久化？
方案設計
- 像這種涉及數據庫操作的高並發的業務，就要考慮使用異步了：客戶端發起接口請求，服務端快速響應，客戶端展示結果給用戶，數據庫操作通過異步同步
- 如何實現異步同步：使用消息隊列，將入庫的內容enqueue到消息隊列中，業務接口快速響應給用戶結果(可以溫馨提示高峰期延遲到賬) 然后再寫個獨立程序從消息隊列dequeue數據出來進行入庫操作，入庫成功后刷新用戶相關緩存，如果入庫失敗記錄日志，方便反饋查詢和重新持久化 這樣一來數據庫操作就只有一個程序(多線程)來完成，不會給數據帶來壓力
高並發—微服務架構
微服務的高並發：簡單的說，“分布式架構，功能分工協作”。
微服務的高可用： 1.服務冗余。 2.優雅服務降級/熔斷 3. 服務緩存 4.服務自愈(容器)
微服務架構—高並發場景
微服務
高並發：阿里雲slb，網關控制，核心業務冗余，多級緩存。微服務適度拆分。 核心業務，拆分細化，分流
高可用：熔斷，nginx負載均衡，降低，CQRS架構，docker集群【反向代理】， docker【監控—殺dokcer---重啟docker】【監控—殺domain--重啟domain】
微服務架構—高並發場景
高可用/並發架構注意項
1.冗余多，成本增大。
2.太復雜，實現和運維成本高。
3.容災難度大
4.過度設計。超出了需求場景。
我們知道集群中的應用只在一台服務器上運行，如果這個應用出現故障，其它的某台服務器會重新啟動這個應用，接管位於共享磁盤櫃上的數據區，進而使應用重新正常運轉。我們知道整個應用的接管過程大體需要三個步驟：偵測並確認故障、后備服務器重新啟動該應用、接管共享的數據區。因此在切換的過程中需要花費一定的時間，原則上根據應用的大小不同切換的時間也會不同，越大的應用切換的時間越長
最忌諱： 過度設計。 目標：適度架構