一篇短小的文章，面試經(jīng)常遇到的這個(gè)問題。本文主要包括下面這些內(nèi)容：

　　高可用的定義

　　哪些情況可能會(huì)導(dǎo)致系統(tǒng)不可用?

　　有些提高系統(tǒng)可用性的方法?只是簡單的提一嘴，更具體內(nèi)容在后續(xù)的文章中介紹，就拿限流來說，你需要搞懂：何為限流?如何限流?為什么要限流?如何做呢?說一下原理?。

　　什么是高可用?可用性的判斷標(biāo)準(zhǔn)是啥?

　　高可用描述的是一個(gè)系統(tǒng)在大部分時(shí)間都是可用的，可以為我們提供服務(wù)的。高可用代表系統(tǒng)即使在發(fā)生硬件故障或者系統(tǒng)升級(jí)的時(shí)候，服務(wù)仍然是可用的。

　　一般情況下，我們使用多少個(gè) 9 來評(píng)判一個(gè)系統(tǒng)的可用性，比如 99.9999% 就是代表該系統(tǒng)在所有的運(yùn)行時(shí)間中只有 0.0001% 的時(shí)間都是可用的，這樣的系統(tǒng)就是非常非常高可用的了!當(dāng)然，也會(huì)有系統(tǒng)如果可用性不太好的話，可能連 9 都上不了。

　　哪些情況會(huì)導(dǎo)致系統(tǒng)不可用?

　　黑客攻擊;

　　硬件故障，比如服務(wù)器壞掉。

　　并發(fā)量/用戶請(qǐng)求量激增導(dǎo)致整個(gè)服務(wù)宕掉或者部分服務(wù)不可用。

　　代碼中的壞味道導(dǎo)致內(nèi)存泄漏或者其他問題導(dǎo)致程序掛掉。

　　網(wǎng)站架構(gòu)某個(gè)重要的角色比如 Nginx 或者數(shù)據(jù)庫突然不可用。

　　自然災(zāi)害或者人為破壞。

　　......

　　有哪些提高系統(tǒng)可用性的方法?

　　1. 注重代碼質(zhì)量，測(cè)試嚴(yán)格把關(guān)

　　我覺得這個(gè)是最最最重要的，代碼質(zhì)量有問題比如比較常見的內(nèi)存泄漏、循環(huán)依賴都是對(duì)系統(tǒng)可用性極大的損害。大家都喜歡談限流、降級(jí)、熔斷，但是我覺得從代碼質(zhì)量這個(gè)源頭把關(guān)是首先要做好的一件很重要的事情。如何提高代碼質(zhì)量?比較實(shí)際可用的就是 CodeReview，不要在乎每天多花的那 1 個(gè)小時(shí)左右的時(shí)間，作用可大著呢!

　　另外，安利這個(gè)對(duì)提高代碼質(zhì)量有實(shí)際效果的寶貝：

　　sonarqube ：保證你寫出更安全更干凈的代碼!(ps: 目前所在的項(xiàng)目基本都會(huì)用到這個(gè)插件)。

　　Alibaba 開源的 Java 診斷工具 Arthas 也是很不錯(cuò)的選擇。

　　IDEA 自帶的代碼分析等工具進(jìn)行代碼掃描也是非常非常棒的。

　　2.使用集群，減少單點(diǎn)故障

　　先拿常用的 Redis 舉個(gè)例子!我們?nèi)绾伪ＷC我們的 Redis 緩存高可用呢?答案就是使用集群，避免單點(diǎn)故障。當(dāng)我們使用一個(gè) Redis 實(shí)例作為緩存的時(shí)候，這個(gè) Redis 實(shí)例掛了之后，整個(gè)緩存服務(wù)可能就掛了。使用了集群之后，即使一臺(tái) Redis 實(shí)例，不到一秒就會(huì)有另外一臺(tái) Redis 實(shí)例頂上。

　　3.限流

　　流量控制(flow control)，其原理是監(jiān)控應(yīng)用流量的 QPS 或并發(fā)線程數(shù)等指標(biāo)，當(dāng)達(dá)到指定的閾值時(shí)對(duì)流量進(jìn)行控制，以避免被瞬時(shí)的流量高峰沖垮，從而保障應(yīng)用的高可用性。——來自 alibaba-Sentinel 的 wiki。

