網(wǎng)站的可用性強(qiáng)調(diào)的是對(duì)最終用戶的使用價(jià)值。它牽動(dòng)著人們的神經(jīng)，直接影響著公司的形象和利益，許多互聯(lián)網(wǎng)公司都將網(wǎng)站的可用性列入工程師的績(jī)效考核，與獎(jiǎng)金、升遷等利益直接掛鉤。

1 可用性的度量與考核

1.1 可用性度量

網(wǎng)站不可用時(shí)間（故障時(shí)間） = 故障修復(fù)時(shí)間點(diǎn) - 故障發(fā)現(xiàn)（報(bào)告）時(shí)間點(diǎn)

網(wǎng)站年度可用性指標(biāo) = （1 - 網(wǎng)站不可用時(shí)間/年度總時(shí)間 ） * 100%

業(yè)界通常用多個(gè) 9 來衡量網(wǎng)站的可用性：

• 2 個(gè) 9 - 基本可用，不可用時(shí)間小于 88 小時(shí)（Twitter 的可用性不足 2 個(gè) 9）。
• 3 個(gè) 9 - 較高可用，不可用時(shí)間小于 9 小時(shí)。
• 4 個(gè) 9 - 具有自動(dòng)恢復(fù)能力的高可用，不可用時(shí)間小于 53 分鐘（QQ 服務(wù)）。
• 5 個(gè) 9 - 極高可用，不可用時(shí)間小于 5 分鐘。

影響可用性的因素很多：

• 技術(shù)是否過硬。
• 設(shè)備資金的投入。
• 工程師的責(zé)任心。
• 好運(yùn)氣 O(∩_∩)O~

1.2 可用性考核

對(duì)外是服務(wù)承諾，對(duì)內(nèi)是考核指標(biāo)。針對(duì)每一個(gè)工程師的考核，使用的是故障分。故障分是一種對(duì)網(wǎng)站故障進(jìn)行分類加權(quán)計(jì)算故障責(zé)任的方法。下面是故障分類權(quán)重示例：

故障分的計(jì)算公式：
故障分 = 故障時(shí)間（分鐘） * 故障權(quán)重

在年初或考核季度的起始，會(huì)根據(jù)網(wǎng)站的可用性指標(biāo)計(jì)算總的故障分，然后根據(jù)團(tuán)隊(duì)和個(gè)人的職責(zé)角色分?jǐn)偣收戏郑@個(gè)故障分是管理預(yù)期的故障分。發(fā)生故障后，根據(jù)故障分類和責(zé)任劃分，把故障分劃定給相關(guān)的責(zé)任人。年末或考核季度結(jié)束時(shí)，團(tuán)隊(duì)和個(gè)人實(shí)際承擔(dān)的故障分如果超過了年初分?jǐn)偟墓收戏?，?jī)效考核就會(huì)受到影響。

故障處理流程

有時(shí)候，一個(gè)故障責(zé)任可能會(huì)由多個(gè)部門或團(tuán)隊(duì)來承擔(dān)，那么故障分也會(huì)按照相應(yīng)的責(zé)任分?jǐn)偟讲煌膱F(tuán)隊(duì)和個(gè)人。

網(wǎng)站的可用性跟技術(shù)、運(yùn)營等相關(guān)各方的績(jī)效息息相關(guān)，所以在架構(gòu)設(shè)計(jì)與評(píng)審會(huì)上，關(guān)于系統(tǒng)可用性的討論總是最費(fèi)精力和時(shí)間的。

不同的企業(yè)文化與市場(chǎng)策略，也會(huì)影響到系統(tǒng)可用性的架構(gòu)決策：

• 崇尚創(chuàng)新和風(fēng)險(xiǎn)的公司，對(duì)可用性的要求會(huì)低一些。
• 業(yè)務(wù)快速增長(zhǎng)的網(wǎng)站忙于應(yīng)對(duì)指數(shù)級(jí)增長(zhǎng)的用戶，對(duì)可用性的要求也會(huì)低一些。
• 服務(wù)于收費(fèi)用戶的網(wǎng)站對(duì)可用性很敏感，因?yàn)榉?wù)的不可用或關(guān)鍵用戶的數(shù)據(jù)丟失，都有可能會(huì)導(dǎo)致收費(fèi)用戶的投訴甚至引來官司。

2 高可用的架構(gòu)

企業(yè)級(jí)應(yīng)用為了提高系統(tǒng)的可用性，通常會(huì)采用較昂貴的軟硬件設(shè)備（小型機(jī)、Oracle 數(shù)據(jù)庫等）。而互聯(lián)網(wǎng)公司則更多地采用 PC 級(jí)服務(wù)器、開源的數(shù)據(jù)庫和操作系統(tǒng)，因?yàn)槌杀镜吐颫(∩_∩)O~

這些廉價(jià)的設(shè)備出現(xiàn)硬件故障是常態(tài)，所以在高可用的架構(gòu)上就要保證發(fā)生硬件故障時(shí)，服務(wù)依然可用、數(shù)據(jù)依然能夠訪問與保存。

實(shí)現(xiàn)上述功能的主要手段是數(shù)據(jù)和服務(wù)的冗余備份以及失效轉(zhuǎn)移。一旦服務(wù)器宕機(jī)，就將服務(wù)切換到其他可用的服務(wù)器上；如果磁盤損壞，就從備份的磁盤中讀取數(shù)據(jù)。

典型的網(wǎng)站設(shè)計(jì)遵循基本分層架構(gòu)模型：

分層架構(gòu)模型

• 應(yīng)用層：處理具體的業(yè)務(wù)邏輯。
• 服務(wù)層：提供可復(fù)用的服務(wù)。
• 數(shù)據(jù)層：數(shù)據(jù)的存儲(chǔ)和訪問。

