高可用——軟件質量保證

在網站運維實踐中，除了網絡、服務器等硬件故障致使的系統可用性風險外，還有來自軟件系統自己的風險。

下面會介紹一些爲了保證線上系統的可用而採起的一些與傳統軟件按開發不一樣的質量保證。

 

1.網站發佈

網站須要保證7x24高可用運行，同時網站又須要不斷地發佈新功能吸引用戶以保證在激烈的市場競爭中得到成功。

許多大型網站每週都須要發佈一到兩次，而中型網站則更加頻繁，一些處於快速發展期的網站甚至天天發佈十幾回。

 

無論發佈的新功能是修改了一個按鈕的佈局仍是增長了一個核心業務，都須要在服務器上關閉原有的應用，

而後從新部署啓動新的應用，整個過程還要求不影響用戶的使用。

這至關於要求給飛行中的飛機換個引擎，既不能讓飛機有劇烈晃動（影響用戶體驗），

也不能讓飛機降落（系統停機維護），更不能讓飛機墜毀（系統故障網站徹底不可用）。

 

網站的發佈過程事實上和服務器宕機效果至關，其對系統可用性的影響也和服務器宕機類似。

因此設計一個網站的高可用架構時，須要考慮的服務器宕機機率不是物理上的每一年一兩次，而是事實上的每週一兩次。

也許你認爲這個應用不重要，重啓也很是塊，用戶能夠忍受每一年一到兩次的宕機故障，於是不須要複雜的高可用設計。

事實上，因爲應用的不斷髮布，用戶須要面對的是每週一到兩次的宕機故障。

 

可是網站發佈畢竟是一次提早預知的服務器宕機，因此過程能夠更柔和，對於用戶影響更小，一般使用發佈腳原本完成發佈，流程以下：

發佈過程當中，每次關閉服務的服務器都是集羣中的一小部分，並在發佈完成後當即能夠訪問，所以整個發佈過程不影響用戶使用。

 

 

2.自動化測試

代碼在發佈到線上服務器以前須要進行嚴格的測試。

即便每次發佈的新功能都在原有系統功能上的小幅增長，但爲了保證系統沒有引入未預料的Bug，網站測試仍是須要對整個網站功能進行全面的迴歸測試。

此外還須要測試各類瀏覽器的兼容性，在發佈頻繁的網站應用中，若是使用人工測試，成本、時間及測試覆蓋率都難以接受。

 

目前大部分網站都採用Web自動化測試技術，使用自動測試工具或腳本完成測試。

比較流行的Web自動化測試工具是ThoughtWorks開發的Selenium。

Selenium運行在瀏覽器中，所以Selenium能夠同時完成Web功能測試和瀏覽器兼容測試。

 

大型網站一般也會開發本身的自動化測試工具，能夠一鍵完成系統部署，測試數據生成、測試執行、測試報告生成等所有測試過程。

許多網站測試工程師的編碼能力絕不遜色於軟件工程師。

 

3.預發佈驗證

即便是通過嚴格的驗證，軟件不是到線上服務器以後仍是會常常出現各類問題，甚至根本沒法啓動服務器。

主要緣由是測試環境和線上環境並不相同，特別是應用須要依賴的其餘服務，

如數據庫、緩存、公共業務服務等，以及一些第三方服務，如電信短信網關、銀行網銀接口等。

 

也許是數據庫表結構不一致，也許是接口變化致使的通訊失敗，也許是配置錯誤致使鏈接失敗，

也許是依賴的服務線上環境尚未準備好，這些問題都有可能致使應用故障。

 

所以在網站發佈時，並非直接把測試經過的代碼包直接發佈到線上服務器，而是先發布到預發機器上，

開發工程師和測試工程師在預發佈服務器上進行預發佈驗證，執行一些典型的業務流程，確認系統沒有問題後才正式發佈。

 

預發佈服務器是一種特殊用途的服務器，它和線上的正式服務器惟一的不一樣就是沒有配置在負載均衡服務器上，外部用戶沒法訪問。

預發佈服務器和線上正式服務器都部署在相同的物理環境，

同一個數據中心甚至同一個機架上，若是使用虛擬機，甚至可能在同一臺物理服務器上，使用相同的線上配置，依賴相同的線上環境。

網站工程師經過在本身的開發機上配置hosts文件綁定域名IP關係直接使用IP地址訪問預發佈服務器。

若是在預發佈服務器上執行的測試是成功的，基本能夠保證在線上正是服務器部署時也沒有問題。

 

不過，也有可能會由於預發佈驗證而引入問題。

由於預發佈服務器鏈接的是真實的環境，全部預發佈驗證操做都是真實有效的數據，這些操做也許會引發不可預期的問題。

好比建立一個店鋪，上架一個商品，就有可能有真的用戶過來購買，若是不能操做，就會致使用戶投訴。

 

此外，在網站應用中強調的一個處理錯誤的理念是快速失敗（fast failed），即系統若是在啓動時發現問題就馬上拋出異樣，

中止啓動讓工程師介入排查錯誤，而不是啓動後執行錯誤的操做。

 

4.代碼控制

