網站高可用指的就是，在絕大多的時間裏，網站一直處於可以對外提供服務的正常狀態。業界通常使用有多少個“9”來衡量網站的可用性指標，具體的計算公式也很簡單，就是一段時間內（比如一年）網站可用的時間佔總時間的百分比。
我用下面這個表格，列出了四種最常見的可用性等級指標，以及允許的系統不可用時長。
| 可用性等級 | 通俗叫法 | 量化的可用性等級 | 一年中允許的不可用時長 |
|---|---|---|---|
| 基本可用 | 2個9 | 99% | 87.6小時 |
| 較高可用 | 3個9 | 99.9% | 8.8小時 |
| 具備故障自動恢復能力的可用 | 4個9 | 99.99% | 53分鐘 |
| 極高可用 | 5個9 | 99.999% | 5分鐘 |
一般，我們以“年”爲單位來統計網站的可用性等級。“9”的個數越多，一年中允許的不可用時間就越短，當達到5個“9”的時候，系統全年不可用時間只有區區5分鐘，可想而知這個指標非常難達到。
所以一般來講，業界的網站能做到4個“9”，也就是說在一年內只有53分鐘的時間網站是處於不可用狀態，就已經是算是非常優秀了。
另外，可用性指標還有個特點，越往後越難提高，需要付出的經濟成本和技術成本都會呈現類似指數級的增長。因此，在實際的網站架構設計過程中，到底需要做到幾個“9”還需要結合具體的業務要求，以及風險評估來最終確定。
那麼，接下來我就首先和你分析一下造成網站不可用的主要原因，然後再基於這些原因談談我們可以通過哪些對策和方法，將這些造成網站不可用的因素的影響降到最低。
其實，造成網站不可用的主要原因有以下三大類：
-
服務器硬件故障；
-
發佈新應用的過程；
-
應用程序本身的問題。
服務器硬件故障
網站物理架構中，隨機的硬件服務器的故障，比如某臺服務器由於硬件故障宕機，可以說不是偶然，而是必然會發生的。尤其是目前互聯網企業普遍採用的“牲口”模式集羣方案。
而且隨着網站規模不斷擴大，網站後臺的服務器數量也越來越多，所以由硬件故障引起問題的概率也是不斷飆升。
所以，網站的高可用架構設計，需要保障的是即使出現了硬件故障，也要保證系統的高可用。
發佈新應用的過程
網站的新版本發佈過程中，往往會出現需要重新部署新的應用程序版本，然後再重啓服務的情況。如果這個更新過程中不採用特殊技術手段的話，也會造成短暫的服務不可用。而且這種形式的不可用，相比服務器硬件故障的不可用更爲常見。
原因很簡單，互聯網網站的功能更新迭代非常快，基本都是以“天”爲單位來發布上線的，也就是說幾乎每天都有需要中斷服務來完成服務升級的可能。
顯然，從業務角度來看，這種爲了應用升級造成的服務不可用，完全不可能被接受。這就好比eBay或者淘寶告訴你說，我們每天某個時間段需要內部升級維護無法對外提供服務一樣，讓人無法接受。
從網站可用性指標的角度來看，這種頻繁出現的停機升級過程將大大增加網站的不可用時間。因此，我們的高可用架構設計必須能夠提供切實可行的方案，將這種停機升級的影響降到最小。
應用程序本身的問題
造成網站不可用的最後一個原因是，應用程序本身的問題。
比如，發佈的應用程序版本身存在潛在的內存泄露，那麼經過較長時間的運行積累後，最終會造成服務器的內存被佔滿，之後必須要靠重啓服務來恢復。那麼，這個時候就會引入短暫的服務不可用時間。
再比如，應用程序在測試環境沒有經過充分的測試驗證，或者說由於測試環境的配置和實際生產環境之間存在差異，有可能造成應用程序在生產環境部署完後無法使用的情況，從而造成服務不可用。
由此可見，應用程序在上線發佈前進行充分、全面的測試，是多麼的重要。無論是立竿見影就能發現的功能缺陷，還是需要長期運行才能暴露的軟件問題，都可以通過軟件測試去發現，然後反饋給開發人員去解決，從而避免造成系統的不可用。同時，我們也需要儘可能減少測試環境和生產環境的差異，儘可能採用完全相同的環境以及第三方依賴。
網站高可用架構設計
爲了系統性地解決造成系統不可用的上述三類問題，提高網站的可用性，我們在網站高可用架構設計上，探索出了對應的三類方法。
- 第一類方法是，從硬件層面加入必要的冗餘；
- 第二類方法是，灰度發佈；
- 第三類方法是，加強應用上線前的測試，或者開啓預發佈驗證。
對於第一類硬件故障造成的網站不可用，最直接的解決方案就是從硬件層面加入必要的冗餘，同時充分發揮集羣的“牲口”優勢。
比如，對於應用服務器來說，即使沒有伸縮性的要求，我們也會至少採用兩臺同樣的服務器，並且引入一臺額外的負載均衡器，所有的外部請求會先到負載均衡器，然後由負載均衡器根據不同的分配算法選擇其中的某一臺服務器來提供服務。
備註：伸縮性是指通過增加或減少服務器的數量，就可以擴大或者減小網站整體處理能力。我會在下一篇文章中和你詳細分享。
這樣，當其中一臺服務器硬件出現問題甚至宕機的時候，另一服務器可以繼續對外提供服務。這時，在外部看來系統整體依然是可用的，這就給恢復那臺故障服務器提供了時間。而兩臺服務器同時出現硬件故障的概率是很低的。
因此，從測試人員的角度來看，知道了應用服務器集羣的工作原理，就可以在設計測試的時候，針對集羣中的某一個或者某幾個節點的故障情況設計測試用例。
再比如，對於數據存儲的服務器來說，往往通過數據冗餘備份和失效轉移機制來實現高可用。爲了防止存儲數據的服務器發生硬件故障而造成數據丟失，我們往往會引入多個數據存儲服務器，並且會在數據有更新操作的時候自動同步多個數據存儲服務器上的數據。
也就是說，數據的存儲存在多個副本，那麼當某臺數據存儲服務器故障的時候，我們就可以快速切換到沒有故障的服務器，以此保證數據存儲的高可用。
那麼，從測試人員的角度來看，我們依舊可以針對這種情況設計出針對部分數據服務器發生故障時的測試用例，以完成系統應對故障的反應情況的測試。
對於第二類由於發佈新應用造成的系統不可用，我們採用的主要技術手段是灰度發佈。
使用灰度發佈的前提是，應用服務器必須採用集羣架構。假定現在有一個包含100個節點的集羣需要升級安裝新的應用版本，那麼這個時候的更新過程應該是：
- 首先，從負載均衡器的服務器列表中刪除其中的一個節點；
- 然後，將新版本的應用部署到這臺刪除的節點中並重啓該服務；
- 重啓完成後，將包含新版本應用的節點重新掛載到負載均衡服務器中，讓其真正接受外部流量，並嚴密觀察新版本應用的行爲；
- 如果沒有問題，那麼將會重複以上步驟將下一個節點升級成新版本應用。如果有問題，就會回滾這個節點的上一個版本。
- 如此反覆，直至集羣中這100個節點全部更新爲新版本應用。
在這個升級的過程中，服務對外來看一直處於正常狀態，宏觀上並沒有出現系統不可用的情況。就好比是爲正在飛行中的飛機更換引擎，而飛機始終處於“正常飛行”的狀態一樣。
對於第三類應用程序本身的問題造成的系統不可用，我們一方面要加強應用程序上線部署前的測試以保證應用本身的質量，另一方面需要啓用所謂的預發佈驗證。
我們一定遇到過這樣的尷尬情況：應用在測試環境中經過了完整、全面的測試，並且所有發現的缺陷也已經被修復並驗證通過了，可是一旦發佈到了生產環境，還是立馬暴露出了很多問題。
這其中的主要原因是，測試環境和生產環境存在差異。比如，網絡環境的限制可能不一樣；再比如，依賴的第三方服務也可能不一樣，測試環境連接的是第三方服務的沙箱環境，而生產環境連接的是真實環境。
爲了避免這類由於環境差異造成的問題，我們往往會預發佈服務器。預發佈服務器和真實的服務所處的環境沒有任何差別，連接的第三方服務也沒有任何差別，唯一不同的是預發佈服務器不會通過負載均衡服務器對外暴露，只有知道其IP地址的內部人員纔可以對其進行訪問。
此時，我們就可以藉助自動化測試來對應用做快速的驗證測試。如果測試通過，新的應用版本就會進入到之前介紹的灰度發佈階段。這種做法，可以盡最大可能保證上線應用的可用性。
總結
今天我和你分享了衡量網站高可用性的指標，對於一些大型網站來說，達到4個“9”（即99.99%，一年中的不可用時間不超過53分鐘）已經算是優秀了。
然後，我將影響網站高可用的因素歸爲了三類，並相應地給出瞭解決這三類問題的方案：
-
由服務器硬件故障引起的網站不可用，對應的解決方案是從硬件層面加入必要的冗餘；
-
由發佈新應用的過程引入的網站不可用，對應的解決方案是採用灰度發佈的技術手段；
-
由應用本身質量引入的網站不可用，對應的解決方案是，一方面加強測試提高應用本身的質量，另一方面是引入預發佈服務器消除測試環境和生產環境的差異。