中小型網(wǎng)站在部署時(shí)，通常將應(yīng)用層和服務(wù)層一起部署，而數(shù)據(jù)層則另外部署。

應(yīng)用與數(shù)據(jù)分離部署

復(fù)雜的大型網(wǎng)站架構(gòu)，劃分的粒度會(huì)更小、更詳細(xì)，結(jié)構(gòu)更復(fù)雜，但還是能夠把這些模塊劃分到這三層架構(gòu)中的：

大型網(wǎng)站架構(gòu)

不同的業(yè)務(wù)產(chǎn)品會(huì)部署在不同的服務(wù)器集群上。而這些產(chǎn)品又會(huì)依賴一些共用的可復(fù)用的服務(wù)（比如賬戶服務(wù)等），這些服務(wù)也是部署在各自的服務(wù)器集群上的。至于最底層的數(shù)據(jù)層，也是部署在服務(wù)器集群上的哦O(∩_∩)O~

大型網(wǎng)站的分布式部署，使得位于不同層次的服務(wù)器具有不同的可用性設(shè)計(jì)：

• 應(yīng)用層 - 為了應(yīng)對(duì)高并發(fā)的訪問請(qǐng)求，通常會(huì)使用負(fù)載均衡設(shè)備把一組的服務(wù)器組合為一個(gè)集群，共同對(duì)外提供服務(wù)。當(dāng)負(fù)載均衡設(shè)備監(jiān)控到某臺(tái)服務(wù)器不可用時(shí)，就將其從集群中剔除，并把請(qǐng)求轉(zhuǎn)發(fā)到集群中的其他可用的服務(wù)器。
• 服務(wù)層 - 應(yīng)用層通過分布式服務(wù)框架來調(diào)用這一層提供的服務(wù)。分布式服務(wù)框架會(huì)在應(yīng)用層的客戶端程序中實(shí)現(xiàn)軟件級(jí)的負(fù)載均衡，并通過注冊(cè)中心監(jiān)控這些提供服務(wù)的服務(wù)器。一旦發(fā)現(xiàn)某個(gè)服務(wù)器不可用，會(huì)立即通知客戶端程序修改服務(wù)訪問列表，剔除不可用的服務(wù)器。
• 數(shù)據(jù)層 - 寫入數(shù)據(jù)的同時(shí)同步復(fù)制數(shù)據(jù)，把數(shù)據(jù)寫入多臺(tái)服務(wù)器，實(shí)現(xiàn)數(shù)據(jù)的冗余備份。當(dāng)數(shù)據(jù)服務(wù)器宕機(jī)時(shí)，會(huì)把針對(duì)數(shù)據(jù)的訪問切換到擁有備份數(shù)據(jù)的服務(wù)器上。

下面我們會(huì)針對(duì)每一層究竟如何實(shí)現(xiàn)高可用，進(jìn)行一一探討哦O(∩_∩)O~

3 實(shí)現(xiàn)高可用的應(yīng)用層

應(yīng)用層是處理業(yè)務(wù)邏輯，這一層的特點(diǎn)是無狀態(tài)性。

無狀態(tài)性指的是：多個(gè)服務(wù)器之間是完全對(duì)等的，即把請(qǐng)求提交給任意一臺(tái)服務(wù)器，處理的結(jié)果都是一樣的。

3.1 通過負(fù)載均衡實(shí)現(xiàn)失效轉(zhuǎn)移

在業(yè)務(wù)量和數(shù)據(jù)量都較高的情況下，通過負(fù)載均衡，可以將流量和數(shù)據(jù)分?jǐn)偟揭粋€(gè)集群所組成的多臺(tái)服務(wù)器上，以提高整體的處理能力。目前的負(fù)載均衡軟、硬件都提供了失效轉(zhuǎn)移功能。所以，如果集群的服務(wù)是無狀態(tài)的對(duì)等服務(wù)時(shí)，負(fù)載均衡技術(shù)可以保證系統(tǒng)的高可用：

負(fù)載均衡實(shí)現(xiàn)失效轉(zhuǎn)移

當(dāng) Web 服務(wù)器集群中的服務(wù)器都可用時(shí)，負(fù)載均衡服務(wù)器會(huì)把訪問請(qǐng)求分發(fā)給任意一臺(tái)服務(wù)器進(jìn)行處理。負(fù)載均衡服務(wù)器通過心跳檢測(cè)機(jī)制，如果發(fā)現(xiàn)某臺(tái)服務(wù)器（比如圖示中的 10.0.0.1）失去響應(yīng)，就會(huì)把它從服務(wù)器列表中剔除。

為了保證高可用，即使某個(gè)應(yīng)用訪問量非常少，也必須至少部署兩臺(tái)服務(wù)器，通過負(fù)載均衡技術(shù)來構(gòu)建一個(gè)小型集群。

3.2 服務(wù)器集群中的 Session 管理

業(yè)務(wù)總是有狀態(tài)的，比如交易類網(wǎng)站，需要有購物車記錄用戶購買的商品。在 web 應(yīng)用中，這些狀態(tài)就稱為 Session。在單機(jī)的情況下，Session 可以由部署在服務(wù)器上的 Web 容器（如 Tomcat）進(jìn)行統(tǒng)一管理。但在使用負(fù)載均衡的集群環(huán)境中，要保證每次請(qǐng)求都能夠獲得正確的 Session 就很復(fù)雜。

在集群環(huán)境中，有這些手段可以進(jìn)行 Session 管理：

3.2.1 復(fù)制 Session

