概述
在中國的互聯網行業最大的特點就是訪問量大，我們在做項目時要考慮如何面對高併發，當一臺服務器不能滿足需求時，我們要考慮搭建多臺服務器同時對外提供服務，這時候我們就要用到反向代理和負載均衡的技術，隨着項目的擴展，對後端的數據庫也有很大壓力，我們需要用到一些緩存的技術來提高我們響應的速度，減輕對數據庫的壓力。還有一些場景下，我們需要優化用戶體驗，提高服務的穩定性或者減少模塊之間的依賴，我們會採用異步化的方案如消息隊列來架構我們的項目。
高可用(High Availability)
- 高可用(HA)就是抵禦一些不確定的因素(不穩定性), 保證我們的系統在7*24小時可以提供正常的服務
- 不穩定性包括：
- 一些自然災害：颱風、地震、洪水
- 戰爭、恐怖襲擊
- 通訊線路異常
- 服務器硬盤、內存出錯
- 程序代碼問題
- 黑客攻擊, 數據庫被刪除等
- 如果系統一直可以提供服務, 那麼我們就說我們系統的可用性是100
- 如果系統每運行100個時間單位種，有一個時間單位內無法提供服務，那麼我們就說系統可用性是99%
- 很多企業的高可用目標是：99.99% (系統的全年停機時間不超過8個小時)
- 高可用是系統架構設計中必須考慮的因素之一，目標是減少系統不能提供服務的時間
- 爲了保證高可用，系統架構設計的一個準則就是冗餘
- 比如：汽車的備胎、動車有2個駕駛員等
- 在服務器方面如果可以做到多機器熱備份, 也就是
雙機熱備、多機熱備一臺出現問題可以切換到另一臺上就保證了高可用 - 對於機房而言也需要有異地的熱備份,
異地雙活、異地多活都是通過冗餘來提高系統的高可用 - 冗餘可以解決的問題大部分都是意外產生的問題
- 如果是代碼問題或者版本升級產生的問題，冗餘就無法解決了
- 第二個準則是灰度發佈與回滾
- 灰度發佈指讓一小部分用戶先體驗新功能, 通過監控來對比觀察, 沒有異常就增加功能, 直到最後全量發佈
- 這種方式在項目上線時複雜度就增加了, 但可以保證大部分用戶高可用
- 第三個準則是限流
- 應對突然增長的訪問量，超過了系統承載能力時, 我們可以讓用戶排隊，如12306搶票時的排隊機制
- 第四個準則是降級
- 爲了保證核心業務，將一些不重要的功能暫停，讓服務器資源集中處理核心業務
高併發(High Concurrency)
- 高併發(HC)是指通過對系統的設計保證能夠同時、並行的處理很多請求, 保證單位時間內爲更多人提供服務
- 併發用戶量是指同時能夠承載正常使用系統的用戶數量
- 例如一些直播系統的在線量，一定程度上反映了系統的併發數
- 高併發設計的核心準則是擴展
- 從硬件層面上可以升級CPU、內存，以提升速度，這種擴展叫
垂直擴展, 還可以通過添加機器數量來提高響應能力，這種擴展叫水平擴展 - 在項目早期預算充足，我們優先考慮增加單機的性能
- 如果隨着業務的增加, 單機很快就會有瓶頸, 我們要考慮水平擴展，這是終極方案
- 水平擴展對系統架構設計是有要求的, 需要遵循系統設計原則
- 從硬件層面上可以升級CPU、內存，以提升速度，這種擴展叫
- 水平擴展系統設計原則
- 無狀態設計
- 先說什麼是有狀態：如果我們在開發項目時使用服務器自帶的session, 這種情況下橫向擴容時還要考慮session在不同服務器上的同步問題, 這時我們的系統是有狀態的
- 無狀態則是指避免這樣的情況發生
- 服務拆分
- 我們不要把所有服務都集中在一起, 我們要適當的將服務拆分開來, 就是現在流行的
微服務 - 用於減少模塊之間的干擾, 降低耦合度, 也會讓水平擴展變得更容易些
- 我們不要把所有服務都集中在一起, 我們要適當的將服務拆分開來, 就是現在流行的
- 緩存
- 使用緩存減少對後端數據庫的請求, 以提升響應速度
- 響應快了，系統承載的併發也就高了
- 隊列
- 通過一些異步化的方式來提升系統的併發能力
- 無狀態設計
經典的架構設計
-
在第一層是項目入口
- 包括PC、移動端的請求
- 所有的請求被接入到了入口層
-
第二層是入口層
- 第一層所有的請求都會被接入
- 需要做負載均衡，將前端請求均衡的分配到後端服務上面
- 比如分配到後端的http server上，而http server有可能是很多服務器組成(集羣)
- 通過反向代理將流量平均分配到每一臺服務器上來實現負載均衡技術
-
第三層是後端服務器層
- 服務器處理請求和響應
- 在上面我們說的水平擴展(橫向擴容), 主要是擴展http-server這一塊
- 主要是配合第二層和第四層實現
-
第四層主要是緩存和異步層
- 緩存在應用服務器和數據庫之間
- 在取數據的時候，我們會把數據放一份在緩存中，再響應出去
- 當第二次再響應的時候，我們可直接從緩存中取數據，不會再次請求數據庫從而提高性能
- 對於可以異步化處理的內容如：用戶註冊後的郵件通知, 短信通知等, 可以考慮放到消息隊列中來, 慢慢處理
- 通過隊列將同步的任務轉變爲異步的任務, 再借助第三層的worker服務器從MQ中取任務在後臺並行的處理
- 通過異步隊列只需要響應一些核心任務之後就可以返回了
-
第五層是存儲層
- 主要是一些常用的關係型數據庫如: mysql等
- 還有一些KV類型的存儲系統如: redis、mongodb
