高可用設計

高可用性（High Availability）通常用來描述一個系統經過專門的設計，減少了停工時間，並保證了其服務的高度可用性，簡而言之，就是不間斷地對外提供服務。

高可用性的度量與考核

對高可用性度量的公式為：

◎ 網站不可用時間（故障時間）=故障修復時間點-故障發現（報告）時間點；

◎ 網站年度可用性指標=（1-網站不可用時間/年度總時間）×100%。

業界通常用多個9來衡量網站的可用性，如下所述。

◎ 2個9：表示基本可用，不可用時間少於88小時。

◎ 3個9：表示較高可用，不可用時間少於9小時。

◎ 4個9：表示具有自動恢復能力的高可用，不可用時間少於53分鐘。

◎ 5個9：表示極度高可用，不可用時間少於5分鐘。

可用性指標是網站架構設計的重要指標，對外是服務承諾，對內是考核指標。從管理層面來看，可用性指標是網站或系統架構的整體考核指標，具體到每個工程師的考核，更多地使用故障分。故障分是指對網站故障進行分類加權計算故障責任的方法，如表5.1所示。

表5.1

故障分的計算公式：故障分=故障時間（分鐘）×故障權重。

高可用的架構

典型的網站設計遵循基本分層架構模型：應用層（處理具體的業務邏輯）、服務層（提供可複用的服務）、資料層（資料的儲存和訪問）。

1.高可用的應用層

應用層主要處理業務邏輯，一個顯著特點是應用的無狀態性。

所謂無狀態是指應用伺服器不儲存業務的上下文資訊，而僅根據每次請求提交的資料進行相應的業務邏輯處理，多個服務例項（伺服器）之間完全對等，請求被提交到任意伺服器後，處理結果都是完全一樣的。

高可用的應用層的第1個特點是透過負載均衡實現失效轉移。

在業務量和資料量都較高的情況下，透過負載均衡，可以將流量和資料都分攤到一個叢集所組成的多臺伺服器上，以提高整體的處理能力。目前的負載均衡軟、硬體都提供了失效轉移功能。所以，如果叢集的服務是無狀態的對等服務，則負載均衡技術可以保證系統的高可用性。

當 We b 伺服器叢集中的伺服器都可用時，負載均衡伺服器會將訪問請求分發給任意一臺伺服器進行處理。負載均衡伺服器會透過心跳檢測機制，在發現某臺伺服器（如圖5.8所示的Web伺服器-001）失去響應時，將該伺服器從伺服器列表中剔除。為了保證高可用性，即使某個應用的訪問量非常少，也必須部署至少兩臺伺服器，透過負載均衡構建一個小型叢集。

可以看出，高可用的應用層的第2個特點是伺服器叢集中的Session管理。

業務總是有狀態的，比如交易類網站需要有購物車記錄使用者購買的商品。在 We b 應用中，這些狀態就被稱為Session。在單機情況下，Session可以由部署在伺服器上的Web容器（如Tomcat）進行統一管理。但在使用負載均衡的叢集環境中，要保證每次請求都能夠獲得正確的Session就是個很複雜的話題。在叢集環境中，有如下手段可以進行Session管理。

圖5.8

（1）複製Session。應用伺服器開啟Web容器的Session複製功能，然後在叢集中的幾臺伺服器之間同步Session物件，使得每臺伺服器都儲存所有使用者的Session資訊。

（2）繫結Session。利用負載均衡的源地址Hash演算法，將源於同一IP的請求分發到同一臺伺服器上。這樣，在整個會話期間，使用者的所有請求就都在同一臺伺服器上進行處理，即把 Session 繫結到某臺特定的伺服器上，這種方法又被稱為“會話粘滯”。繫結 Session的方案不符合系統高可用性的需求，因為一旦某臺伺服器宕機，該伺服器上的 Session 就不存在了。即使將使用者的請求切換到其他伺服器，也會因為沒有 Session 而導致業務無法正常處理。所以很少有網站使用繫結Session的方案。

（3）利用 Cookie 記錄 Session。這種方式是將 Session 記錄在客戶端，在每次請求伺服器時，都將Session放在請求中傳送給伺服器，在伺服器處理後，再將修改過的Session傳送回客戶端。利用Cookie記錄Session也有一些缺點，如下所述。

◎ Cookie有大小限制，記錄的資訊有限。◎ 每次請求響應都要傳輸Cookie，影響效能。

◎ 如果使用者關閉了Cookie，訪問就會變得不正常。

但 Cookie 簡單易用，能夠支援應用伺服器的線性伸縮；而且大部分應用需要記錄的Session資訊又比較小。所以許多網站都或多或少地使用Cookie記錄Session。

（4）Session伺服器。利用獨立部署的Session伺服器或叢集來統一管理Session。應用伺服器在每次讀寫Session時，都需要訪問Session伺服器。這樣的方案是把應用伺服器分為無狀態的應用伺服器和有狀態的Session伺服器。對於有狀態的Session伺服器，可以這樣簡單實現：在分散式快取、資料庫等元件的基礎上進行封裝，使其符合 Session 的儲存與訪問要求。