這是早期的企業(yè)應(yīng)用系統(tǒng)使用較多的一種 Session 管理策略。應(yīng)用服務(wù)器開啟 Web 容器的 Session 復(fù)制功能，然后在集群中的幾臺(tái)服務(wù)器之間同步 Session 對(duì)象，使得每一臺(tái)服務(wù)器都保存著所有用戶的 Session 信息：

復(fù)制 Session

3.2.2 綁定 Session

利用負(fù)載均衡的源地址 Hash 算法，將源于同一 IP 的請(qǐng)求分發(fā)到同一臺(tái)服務(wù)器上。這樣在整個(gè)會(huì)話期間，用戶的所有請(qǐng)求都是在同一臺(tái)服務(wù)器上進(jìn)行處理，即把 Session 綁定到某臺(tái)特定的服務(wù)器上。這種方法又稱為 “會(huì)話黏滯”。

綁定 Session

綁定 Session 的方案不符合系統(tǒng)高可用的需求，因?yàn)橐坏┠撑_(tái)服務(wù)器宕機(jī)，那么該服務(wù)器上的 Session 就不存在咯。即使把用戶的請(qǐng)求切換到其他服務(wù)器也會(huì)因?yàn)闆]有 Session 而導(dǎo)致業(yè)務(wù)無法正常處理。所以很少有網(wǎng)站使用綁定 Session 的方案。

3.2.3 利用 Cookie 記錄 Session

這種方式是將 Session 記錄在客戶端，每次請(qǐng)求服務(wù)器時(shí)，把 Session 放在請(qǐng)求中發(fā)送給服務(wù)器，服務(wù)器處理后，再把修改過的 Session 發(fā)送回客戶端。

網(wǎng)站可以利用瀏覽器支持的 Cookie 記錄 Session：

利用 Cookie 記錄 Session

利用 Cookie 記錄 Session 也有一些缺點(diǎn)：

• Cookie 有大小限制，記錄的信息有限。
• 每次請(qǐng)求響應(yīng)都要傳輸 Cookie，影響性能。
• 如果用戶關(guān)閉了 Cookie，訪問會(huì)變得不正常。

但由于 Cookie 簡(jiǎn)單易用，能夠支持應(yīng)用服務(wù)器的線性伸縮；而且大部分需要記錄的 Session 信息又比較小。所以許多網(wǎng)站都或多或少地使用 Cookie 記錄 Session。

3.2.4 Session 服務(wù)器

利用獨(dú)立部署的 Session 服務(wù)器或集群，來統(tǒng)一管理 Session。應(yīng)用服務(wù)器每次讀寫 Session 時(shí)，都需要訪問 Session 服務(wù)器。

利用 Session 服務(wù)器共享 Session

這樣的方案是把應(yīng)用服務(wù)器，分為無狀態(tài)的應(yīng)用服務(wù)器與有狀態(tài)的 Session 服務(wù)器。

對(duì)于有狀態(tài)的 Session 服務(wù)器，可以這樣簡(jiǎn)單實(shí)現(xiàn)：利用分布式緩存、數(shù)據(jù)庫等組件的基礎(chǔ)上進(jìn)行封裝，使其符合 Session 的存儲(chǔ)與訪問的要求。

4 實(shí)現(xiàn)高可用的服務(wù)層

可復(fù)用的服務(wù)模塊為產(chǎn)品提供了基礎(chǔ)公共服務(wù)。這些服務(wù)通常都是獨(dú)立分布式部署，由具體應(yīng)用進(jìn)行遠(yuǎn)程調(diào)用。它們也是無狀態(tài)的服務(wù)，因此可以使用類似負(fù)載均衡的失效轉(zhuǎn)移策略實(shí)現(xiàn)高可用。

還有這些高可用的策略：

4.1 分級(jí)管理

運(yùn)維層面對(duì)服務(wù)器進(jìn)行分級(jí)管理，核心應(yīng)用與服務(wù)優(yōu)先使用更好的硬件。

在服務(wù)部署上進(jìn)行必要的隔離，避免故障的連鎖反應(yīng)：

• 低優(yōu)先級(jí)的服務(wù)通過啟動(dòng)不同的線程或部署在不同的虛擬機(jī)上進(jìn)行隔離。
• 高優(yōu)先級(jí)的服務(wù)需要部署在不同的物理機(jī)上，核心服務(wù)和數(shù)據(jù)最好是部署在不同地域的數(shù)據(jù)中心上。

4.2 超時(shí)設(shè)置

在應(yīng)用中設(shè)置調(diào)用服務(wù)的超時(shí)時(shí)間，一旦超時(shí)，通信框架就拋出異常。應(yīng)用根據(jù)服務(wù)調(diào)度策略，可以選擇繼續(xù)重試或者將請(qǐng)求轉(zhuǎn)移到提供相同服務(wù)的其他服務(wù)器上。

4.3 異步調(diào)用

應(yīng)用對(duì)服務(wù)的調(diào)用，通過消息隊(duì)列的異步方式實(shí)現(xiàn)。應(yīng)用程序會(huì)將用戶注冊(cè)信息發(fā)送給消息隊(duì)列服務(wù)器后，立即返回用戶注冊(cè)成功的響應(yīng)。而多個(gè)消費(fèi)者任務(wù)（記錄用戶信息到數(shù)據(jù)庫、發(fā)送注冊(cè)成功郵件、開通權(quán)限）會(huì)從消息隊(duì)列中獲取用戶注冊(cè)信息后異步執(zhí)行。

注意：不是所有的的服務(wù)調(diào)用都可以使用異步調(diào)用模式。比如 “獲取用戶信息的服務(wù)” 或 “必須確認(rèn)服務(wù)調(diào)用成功才能繼續(xù)下一步操作的服務(wù)” 等，都不適合使用異步調(diào)用模式。