　　4.超時(shí)和重試機(jī)制設(shè)置

　　一旦用戶請(qǐng)求超過某個(gè)時(shí)間的得不到響應(yīng)，就拋出異常。這個(gè)是非常重要的，很多線上系統(tǒng)故障都是因?yàn)闆]有進(jìn)行超時(shí)設(shè)置或者超時(shí)設(shè)置的方式不對(duì)導(dǎo)致的。我們?cè)谧x取第三方服務(wù)的時(shí)候，尤其適合設(shè)置超時(shí)和重試機(jī)制。一般我們使用一些 RPC 框架的時(shí)候，這些框架都自帶的超時(shí)重試的配置。如果不進(jìn)行超時(shí)設(shè)置可能會(huì)導(dǎo)致請(qǐng)求響應(yīng)速度慢，甚至導(dǎo)致請(qǐng)求堆積進(jìn)而讓系統(tǒng)無法在處理請(qǐng)求。重試的次數(shù)一般設(shè)為 3 次，再多次的重試沒有好處，反而會(huì)加重服務(wù)器壓力(部分場(chǎng)景使用失敗重試機(jī)制會(huì)不太適合)。

　　5.熔斷機(jī)制

　　超時(shí)和重試機(jī)制設(shè)置之外，熔斷機(jī)制也是很重要的。 熔斷機(jī)制說的是系統(tǒng)自動(dòng)收集所依賴服務(wù)的資源使用情況和性能指標(biāo)，當(dāng)所依賴的服務(wù)惡化或者調(diào)用失敗次數(shù)達(dá)到某個(gè)閾值的時(shí)候就迅速失敗，讓當(dāng)前系統(tǒng)立即切換依賴其他備用服務(wù)。 比較常用的是流量控制和熔斷降級(jí)框架是 Netflix 的 Hystrix 和 alibaba 的 Sentinel。

　　6.異步調(diào)用

　　異步調(diào)用的話我們不需要關(guān)心最后的結(jié)果，這樣我們就可以用戶請(qǐng)求完成之后就立即返回結(jié)果，具體處理我們可以后續(xù)再做，秒殺場(chǎng)景用這個(gè)還是蠻多的。但是，使用異步之后我們可能需要 適當(dāng)修改業(yè)務(wù)流程進(jìn)行配合，比如用戶在提交訂單之后，不能立即返回用戶訂單提交成功，需要在消息隊(duì)列的訂單消費(fèi)者進(jìn)程真正處理完該訂單之后，甚至出庫后，再通過電子郵件或短信通知用戶訂單成功。除了可以在程序中實(shí)現(xiàn)異步之外，我們常常還使用消息隊(duì)列，消息隊(duì)列可以通過異步處理提高系統(tǒng)性能(削峰、減少響應(yīng)所需時(shí)間)并且可以降低系統(tǒng)耦合性。

　　7.使用緩存

　　如果我們的系統(tǒng)屬于并發(fā)量比較高的話，如果我們單純使用數(shù)據(jù)庫的話，當(dāng)大量請(qǐng)求直接落到數(shù)據(jù)庫可能數(shù)據(jù)庫就會(huì)直接掛掉。使用緩存緩存熱點(diǎn)數(shù)據(jù)，因?yàn)榫彺娲鎯?chǔ)在內(nèi)存中，所以速度相當(dāng)?shù)乜?

　　8.其他

　　核心應(yīng)用和服務(wù)優(yōu)先使用更好的硬件

　　監(jiān)控系統(tǒng)資源使用情況增加報(bào)警設(shè)置。

　　注意備份，必要時(shí)候回滾。

　　灰度發(fā)布： 將服務(wù)器集群分成若干部分，每天只發(fā)布一部分機(jī)器，觀察運(yùn)行穩(wěn)定沒有故障，第二天繼續(xù)發(fā)布一部分機(jī)器，持續(xù)幾天才把整個(gè)集群全部發(fā)布完畢，期間如果發(fā)現(xiàn)問題，只需要回滾已發(fā)布的一部分服務(wù)器即可

　　定期檢查/更換硬件： 如果不是購買的云服務(wù)的話，定期還是需要對(duì)硬件進(jìn)行一波檢查的，對(duì)于一些需要更換或者升級(jí)的硬件，要及時(shí)更換或者升級(jí)。