2.高可用的服務層

可複用的服務模組為業務產品提供基礎公共服務，通常都獨立分散式部署，被具體應用遠端呼叫。可複用的服務和應用一樣，也是無狀態的服務，因此可以使用類似負載均衡的失效轉移策略實現高可用的服務。

除此之外，具體實踐中，還有如下幾種高可用的服務策略。

（1）分級管理。在運維層面對伺服器進行分級管理，核心應用與服務優先使用更好的硬體。在服務部署上進行必要的隔離，避免故障的連鎖反應。低優先順序的服務透過啟動不同的執行緒或部署在不同的虛擬機器上進行隔離。高優先順序的服務需要部署在不同的物理機上，核心服務和資料最好部署在不同地域的資料中心上。

（2）超時設定。在應用中設定呼叫服務的超時時間，一旦超時，通訊框架就會丟擲異常。應用根據服務排程策略，可以選擇繼續重試或者將請求轉移到提供相同服務的其他伺服器上。

（3）非同步呼叫。應用對服務的呼叫，透過訊息佇列的非同步方式實現。應用程式會將使用者註冊資訊傳送給訊息佇列伺服器，之後立即返回使用者註冊成功的響應。而多個消費者任務（記錄使用者資訊到資料庫、傳送註冊成功郵件、開通許可權）會從訊息佇列中獲取使用者註冊的資訊，之後非同步執行。注意：不是所有的服務呼叫都可以使用非同步呼叫模式，比如獲取使用者資訊的服務或必須確認服務呼叫成功才能繼續下一步操作的服務等，都不適合使用非同步呼叫模式。

（4）服務降級。在網站訪問的高峰期，服務可能因為大量的併發呼叫導致效能下降，嚴重時甚至會導致服務宕機。所以為了保證核心應用與服務的正常執行，我們必須對某些服務進行降級。降級有如下兩種手段。

◎ 拒絕服務：拒絕低優先順序應用的呼叫，減少併發數，以確保核心應用；或隨機拒絕部分請求，以節約資源。

◎ 關閉功能：關閉部分不重要的服務，或關閉服務內不重要的功能，以節約資源。

（5）冪等性設計。應用在呼叫服務失敗後，會將請求傳送給其他伺服器，但這個失敗可能不是真的！比如服務實際上已處理成功，但因為網路故障，應用沒有收到響應，那麼這時應用所重新提交的請求，就是在重複呼叫服務！如果這是一個轉賬服務，那麼後果會很嚴重。重複呼叫服務是不可避免的，所以服務層必須保證重複呼叫服務與呼叫一次服務的結果是相同的，即服務具有冪等性。比如轉賬交易的操作就需要透過交易編號對呼叫的服務進行有效性校驗，保證呼叫是有效的才能繼續執行。

3.高可用的資料層

對於系統而言，最珍貴的資產是多年運營積累下來的資料（使用者資料、交易資料和商品資料等），所以保護了資料就是保護了企業的命脈。而保證資料高可用的手段是資料備份和失效轉移，如下所述。

（1）資料備份：保證資料有多個副本，任意副本的失效都不會導致資料的永久丟失。

（2）失效轉移：當有一個數據副本不可訪問時，可以快速切換到其他副本。

注意：快取服務不是資料儲存服務，快取伺服器宕機引起的快取資料丟失及伺服器負載過高的問題，應該透過其他手段進行解決。可以讓整個網站共享一個分散式快取叢集，應用只需要向共享快取叢集申請快取資源即可，這樣任何一臺快取伺服器宕機所引起的快取失效，都只會影響到快取資料的一小部分，而不會對應用的效能和資料庫負載造成太大的影響。

下面講講 CAP 的原理。為了保證資料的高可用，系統通常會犧牲資料的一致性。高可用的資料有如下幾層含義。

◎ 資料永續性：保證資料可持久儲存，即在將資料寫入可永續性儲存的硬體的同時，將資料備份成一個或多個副本。

◎ 資料可訪問性：將多個數據副本儲存在不同的儲存裝置上，如果一個儲存裝置損壞，就需要將對資料的訪問切換到另一個數據儲存裝置上。這個過程要儘量快，讓客戶不可感知。

◎ 資料一致性：在資料有多個副本的情況下，如果網路、伺服器或軟體出現故障，則會導致部分副本寫入成功，部分寫入失敗，這樣就會造成各個副本之間存在資料不一致的情況。

下面講講備份資料。早期的資料備份主要是冷備份，即定期地將資料複製到儲存介質中（磁帶、光碟等）並進行物理儲存，冷備份的優點是簡單、廉價，缺點是不能保證資料最終一致。因為資料是定期複製的，所以備份裝置中的資料比系統中的資料老，如果系統資料發生丟失，那麼從上一個備份點開始，更新的資料就會永久丟失、不能恢復。冷備份作為一個傳統的資料保護手段，依然在網站日常運維中使用，但還需要進行資料熱備份，以提供更好的資料可用性。資料熱備份有兩種：非同步熱備和同步熱備。