4.4 服務(wù)降級(jí)

網(wǎng)站訪問的高峰期，服務(wù)可能因?yàn)榇罅康牟l(fā)調(diào)用而導(dǎo)致性能下降，嚴(yán)重時(shí)甚至?xí)?dǎo)致服務(wù)宕機(jī)。所以為了保證核心應(yīng)用與服務(wù)的正常運(yùn)行，我們必須對(duì)某些服務(wù)進(jìn)行降級(jí)。降級(jí)有兩種手段：

1. 拒絕服務(wù) - 拒絕低優(yōu)先級(jí)應(yīng)用的調(diào)用，減少并發(fā)數(shù)，以確保核心應(yīng)用；或隨機(jī)拒絕部分請(qǐng)求，以節(jié)約資源。
2. 關(guān)閉功能 - 關(guān)閉部分不重要的服務(wù)，或關(guān)閉服務(wù)內(nèi)不重要的功能，以節(jié)約資源。比如淘寶在 “雙十一” 促銷期間就使用了這種方法：它在系統(tǒng)最繁忙的階段關(guān)閉了 “評(píng)價(jià)”、“確認(rèn)收貨” 等非核心服務(wù)，以保證核心的交易服務(wù)。

4.5 冥等性設(shè)計(jì)

應(yīng)用調(diào)用服務(wù)失敗后，會(huì)把請(qǐng)求發(fā)給其他的服務(wù)器，但這個(gè)失敗可能不是真的！比如服務(wù)實(shí)際已處理成功，但因?yàn)榫W(wǎng)絡(luò)故障，所以應(yīng)用沒有收到響應(yīng)，那么這時(shí)應(yīng)用所重新提交的請(qǐng)求，就是在重復(fù)調(diào)用服務(wù)！如果這是一個(gè)轉(zhuǎn)賬服務(wù)，那么后果就很嚴(yán)重啦。

重復(fù)調(diào)用服務(wù)是不可避免的，所以服務(wù)層必須保證重復(fù)調(diào)用服務(wù)與調(diào)用一次服務(wù)的結(jié)果是相同的，即服務(wù)具有冥等性。

比如轉(zhuǎn)賬交易的操作，就需要通過交易編號(hào)對(duì)調(diào)用的服務(wù)進(jìn)行有效性校驗(yàn)，保證調(diào)用是有效的才能繼續(xù)執(zhí)行。

5 實(shí)現(xiàn)高可用的數(shù)據(jù)層

對(duì)網(wǎng)站而言，最高貴的資產(chǎn)是多年運(yùn)營積累下來的數(shù)據(jù)（用戶數(shù)據(jù)、交易數(shù)據(jù)、商品數(shù)據(jù)等）。所以保護(hù)了數(shù)據(jù)就是保護(hù)了企業(yè)的命脈。

保證數(shù)據(jù)高可用的手段是數(shù)據(jù)備份和失效轉(zhuǎn)移：

1. 數(shù)據(jù)備份 - 保證數(shù)據(jù)有多個(gè)副本，任意副本的失效不會(huì)導(dǎo)致數(shù)據(jù)的永久丟失。
2. 失效轉(zhuǎn)移 - 當(dāng)一個(gè)數(shù)據(jù)副本不可訪問時(shí)，可以快速地切換到其他副本。

注意：緩存服務(wù)不是數(shù)據(jù)存儲(chǔ)服務(wù)，緩存服務(wù)器的宕機(jī)所引起的緩存數(shù)據(jù)丟失而導(dǎo)致的服務(wù)器負(fù)載過高的情況，應(yīng)該通過其他手段進(jìn)行解決。可以讓整個(gè)網(wǎng)站共享一個(gè)分布式緩存集群，應(yīng)用只需要向共享緩存集群申請(qǐng)緩存資源即可。這樣任何一臺(tái)緩存服務(wù)器宕機(jī)所引起的緩存失效，都只會(huì)影響到緩存數(shù)據(jù)的一小部分，而不會(huì)對(duì)應(yīng)用的性能和數(shù)據(jù)庫負(fù)載造成太大的影響。

5.1 CAP 原理

為了保證數(shù)據(jù)的高可用，網(wǎng)站通常會(huì)犧牲數(shù)據(jù)的一致性。

高可用的數(shù)據(jù)有這幾層含義：

1. 數(shù)據(jù)持久性 - 保證數(shù)據(jù)可持久存儲(chǔ)，即把數(shù)據(jù)寫入可持久性存儲(chǔ)的硬件的同時(shí)，還需要把數(shù)據(jù)備份成一個(gè)或多個(gè)副本。
2. 數(shù)據(jù)可訪問性 -把多個(gè)數(shù)據(jù)副本存儲(chǔ)在不同的存儲(chǔ)設(shè)備下，如果一個(gè)存儲(chǔ)設(shè)備損壞，就需要把對(duì)數(shù)據(jù)的訪問切換到另一個(gè)數(shù)據(jù)存儲(chǔ)設(shè)備上。這個(gè)過程要盡量快，讓客戶不可感知。
3. 數(shù)據(jù)一致性 - 在數(shù)據(jù)有多個(gè)副本的情況下，如果網(wǎng)絡(luò)、服務(wù)器或軟件出現(xiàn)故障，會(huì)導(dǎo)致部分副本寫入成功，部分寫入失敗。這樣就會(huì)造成各個(gè)副本之間存在數(shù)據(jù)不一致的情況。

CAP 原理

CPA 原理認(rèn)為：一個(gè)提供數(shù)據(jù)服務(wù)的存儲(chǔ)系統(tǒng)無法同時(shí)滿足數(shù)據(jù)一致性（Consistency）、數(shù)據(jù)可用性（Availability ）、分區(qū)耐受性（Patition Tolerance）這三個(gè)條件。