對於大型網站，核心應用系統和公共業務模塊涉及許多團隊和工程師，須要對相同的代碼庫進行共同開發和維護。

而這些團隊對同一個應用的開發維護（開發週期和發佈時間各不相同），若是代碼控制環節出了問題，

可能將有問題的代碼發佈上線，將問題帶入生產環節，致使系統故障。

 

網站代碼控制的核心問題是如何進行代碼管理，既能保證代碼發佈版本的穩定正確，同時又能保證不一樣團隊的開發互不影響。

目前大部分網站使用的源代碼版本控制工具是SVN，SVN代碼控制和版本發佈方式通常有如下兩種。

（1）主幹開發、分支發佈

代碼修改都在主幹（trunk）上進行，須要發佈的時候，從主幹上拉一個分支（branch）發佈，

即分支成爲一個發佈版本，若是該版本發現Bug，繼續在該分支上修改發佈，將修改合併（merge）回主幹，直到下次主幹發佈。

（2）分支開發、主幹發佈

任何修改都不得在主幹上直接進行，須要開發一個新功能或者修復一個Bug時，從主幹拉一個分支進行開發，

開發完成且經過測試後，合併回主幹，而後從主幹進行發佈，主幹上的代碼永遠是最新發布的版本。

這兩種方式各有優缺點。

主幹開發、分支發佈方式，主幹代碼反應目前整個應用的狀態，一目瞭然，便於管理和控制，也利於持續集成。

分支開發、主幹發佈方式，各個分支獨立進行，互不干擾，可使不一樣發佈週期的開發在同一應用中進行。

 

目前網站應用開發中主要使用的是分支開發、主幹發佈的方式。

能夠想象，若是使用主幹開發、分支發佈，那麼在同一個應用上，對於不一樣開發週期，不一樣發佈時間的項目，

有可能A項目發佈時，B項目只開發了一半，這時候的主幹代碼是半成品，根本不能發佈。

而使用分支開發、主幹發佈的方式，只須要將A項目的分支合併到主幹便可發佈，不受B項目發佈時間的影響。

 

目前在開源技術社區，Git做爲版本控制工具，正逐步取代SVN的地位。

Git對分佈式開發、分支開發等有更好的支持，也更容易在各個開發分支上及時反應主幹最新跟新，

避免SVN在最後提交代碼時發現主幹代碼差異太大難以merge成功。

若是想查看更多GIt和SVN的區別，請訪問另外一篇博客：http://www.cnblogs.com/yangmingxianshen/p/8361369.html

 

5.自動化發佈

網站版本發佈頻繁，整個發佈過程須要許多團隊通力合做，發佈前，多個代碼分支合併回主幹可能發生衝突（conflict），

預發佈驗證也會帶來風險，每次發佈又至關於一次宕機事故。所以網站發佈過程當中荊棘叢生，一不當心就會踩雷區。

 

對於有固定發佈日期的網站，不少網站選擇週四做爲發佈日，這樣一週前面有三天時間能夠準備發佈，

後面還有一天能夠挽救錯誤，若是選擇週五發佈，發現問題就須要加班加點了。

 

火車發佈模型：將每一個應用的發佈過程看做一次火車旅行，火車定點運行，期間有若干站點，

每一站都例行檢查，不經過的項目下車，剩下的項目繼續坐着火車，直到火車到達終點（應用發佈成功）。

因爲火車發佈模型是基於規則驅動流程，因此這個流程能夠自動化採用火車發佈模型的網站回開發一個自動化發佈工具實現發佈過程自動化。

根據響應驅動流程，自動構建代碼分支，進行代碼合併，執行發佈腳本等。

正常流程下，能夠作到發佈過程無人值守，無需SCM（網站配置管理員）參與，

每一個項目相關人員基於流程執行相應的操做，便可完成自動化發佈。

人的干預越少，自動化程度越高，引入故障的可能性就越小。

 

6.灰度發佈

應用發佈成功後，仍然可能發現應爲軟件問題而引發的故障，這時候就須要作發佈回滾，

即卸載剛剛發佈的這個軟件，將上一個版本的軟件包從新發布，使系統復原，消除故障。

 

大型網站的主要業務服務器集羣規模很是強大，好比某大型服務器應用集羣服務器數量超過一萬臺。

一旦發生故障，即便想要發佈回滾也須要很長時間才能完成，只能眼睜睜看着故障時間不斷增長。

爲了應付這種局面，大型網站都會使用灰度發佈模式，將集羣服務器分廠若干部分，持續幾天才能把整個集羣所有發佈完畢，

期間若是發現問題，只須要回滾已發佈的一部分服務器便可。

就像一個大型網絡遊戲，不能說一次把全部區更新完畢，而是分批次完成，即便更新失敗也能回到以前版本，回滾時間也能接收。

灰度發佈也經常使用戶用戶測試，即在部分服務器上發佈新版本，其他服務器保持老版本（或者發佈另外一個版本），

而後監控用戶操做行爲，收集用戶體驗報告，比較用戶對兩個版本的滿意度，以肯定最終的發佈版本。這種手段叫作AB測試。