下面講講失效轉移。失效轉移指的是在伺服器叢集中如果有任意一臺伺服器宕機，那麼應用針對這臺伺服器的所有讀寫操作，都需要被重新路由到其他伺服器，保證服務依然是可用的。保證資料高可用性的手段是失效確認、失效轉移和資料恢復。

（1）失效確認。系統透過心跳檢測和應用訪問失敗的報告來確認某臺伺服器是否宕機。對於應用程式的訪問失敗報告，控制中心還需要再發送一次心跳檢測對伺服器進行確認，以免應用程式判斷錯誤。因為一旦進行失效轉移，就會出現儲存的多份資料副本不一致，後續就要對這種情況進行一系列複雜的糾錯操作。

（2）訪問轉移。在確認伺服器宕機後，就要將資料的讀寫訪問重新路由到其他伺服器上。這又分為如下兩種情況。

◎ 儲存完全對等：直接切換到對等伺服器上。

◎ 儲存不對等：重新計算路由，選擇健康的伺服器。

（3）資料恢復。在某臺伺服器宕機後，資料儲存的副本就會減少，這時系統會從健康的伺服器上覆制資料，將副本的數量恢復到系統設定的值。

高可用質量保證

下面會介紹一些保證線上系統的高可用質量的手段。

（1）釋出系統。系統的釋出實際上與伺服器的宕機效果差不多，因為需要關閉伺服器上的原有應用，然後重新部署、啟動新的應用。但系統的釋出畢竟是一次提前預知的“伺服器宕機”，其過程可以更

柔和，對使用者的影響可以更小。因為每次關閉的伺服器只是叢集中的一小部分，而且在釋出完成後可以立即訪問，所以整個釋出過程並不影響使用者的使用。

（2）自動化測試。程式碼在釋出到伺服器之前需要進行嚴格的測試。即使釋出的新功能都在原有系統的功能上進行小幅增加，也需要對整個網站的功能進行全面的迴歸測試。此外，還要針對各種瀏覽器進行相容性測試。大部分系統都採用了We b自動化測試技術。

（3）預釋出過程。即使經過了嚴格測試，在部署到現網後還是有可能出現問題的。因為測試環境與現網環境不同，特別是應用可能會依賴其他服務，例如資料庫、快取及第三方服務（簡訊閘道器、支付介面等），所以在釋出時可以先將包釋出到“預釋出伺服器”上，這樣開發人員與測試人員就可以在預釋出伺服器上進行驗證了。一般會測試一些典型的業務流程，在確認系統沒有問題後才會正式釋出。

（4）程式碼控制。程式碼控制的核心問題是如何進行程式碼管理，既能保證程式碼釋出的版本穩定、正確，又能保證不同團隊的開發互不影響。

（5）很多公司都要求週期性釋出系統，例如要求每週四都是釋出日，在月底、節日前不允許釋出。這樣做是為了避免週末、節假日出現問題時無人解決問題，也避免週末、節假日加班。使用“火車釋出模型“可以有效控制釋出故障，減少釋出日的加班問題。

（6）灰度釋出模型。灰度釋出又叫作AB測試，常被用於觀察使用者體驗或測試新功能，即在線上環境中同時存在新老版本的系統，透過將部分使用者導流到新版本中並監控使用者的操作，來得到使用者體驗報告，這樣就可以比較出使用者對新老系統的滿意度，為運營人員提供最真實的可信度資料。

系統執行監控

我們常常說：“不允許沒有監控的系統上線”。系統執行監控對於系統運維和架構設計最佳化至關重要，沒有監控的系統，是不完整的系統。

（1）採集監控資料。使用者行為日誌指的是使用者在瀏覽器上的所有操作及使用者所在的操作環境（作業系統與瀏覽器的版本、IP 地址、頁面訪問路徑、頁面停留時間等）。大型系統的使用者日誌資料量驚人，資料儲存與計算的壓力都很大，許多網站都逐步開發了基於實時計算框架Apache Storm的日誌統計與分析工具。

（2）監控管理，如下所述。

◎ 系統告警。如果監控的某項指標超過了閾值，就意味著系統可能要出現故障，這時就要對相關人員進行告警。在監控管理系統中可以配置告警閾值和值守人員的聯絡方式（透過郵件、即時通訊工具、手機簡訊等方式），及時發出預警。

◎ 失效轉移。監控系統在發現故障時應該主動通知應用，及時進行失效轉移。

◎ 自動優雅降級。優雅降級指的是網站為了應付突發的訪問高峰，主動關閉一部分功能，釋放系統資源。自動優雅降級的監控系統是一種柔性架構的理想狀態：監控系統會實時監控所有伺服器，如果發現某部分應用負載過高，就會適當解除安裝低負載應用的一部分伺服器，重新安裝和啟動高負載的應用，使應用負載總體均衡。如果所有應用的負載都很高，就會自動關閉一部分不重要的功能，保證核心功能的正常執行。