大型網(wǎng)站中，數(shù)據(jù)規(guī)模會(huì)快速擴(kuò)張，因此可伸縮性（分區(qū)耐受性）必不可少；規(guī)模變大后，機(jī)器數(shù)量也會(huì)變得龐大，這時(shí)網(wǎng)絡(luò)和服務(wù)器故障就會(huì)頻繁出現(xiàn)，所以網(wǎng)站使用了分布式系統(tǒng)保證應(yīng)用高可用。一般情況下，大型網(wǎng)站大都會(huì)強(qiáng)化存儲(chǔ)系統(tǒng)的可用性（A）和伸縮性（P），在某種程度上放棄一致性（C）。

CPA 原理告訴我們：在系統(tǒng)設(shè)計(jì)開發(fā)的過程中，如果不恰當(dāng)?shù)赜细鞣N需求，就會(huì)使設(shè)計(jì)進(jìn)入兩難境地，難以為繼。

數(shù)據(jù)的一致性有這幾個(gè)級(jí)別：

• 數(shù)據(jù)強(qiáng)一致 - 各個(gè)副本的數(shù)據(jù)在物理存儲(chǔ)中總是一致的。
• 數(shù)據(jù)用戶一致 - 各個(gè)副本的數(shù)據(jù)可能是不一致的，但當(dāng)用戶訪問時(shí)，通過糾錯(cuò)和校驗(yàn)機(jī)制，可以確定一個(gè)一致的、正確的數(shù)據(jù)返回給用戶。
• 數(shù)據(jù)最終一致 - 這是數(shù)據(jù)一致性中最弱的一種。系統(tǒng)經(jīng)過一段時(shí)間（比較短的時(shí)間）的自我修復(fù)，數(shù)據(jù)會(huì)達(dá)到最終的一致。

數(shù)據(jù)強(qiáng)一致很難達(dá)到，所以網(wǎng)站會(huì)綜合考慮成本、技術(shù)、業(yè)務(wù)場(chǎng)景等因素，使用數(shù)據(jù)監(jiān)控和糾錯(cuò)功能，達(dá)到“數(shù)據(jù)用戶一致”。

5.2 備份數(shù)據(jù)

早期的數(shù)據(jù)備份主要是冷備份，即定期地將數(shù)據(jù)復(fù)制到存儲(chǔ)介質(zhì)中（磁帶、光盤等）并物理存檔保存。

冷備份的優(yōu)點(diǎn)是簡(jiǎn)單、廉價(jià)。缺點(diǎn)是不能保證數(shù)據(jù)最終一致。因?yàn)閿?shù)據(jù)是定期復(fù)制，所以備份設(shè)備中的數(shù)據(jù)比系統(tǒng)的數(shù)據(jù)來的舊，如果系統(tǒng)數(shù)據(jù)發(fā)生丟失，那么從上一個(gè)備份點(diǎn)開始后，更新的數(shù)據(jù)就會(huì)永久丟失，不能恢復(fù)。

冷備份作為一個(gè)傳統(tǒng)的數(shù)據(jù)保護(hù)手段，依然在網(wǎng)站日常運(yùn)維中使用。但還需要進(jìn)行數(shù)據(jù)熱備份，以提供更好的數(shù)據(jù)可用性。

數(shù)據(jù)熱備份有兩種：異步熱備和同步熱備。

5.2.1 異步熱備

異步熱備指的是，使用異步方式寫入多個(gè)數(shù)據(jù)副本。應(yīng)用收到存儲(chǔ)系統(tǒng)的寫操作成功響應(yīng)時(shí)，實(shí)際上只成功寫入了一份，其他副本由存儲(chǔ)系統(tǒng)異步寫入（可能會(huì)失?。?/p>

異步熱備

存儲(chǔ)服務(wù)器分為主服務(wù)器（Master ）和從服務(wù)器（Slave ）。應(yīng)用只連接到主服務(wù)器。寫入數(shù)據(jù)時(shí)，由主服務(wù)器上的寫操作代理模塊，把數(shù)據(jù)寫入本機(jī)后立即返回寫操作成功響應(yīng)，然后通過異步線程把寫操作的數(shù)據(jù)同步到存儲(chǔ)服務(wù)器。

關(guān)系型數(shù)據(jù)庫的熱備機(jī)制就是 Master-Slave 同步機(jī)制。這樣不但實(shí)現(xiàn)了數(shù)據(jù)備份，還改善了性能。因?yàn)樵趯?shí)踐中，通常采用讀寫分離的方法來訪問數(shù)據(jù)庫。寫操作只訪問 Master 數(shù)據(jù)庫，讀操作只訪問 Slave 數(shù)據(jù)庫。

5.2.2 同步熱備

同步熱備指的是，同步寫入多個(gè)數(shù)據(jù)副本，都寫入成功后，應(yīng)用才會(huì)收到寫成功響應(yīng)。如果應(yīng)用收到寫失敗響應(yīng)時(shí)（網(wǎng)絡(luò)或系統(tǒng)故障），可能有部分或全部副本都已寫入成功，這時(shí)就要進(jìn)行糾錯(cuò)咯。

同步熱備

為了提高性能，應(yīng)用的客戶端會(huì)并發(fā)地向多個(gè)存儲(chǔ)服務(wù)器同時(shí)寫入數(shù)據(jù)，然后等待所有的存儲(chǔ)服務(wù)器都返回操作成功的響應(yīng)后，才會(huì)通知應(yīng)用寫操作成功。

這里的存儲(chǔ)服務(wù)器是完全對(duì)等，這樣有利于管理與維護(hù)?？偟膶懖僮餮舆t是那個(gè)響應(yīng)最慢的存儲(chǔ)服務(wù)器。

