關於高併發
高併發場景
互聯網應用以及雲計算的普及，使得架構設計和軟件技術的關注點從如何實現複雜的業務邏 輯，轉變爲如何滿足大量用戶的高併發訪問請求。
一個簡單的計算處理過程，如果一旦面對大量的用戶訪問，整個技術挑戰就會變得完全不 同，軟件開發方法、技術團隊組織、軟件的過程管理都會完全不同。
架構策略
垂直伸縮
垂直伸縮，就是提升單臺服務器的處理能力。
比如用更快頻率的 CPU，用更多核的 CPU，用更大的內存，用更快的網卡，用更多的磁盤組成一臺服務器，使單臺服務器的處理能力得到提升。
垂直伸縮帶來的價格成本和服務器的處理能力並不一定呈線性關係。
增加同樣的費用，並不能得到同樣的計算能力。而且計算能力越強大，需要花費的錢就越多。
而且，受計算機硬件科技水平的制約，單臺服務器的計算能力並不能無限增加，而互聯網，特別是物聯網的計算要求幾乎是無限的。
因此，在互聯網以及物聯網領域，並不使用垂直伸縮這種方案，而是使用水平伸縮。
水平伸縮
所謂的水平伸縮，指的是不去提升單機的處理能力，而是使用更多的服務器，將這些服務器構成一個分佈式集羣，通過這個集羣，對外統一提供服務，以此來提高系統整體的處理能力。
但是要想讓更多的服務器構成一個整體，就需要在架構上進行設計，讓這些服務器成爲整體 系統的一個部分，將這些服務器有效地組織起來，統一提升系統的處理能力。
這就是互聯網應用和雲計算中普遍採用的分佈式架構方案。
分佈式技術方案
- 分佈式緩存
- 負載均衡
- 反向代理與 CDN
- 分佈式消息隊列
- 分佈式數據庫
- NoSQL 數據庫
- 分佈式文件
- 搜索引擎
- 微服務
將這些分佈式技術整合起來，就是分佈式架構方案
互聯網分佈式架構演化
單機架構
微服務架構
分佈式緩存架構
負載均衡架構
數據庫讀寫分離
消息隊列&反向代理&CDN&分佈式數據庫架構
海量數據的存儲，主要通過分佈式數據庫、分佈式文件系統、NoSQL 數據庫解決。
直接在數據庫上查詢已經無法滿足這些數據的查詢性能要求，還需要部署獨立的搜索引擎提供查詢服務。
同時減少數據中心的網絡帶寬壓力，提供更好的用戶訪問延時，使用 CDN 和反向代理提供前置緩存，儘快返回靜態文件資源給用戶。
爲了使各個子系統更靈活易於擴展，則使用分佈式消息隊列將相關子系統解耦，通過消息的發佈訂閱完成子系統間的協作。
使用微服務架構將邏輯上獨立的模塊在物理上也獨立部署，單獨維護，應用系統通過組合多個微服務完成自己的業務邏輯，實現模塊更高級別的複用，從而更快速地開發系統和維護系統。
關於高性能
高性能場景
互聯網應用以及雲計算的普及，使得架構設計和軟件技術的關注點從如何實現複雜的業務邏 輯，轉變爲如何滿足大量用戶的高併發訪問請求。
衡量指標
4個性能指標：併發數不變，響應時間足夠快，單位時間的吞吐量就會相應的提高。
- 響應時間：指從發出請求開始到收到最後響應數據所需要的時間。反映系統快慢。
- 併發數：系統同時處理的請求數。反映系統負載。
- 吞吐量：單位時間內，系統處理請求的數量。體現系統處理能力。
- HTTP請求數：HPS
- 每秒事務數：TPS
- 每秒查詢數：QPS
- 性能計數器：
- 系統負載System Load
- 對象和線程數
- 內存使用
- CPU使用
- 磁盤和網絡
性能測試
- 性能測試
- 負載測試
- 壓力測試
- 穩定性測試
性能優化
性能優化5個過程
- 1.性能測試
- 2.性能分析
- 3.性能優化
- 4.性能測試
- 5.是否符合預期性能目標
性能優化策略
- 1.數據中心優化
- 2.硬件優化
- 3.操作系統優化
- 4.虛擬機優化
- 5.基礎組件優化
- 6.架構優化
- 緩存
- 消息隊列
- 集羣
- 7.代碼優化
- 使用合理的數據結構優化性能
- 編寫性能更好的SQL語句
- 實現異步I/O與異步方法調用
關於高可用
高可用場景
我們知道，Web 應用在各種情況下都有可能不可訪問，也就是不可用。
各種硬件故障，比如應用服務器及數據庫宕機、網絡交換機宕機、磁盤損壞、網卡鬆掉等等。還有各種軟件故障，程序 Bug 什麼的。即使沒有 Bug，程序要升級，必須要關閉進程重新啓動，這段時間應用也是不可用的；
此外，還有外部環境引發的不可用，比如促銷引來大量用戶訪問，導致系統併發壓力太大而崩潰，以及，黑客攻擊、機房火災、挖掘機挖斷光纜，各種情況導致的應用不可用。
而互聯網的高可用是說，在上面各種情況下，應用都要是可用的，用戶都能夠正常訪問系統，完成業務處理。
衡量指標
業界通常用多少個 9 來說明互聯網應用的可用性。
- 兩個9：系統基本可用，年度不可用時間小於88小時
- 三個9：系統較高可用，年度不可用時間小於9個小時
- 四個9：具有自動恢復能力的高可用，年度不可用時間
- 五個9：極高的可用性，年度不可用時間小於5分鐘
我們熟悉的互聯網產品的可用性大多是 4 個 9。淘寶、百度、微信，差不多都是這樣。
相對支付寶的可用性超過 99.99%，Twitter 的可用性只有 98%。
在互聯網企業中，爲了更好地管理系統的可用性，界定好系統故障以後的責任，通常會用故障分進行管理。
架構策略
- 提高應災能力
- 冗餘備份：數據庫主主複製
- 負載均衡
- 異地多活
- 保護策略
- 失敗隔離：限制影響範圍。主要架構技術是消息隊列
- 限流降級