本文轉自：http://ifeve.com/%E5%A6%82%E4%BD%95%E5%BB%BA%E8%AE%BE%E9%AB%98%E5%8F%AF%E7%94%A8%E7%B3%BB%E7%BB%9F/
如何建設高可用系統
面試的時候經常會問一個問題，如何建設高可用系統？大家可以一起探討下。
“高可用性”（High Availability）通常來描述一個系統經過專門的設計，從而減少停工時間，而保持其服務的高度可用性。以下是高可用系統的設計建議：
設計建議
- 減少單點 – 去單點首先要識別整個系統所有主鏈路的單點，如機房（同城異地雙機房），應用服務器，DNS服務器，SFTP服務器，LBS，緩存服務器，數據庫，消息服務器，代理服務器和專線等，如系統通過專線調用對方服務，需要考慮同時拉聯通和電信的專線，聯通或電信的專線還是有一定概率會出現問題的，但是同時出問題的概率會小非常多。優先使用軟負載，使用硬負載兜底。
- 減少依賴 – 減少DNS依賴，減少遠程服務依賴，DNS依賴可以嘗試設置本地host，用工具給所有服務器推送最新的域名映射關系，通過本地緩存或近端服務減少RPC調用。
- 限制循環 – 避免無限死循環，導致CPU利用率百分百，可以設置for循環的最大循環次數，如最大循環1000次。
- 控制流量 – 避免異常流量對應用服務器產生影響，可以對指定服務設置流量限制，如QPS，TPS，QPH（每小時總請求量）和QPD（每天總請求量）。
- 精准監控 – 對CPU利用率，load，內存，帶寬，系統調用量，應用錯誤量，PV，UV和業務量進行監控，避免內存泄露和異常代碼對系統產生影響，配置監控一定要精准，如平時內存利用率是50%，監控可以配置成60%進行報警，這樣可以提前感知內存泄露問題，避免應用無響應。
- 無狀態 – 服務器不能保存用戶狀態數據，如在集群環境下不能用static變量保存用戶數據，不能長時間把用戶文件存放在服務器本地。服務器有狀態會難以擴容，且出現單點問題。
- 容量規划 – 定期對容量進行評估。如大促前進行壓測和容量預估，根據需要進行擴容。
- 功能開關 – 打開和關閉某些功能，比如消息量過大，系統處理不了，把開關打開后直接丟棄消息不處理。上線新功能增加開關，如果有問題關閉新功能。
- 設置超時 – 設置連接超時和讀超時設置，不應該太大，如果是內部調用連接超時可以設置成1秒，讀超時3秒，外部系統調用連接超時可以設置成3秒，讀超時設置成20秒。
- 重試策略 – 當調用外部服務異常時可以設置重試策略，每次重試時間遞增，但是需要設置最大重試次數和重試開關，避免對下游系統產生影響。
- 隔離 – 應用隔離，模塊隔離，機房隔離和線程池隔離。可以按照優先級，不變和變幾個維度來隔離應用和模塊，如抽象和不變的代碼放在一個模塊，這個模塊的代碼幾乎不會修改，可用性高，經常變的業務邏輯放在一個模塊里，這樣就算有問題，也只會影響到某一個業務。不同的業務使用不同的線程池，避免低優先級任務阻塞高優先級，或高優先級任務過多時影響低優先級任務永遠不會執行。
- 異步調用 – 同步調用改成異步調用，解決遠程調用故障或調用超時對系統的影響。
- 熱點緩存 – 對熱點數據進行緩存，降低RPC調用。如B系統提供名單服務，B系統可以提供一個client SDK提供近端緩存服務，定期去服務器端取數據，減少RPC調用。
- 緩存容災 – 當數據庫不可用時可以使用緩存的數據。並設置分級緩存，如優先讀本地緩存，其次讀分布式緩存。
- 分級緩存 – 優先讀本地緩存，其次讀分布式緩存。通過推模式更新本地緩存。
- 系統分級 – 對系統進行分級，如ABC三個等級，高級別系統不依賴於低級別系統，並且高級別系統比底級別系統高可用率要高。
- 服務降級 – 如果系統出現響應緩慢等狀況，可以關閉部分功能，從而釋放系統資源，保證核心服務的正常運行。需要識別哪些服務可以降級，比如突然有大量消息流入，導致服務不可用，我們會把消息直接丟棄掉。或通過設置流控，拒絕為低級別系統提供服務。
- 流量蓄洪 – 當流量陡增時，可以將請求進行蓄洪，如把請求保存在數據庫中，再按照指定的QPS進行泄洪，有效的保護下游系統，也保證了服務的可用性。當調用對方系統，對方系統響應緩慢或無響應時，可采取自動蓄洪。
- 服務權重 – 在集群環境中，可自動識別高性能服務，拒絕調用性能低的服務。如在集群環境中，對調用超時的服務器進行權重降低，優先調用權重高的服務器。
- 依賴簡化– 減少系統之間的依賴，比如使用消息驅動，A和B系統通過消息服務器傳遞數據，A和B系統使用數據庫進行讀寫分離，A系統負責往數據庫中寫數據，B系統負責讀數據，因為數據存放在數據庫中，當A不可用時，短時間內不影響B系統提供服務。
- 彈性擴容 – 根據資源的使用率自動或手動進行擴容。如帶寬不夠用時，快速增加帶寬。
- 灰度和回滾 – 發布新功能只讓部分服務器生效，且觀察幾天逐漸切流，如果出現問題只影響部分客戶。出現問題快速回滾，或者直接下線灰度的機器。
- 減少遠程調用 – 優先調用本地JVM內服務，其次是同機房服務，然后是同城服務，最后是跨城服務。如A調用B，B調用互聯網的C系統獲取數據，B系統可以把數據緩存起來，並設置數據的保鮮度，減少B對C的依賴。配置中心把注冊服務的地址推送到調用服務的系統本地。參數中心把參數配置信息推送到系統的本地內存，而不是讓系統去遠程服務器獲取參數信息。
- 熔斷機制 – 增加熔斷機制，當監控出線上數據出現大幅跌漲時，及時中斷，避免對業務產生更大影響。如我們做指標計算時，指標可以計算慢，但是不能算錯，如果發現某個用戶的指標環比或同比增長一倍或跌零，會考慮保存所有消息，並中止該用戶的指標計算。
- 運行時加載模塊 – 我們會把經常變的業務代碼變成一個個業務模塊，使用Java的ClassLoader在運行時動態加載和卸載模塊，當某個模塊有問題時候，可以快速修復。
- 代碼掃描 – 使用IDEA代碼分析等工具進行代碼掃描，識別出程序中的BUG，如空指針異常，循環依賴等。
- 自動備份 – 程序，系統配置和數據定期進行備份。可使用linux命令和shell腳本定時執行備份策略，自動進行本地或異地。出現問題時能快速重新部署。
- 線上壓測 – 系統的對外服務需要進行壓測，知道該服務能承受的QPS和TPS，從而做出相對准確的限流。
參考資料
- 分布式系統穩定性模式