不管是關(guān)系型數(shù)據(jù)庫還是 NoSQL 數(shù)據(jù)庫，都提供了數(shù)據(jù)實(shí)時(shí)備份功能。

5.3 失效轉(zhuǎn)移

失效轉(zhuǎn)移指的是，服務(wù)器集群中，如果任何一臺(tái)服務(wù)器宕機(jī)，那么應(yīng)用所針對(duì)這臺(tái)服務(wù)器的所有讀寫操作，都需要重新路由到其他服務(wù)器，保證服務(wù)依然是可用的。

失效轉(zhuǎn)移有這些部分：

1.失效確認(rèn)

系統(tǒng)通過心跳檢測(cè)和應(yīng)用訪問失敗的報(bào)告來確認(rèn)某臺(tái)服務(wù)器是否宕機(jī)：

確認(rèn)失效的機(jī)制

對(duì)于應(yīng)用程序的訪問失敗報(bào)告，控制中心還需要再發(fā)送一次心跳檢測(cè)對(duì)服務(wù)器進(jìn)行確認(rèn)，以免應(yīng)用程序判斷錯(cuò)誤。因?yàn)橐坏┻M(jìn)行失效轉(zhuǎn)移，就會(huì)出現(xiàn)存儲(chǔ)的多份數(shù)據(jù)副本不一致，那么后續(xù)就要對(duì)這種情況進(jìn)行一系列復(fù)雜的糾錯(cuò)操作。

2. 訪問轉(zhuǎn)移

確認(rèn)服務(wù)器宕機(jī)后，就要把數(shù)據(jù)的讀寫訪問重新路由到其他的服務(wù)器上。這又分為兩種情況：

• 存儲(chǔ)完全對(duì)等：直接切換到對(duì)等服務(wù)器上。
• 存儲(chǔ)不對(duì)等：重新計(jì)算路由，選擇健康的服務(wù)器。

3. 數(shù)據(jù)恢復(fù)

某臺(tái)服務(wù)器宕機(jī)后，數(shù)據(jù)存儲(chǔ)的副本就會(huì)減少，這時(shí)系統(tǒng)會(huì)從健康的服務(wù)器上復(fù)制數(shù)據(jù)，把副本的數(shù)目恢復(fù)到系統(tǒng)設(shè)定的值。

6 高可用質(zhì)量保證

6.1 發(fā)布網(wǎng)站

網(wǎng)站的發(fā)布實(shí)際上與服務(wù)器的宕機(jī)效果相當(dāng)，因?yàn)樾枰P(guān)閉服務(wù)器上原有的應(yīng)用，然后重新部署啟動(dòng)新的應(yīng)用。
但網(wǎng)站的發(fā)布畢竟是一次提前預(yù)知的“服務(wù)器宕機(jī)”，因?yàn)檫^程可以更柔和，對(duì)用戶的影響可以更小。我們通常使用腳本來完成發(fā)布。

網(wǎng)站發(fā)布流程

因?yàn)槊看侮P(guān)閉的服務(wù)器只是集群中的一小部分，而且在發(fā)布完成后可以立即訪問，所以整個(gè)發(fā)布過程并不影響用戶的使用。

6.2 自動(dòng)化測(cè)試

代碼在發(fā)布到服務(wù)器之前需要進(jìn)行嚴(yán)格的測(cè)試。即使發(fā)布的新功能都是在原有系統(tǒng)的功能上進(jìn)行小幅的增加，也需要對(duì)整個(gè)網(wǎng)站功能進(jìn)行全面的回歸測(cè)試。此外，還要針對(duì)各種瀏覽器進(jìn)行兼容性測(cè)試。

大部分網(wǎng)站都是采用 Web 自動(dòng)化測(cè)試技術(shù)。比較流行的是 Selenium。它運(yùn)行于瀏覽器，可以模擬用戶的操作進(jìn)行測(cè)試，因此 Selenium 可以同時(shí)完成 Web 功能測(cè)試和瀏覽器兼容性測(cè)試。

大型網(wǎng)站會(huì)開發(fā)自有的自動(dòng)化測(cè)試工具，實(shí)現(xiàn)一鍵部署、生成測(cè)試數(shù)據(jù)、執(zhí)行測(cè)試和生成測(cè)試報(bào)告等測(cè)試過程。測(cè)試工程師的編碼能力毫不遜于軟件工程師哦O(∩_∩)O~

6.3 預(yù)發(fā)布過程

即使經(jīng)過了嚴(yán)格測(cè)試，部署到現(xiàn)網(wǎng)后還是有可能出現(xiàn)問題。因?yàn)闇y(cè)試環(huán)境與現(xiàn)網(wǎng)環(huán)境不同，特別是應(yīng)用可能會(huì)依賴的其他服務(wù)，諸如數(shù)據(jù)庫、緩存以及第三方的服務(wù)（短信網(wǎng)關(guān)、網(wǎng)銀接口等）。

因此在發(fā)布時(shí)，可以先把包發(fā)布到 “預(yù)發(fā)布服務(wù)器” 上，這樣開發(fā)與測(cè)試工程師就可以在預(yù)發(fā)布服務(wù)器進(jìn)行驗(yàn)證咯，一般會(huì)測(cè)試一些典型的業(yè)務(wù)流程，確認(rèn)系統(tǒng)沒有問題后才會(huì)正式發(fā)布。

預(yù)發(fā)布服務(wù)器與正式服務(wù)器的不同之處是：外部用戶無法訪問（沒有配置在負(fù)載均衡服務(wù)器上）。

預(yù)發(fā)布

預(yù)發(fā)布服務(wù)器與線上的正式服務(wù)器部署在相同的物理環(huán)境上（同一個(gè)數(shù)據(jù)中心或同一個(gè)機(jī)架，如果使用虛擬機(jī)，甚至可以部署在同一個(gè)物理服務(wù)器上），使用相同的線上配置，依賴同樣的外部服務(wù)。工程師在開發(fā)機(jī)上配置 hosts 文件綁定域名，這樣就可以訪問到預(yù)發(fā)布服務(wù)器咯。如果預(yù)發(fā)布服務(wù)器執(zhí)行的驗(yàn)證通過的話，基本上可以確保部署到線上的正式服務(wù)器沒有問題。

但有可能會(huì)因?yàn)轭A(yù)發(fā)布驗(yàn)證而引入新的問題。因?yàn)轭A(yù)發(fā)布服務(wù)器連接的是真實(shí)的生產(chǎn)環(huán)境，所以，所有的預(yù)發(fā)布驗(yàn)證操作的都是真實(shí)有效的數(shù)據(jù)，這些操作會(huì)引起某些不可預(yù)期的問題。比如上架了一個(gè)商品，可能真的會(huì)有用戶過來購買，如果不能發(fā)貨，那就慘了哦。

注意：在應(yīng)用中應(yīng)該強(qiáng)調(diào) “快速失敗” 的錯(cuò)誤理念。即如果在系統(tǒng)啟動(dòng)時(shí)發(fā)現(xiàn)問題就立刻拋出異常，讓工程師可以盡快介入解決問題。

6.4 代碼控制

代碼控制的核心問題是如何進(jìn)行代碼管理，即能保證代碼發(fā)布的版本穩(wěn)定正確，又能保證不同團(tuán)隊(duì)的開發(fā)互不影響。

目前大部分網(wǎng)站的源代碼版本控制工具是 SVN 與 Git。

SVN 的代碼控制發(fā)布的方式有兩種：

1. 主干開發(fā)、分支發(fā)布

修改都在主干（trunk）上進(jìn)行，在需要發(fā)布的時(shí)候，從主干上拉出一個(gè)分支（branch）發(fā)布，這個(gè)分支就是一個(gè)發(fā)布版本，如果這個(gè)版本發(fā)現(xiàn)了 bug，就繼續(xù)在該分支上修改發(fā)布，并將修改合并（merge）回主干，直到下一次發(fā)布。

2. 分支開發(fā)、主干發(fā)布

任何修改都不得在主干上進(jìn)行。需要開發(fā)新功能或修復(fù) bug 時(shí)，就從主干上拉下一個(gè)分支進(jìn)行開發(fā)，開發(fā)完成并測(cè)試通過后，合并回主干，然后從主干上發(fā)布，主干上的代碼永遠(yuǎn)是最新發(fā)布的版本。

“主干開發(fā)、分支發(fā)布” 的方式，主干代碼反映的是目前應(yīng)用的狀態(tài)，便于管理和控制，也有利于持續(xù)集成。
“ 分支開發(fā)、主干發(fā)布” 的方式，各個(gè)分支獨(dú)立進(jìn)行，互不干擾，因此可以同時(shí)進(jìn)行不同發(fā)布周期的執(zhí)行過程。

目前網(wǎng)站應(yīng)用主要使用的是 “ 分支開發(fā)、主干發(fā)布” 的方式：

分支開發(fā)、主干發(fā)布

同一個(gè)應(yīng)用，有可能 A 項(xiàng)目發(fā)布時(shí)， B 項(xiàng)目還在開發(fā)中，那么“ 分支開發(fā)、主干發(fā)布” 的方式，只需要將 A 項(xiàng)目的分支合并回主干即可，這樣可以不受 B 項(xiàng)目發(fā)布時(shí)間的影響。

Git 目前正逐步取代 SVN。雖然 Git 學(xué)習(xí)成本較高，但它對(duì)分布式開發(fā)和分支開發(fā)等有更好的支持，而且可以更容易在各個(gè)開發(fā)分支上及時(shí)反映出主干上的最新更新（代碼變得更容易合并啦）。相信 Git 遲早會(huì)成為網(wǎng)站標(biāo)準(zhǔn)版本的控制工具。

6.5 自動(dòng)化發(fā)布

很多網(wǎng)站選擇周四作為發(fā)布日，這樣一周的前三天可以做好發(fā)布準(zhǔn)備，后面一天可以挽回錯(cuò)誤。如果選擇的是周五，那么如果發(fā)現(xiàn)了問題，就必須周末來加班咯。

使用 “火車發(fā)布模型” 可以有效地控制發(fā)布故障、減少發(fā)布日的加班問題。

火車發(fā)布模型是這樣的：可以把應(yīng)用的發(fā)布過程看做是一次火車旅行。旅行路線上有若干個(gè)站點(diǎn)，每一站都要進(jìn)行例行檢查。不通過的項(xiàng)目就下車，剩下的項(xiàng)目繼續(xù)旅行，直到達(dá)到終點(diǎn)（應(yīng)用發(fā)布成功）。

火車發(fā)布模型是基于規(guī)則驅(qū)動(dòng)的流程，所以可以自動(dòng)化。因?yàn)槿斯じ深A(yù)的越少，自動(dòng)化程度就會(huì)越高，引入故障的可能性也就越小。

6.6 灰度發(fā)布

應(yīng)用發(fā)布成功后，仍可能因?yàn)檐浖栴}而引入故障。這時(shí)候就要做發(fā)布回滾，即卸載剛剛發(fā)布的軟件，將上一個(gè)版本的軟件包重新發(fā)布，復(fù)原系統(tǒng)。

大型網(wǎng)站的服務(wù)器集群規(guī)模非常大，有的甚至超過一萬臺(tái)。一旦發(fā)生故障，回滾也需要花費(fèi)很長(zhǎng)的時(shí)間才能完成。所以大型網(wǎng)站一般使用灰度發(fā)布模式：即把集群服務(wù)器分為若干部分，每天只發(fā)布一部分服務(wù)器，觀察運(yùn)行穩(wěn)定沒有出現(xiàn)故障，那么第二天再繼續(xù)發(fā)布另一部分的服務(wù)器，這樣持續(xù)幾天才會(huì)把整個(gè)集群都發(fā)布完畢。期間如果發(fā)現(xiàn)問題，就只需要回滾那些已發(fā)布的那部分服務(wù)器就好啦O(∩_∩)O~

灰度發(fā)布模型

灰度發(fā)布模型也常用于用戶測(cè)試，即在部分服務(wù)器上發(fā)布新版本，其余服務(wù)器保持舊版本，然后監(jiān)控用戶的操作行為，通過用戶的體驗(yàn)報(bào)告，就可以比較出用戶對(duì)新舊兩個(gè)版本的滿意度，以確定最終的發(fā)布版本。這也被稱為 AB 測(cè)試。

7 運(yùn)行監(jiān)控

沒有被監(jiān)控的系統(tǒng)不能上線！ 因?yàn)檫\(yùn)行監(jiān)控對(duì)于網(wǎng)站運(yùn)維與架構(gòu)設(shè)計(jì)優(yōu)化至關(guān)重要。

7.1 采集監(jiān)控?cái)?shù)據(jù)

1. 收集用戶行為日志

用戶行為日志指的是用戶在瀏覽器所做的所有操作以及用戶所在的操作環(huán)境（操作系統(tǒng)與瀏覽器的版本、IP 地址、頁面訪問路徑、頁面停留時(shí)間等）。

有兩種收集對(duì)象：

• 服務(wù)端日志 - 開啟 web 服務(wù)器的日志記錄即可。缺點(diǎn)是可能出現(xiàn)信息失真，比如 IP 地址可能是代理服務(wù)器的地址。
• 客戶端瀏覽器日志 - 嵌入專門的 JavaScript 腳本就可以收集用戶真實(shí)的操作行為。缺點(diǎn)是麻煩，因?yàn)樾枰陧撁嬷星度胩囟ǖ哪_本。

大型網(wǎng)站的用戶日志數(shù)據(jù)量驚人，數(shù)據(jù)存儲(chǔ)與計(jì)算的壓力都很大，所以許多網(wǎng)站都逐步開發(fā)了基于實(shí)時(shí)計(jì)算框架 Apache Storm 的日志統(tǒng)計(jì)與分析工具。

2.監(jiān)控服務(wù)器性能

運(yùn)維人員在初始化系統(tǒng)時(shí)統(tǒng)一部署，收集服務(wù)器性能指標(biāo)。根據(jù)監(jiān)控到的數(shù)據(jù)，運(yùn)維工程師可以合理安排服務(wù)器的集群規(guī)模，架構(gòu)師可以及時(shí)改善系統(tǒng)的性能和調(diào)整伸縮性策略。

目前使用廣泛的性能監(jiān)控工具是 Ganglia，它支持大規(guī)模的服務(wù)器集群，并支持以圖形的方式在瀏覽器中展示實(shí)時(shí)的性能曲線。

3. 運(yùn)行數(shù)據(jù)報(bào)告

應(yīng)用需要在代碼中加入采集運(yùn)行數(shù)據(jù)的邏輯，匯總后統(tǒng)一顯示。

7.2 監(jiān)控管理

1. 系統(tǒng)報(bào)警

如果監(jiān)控的某項(xiàng)指標(biāo)超過了閾值，那就意味著系統(tǒng)可能將要出現(xiàn)故障，這時(shí)就要對(duì)相關(guān)人員進(jìn)行報(bào)警。

監(jiān)控管理系統(tǒng)可以配置報(bào)警的閾值和值守人員的聯(lián)絡(luò)方式（通過郵件、即時(shí)通信工具、手機(jī)短信等方式），及時(shí)發(fā)出預(yù)警。

2. 失效轉(zhuǎn)移

監(jiān)控系統(tǒng)在發(fā)現(xiàn)故障時(shí)應(yīng)該主動(dòng)通知應(yīng)用，及時(shí)進(jìn)行失效轉(zhuǎn)移。

3. 自動(dòng)優(yōu)雅降級(jí)

優(yōu)雅降級(jí)指的是，網(wǎng)站為了應(yīng)付突發(fā)的訪問高峰，會(huì)主動(dòng)關(guān)閉一部分功能，釋放系統(tǒng)資源。

自動(dòng)優(yōu)雅降級(jí)的監(jiān)控系統(tǒng)是一種柔性架構(gòu)的理想狀態(tài)：監(jiān)控系統(tǒng)會(huì)實(shí)時(shí)監(jiān)控所有的服務(wù)器，如果發(fā)現(xiàn)某部分的應(yīng)用負(fù)載過高，那么就會(huì)適當(dāng)卸載低負(fù)載應(yīng)用的一部分服務(wù)器，重新安裝啟動(dòng)高負(fù)載的應(yīng)用，使得應(yīng)用負(fù)載總體均衡。如果所有應(yīng)用的負(fù)載都很高，那么就會(huì)自動(dòng)關(guān)閉一部分非重要的功能，保證核心功能的正常運(yùn)行。

對(duì)公司而言，可用性關(guān)系到了網(wǎng)站的生死存亡；對(duì)個(gè)人而言，可用性關(guān)系到了個(gè)人的績(jī)效升遷。所以一定要重視呀O(∩_∩)O~