如何在阿裡雲上建構高可用應用

業務高可用是我們每個項目的需求，一個經常故障的項目，會讓我們覺得不靠譜而選擇放棄，進而導緻項目的失敗。今天，我們來聊一聊，如何讓你自己的業務能夠更加穩固的運作！

本次我們從四個不同的角度，來分析，如何讓我們的應用更加穩固，平穩運作。

<b>一、       </b>

<b>程式架構</b>

<b>優秀的代碼</b>

優秀的代碼非常重要，即使我們擁有最好的硬體資源和架構，如果我們沒有一套健壯的代碼，其他資源再好都沒有用，是以代碼在設計和編寫時，應當注意代碼的健壯程度。優秀的代碼不止開發起來友善，同時維護成本也較低，對于後續的優化來說，健壯的代碼會讓優化人員更加容易的找到問題的關鍵。

<b>合理的架構</b>

一個大型的、負載的單體應用可能會讓你的整個開發進度緩慢、部署困難。是以，為了解決這種問題，不妨在開發初期便将應用程式設計為微服務架構的程式，雖然可能會提升程式之間的溝通難度，但卻為你的應用提供了後續自由伸縮的可能，幫你解決後期發展起來的伸縮難題。

對于已經上線的應用，整體微服務化可能是非常困難的，畢竟你不可能讓整個團隊重新開發一套系統出來，這樣的情況下，不妨把核心的、請求量較高的業務單獨拆分出來，作為一個服務，讓每一個服務都變成專注與單一的責任和功能的小的區塊，更好的對外提供服務。

<b>二、       </b>

<b>資源架構</b>

在雲計算的時代，雲計算大行其道，為各行各業提供計算能力的支援，合理的利用雲計算所提供的能力，就能幫助我們更加輕松的去做好應用的高可用。

一般來說，我們的每一個應用大體上都可以分為四層：入口層、業務層、緩存層、資料庫層。當我們做好每一層的優化，那麼我們的應用本身對于可能出現的問題進行避免。

<b>入口層</b>

入口層通常的情況下指的是nginx、apache等層面的東西，來負責應用的入口。一般情況下，我們會将應用程式定位在某一個ip，那麼如果我們這個ip當機了，就會導緻服務的不可用，是以，在入口層我們不妨使用負載均衡，通過對壓力的評估和成本的預估以及技術實作的難度，我們可以選擇自建負載均衡或者使用雲服務商提供的負載均衡器，在這樣的情況下，當我們入口層後面的業務出現了單點故障時，可以自動借助于負載均衡的健康檢查和請求分發的機制，把請求轉發配置設定到可用的節點，保證服務的正常運轉。

<b>業務層</b>

業務層通常是由php、java、python、go等寫的邏輯代碼構成的，需要依賴于背景資料庫及一些緩存層面的東西。如何實作業務層的高可用呢？最核心的就是，業務層不要有狀态,将狀态分散到緩存層和資料庫。目前大家通常喜歡将以下幾種資料放入業務層。

第一個是session，即使用者登入相關的資料，但好的做法是将session放在資料庫裡，或者一個比較穩定的緩存系統中。

第二個是緩存，在通路資料庫時，如果一個查詢很慢，就希望将這些結果暫時放到程序裡，下次再做查詢時就不用再通路資料庫了。

一個簡單的原則就是業務層不要有狀态。在業務層沒有狀态時，一台業務層伺服器當掉了之後，nginx/apache會自動将所有的請求打到另外一台業務層的伺服器上。由于沒有狀态，兩台伺服器沒有任何差異，是以使用者完全感受不到。如果把session放在業務層裡面的話，那麼面臨的問題是，這個使用者以前是登入在一台機器上的，這個程序死掉後，使用者就會被登出了。

<b>緩存層</b>

非常簡單的架構裡是沒有緩存這個概念的。但在通路量上來之後，mysql之類的資料庫扛不住了，比如在sata盤裡跑mysql，qps到達200、300甚至500時，mysql的性能會大幅下降，這時就可以考慮用緩存層來擋住絕大部分服務請求，提升系統整體的容量。

緩存層如果希望實作高可用的架構，最好的方案就是将緩存層分的細一些，采用分布式的緩存或者是雲計算服務商提供的雲緩存能力，來減輕資料庫層的壓力。

<b>資料庫層</b>

在資料庫層面實作高可用，通常是在軟體層面來做。例如，mysql有主從模式(master-slave)，還有主主模式(master-master)都能滿足需求。mongodb也有replicaset的概念,基本都能滿足大家的需求。

<b>三、       </b>

<b>雲計算資源利用</b>

上述的内容，主要還是和開發層面有關的，接下來我們來聊聊和運維強相關的内容

<b>業務不單點</b>

無論我們怎麼對伺服器的能力進行優化，終歸是有個上限的，而且，單點伺服器也更容易出現安全的故障問題。即便是雲計算，也無法保證業務的永久可運作，即便是國内top1的阿裡雲，也出現過機房光纜被挖斷過。是以，不要指望雲計算服務商為你提供絕對可用的服務，更何況，在他們自己的服務等級協定裡也不是100%。

是以，對于我們自己來說，要讓自己的應用盡可能的不要單機運作，即使你的應用是單體服務，也可以讓他跑在同一個節點的不同可用區（節點故障很少見）、不同節點的多個可用區（異地多活）、甚至，為了保證業務的運作，不要相信一家服務商，你可以同時采購多家的雲計算資源（如果預算足夠），就算有百分之一的可能，這個服務商挂掉了，你還可以切換到别的服務商去提供服務。

<b>合理利用雲資源</b>

除了雲計算最基礎的計算能力，我們往往會購買一些附加的業務，比如雲資料庫、雲緩存、雲存儲等等。

通過雲存儲，我們可以将非結構化的附件資料，存儲到雲服務商所提供的對象存儲服務中，減少本地的檔案存儲壓力，同時為業務伺服器減少io讀寫壓力，更加專注于運算。

通過雲緩存，我們可以在使用同一個可用區的多台主機時，将狀态進行同步。幫助我們的應用同步狀态，以免使用者登入狀态的丢失。

通過雲資料庫，我們可以借助雲服務廠商所提供的能力，來拓展我們資料庫的多備份、主從分離等等。讓我們的業務資料查詢請求進行分流，避免單一資料庫的讀寫壓力過大而導緻業務的崩潰。

利用雲計算供應商的提供能力，能夠為你自己維護減輕壓力，把精力放在業務本身。

<b>注意備份保安全</b>

雲服務商不是神，我們自己部署伺服器會出現的問題，雲服務商同樣也會出現，隻是他們可能比我們的優勢在于能夠更好的去幫我們儲存資料，避免資料的丢失。同時借助數異地雙活、異地多活、資料三備份等技術，保證我們資料的安全和可靠。我們在使用雲服務商為我們提供的種種安全措施的同時，看清楚人家的能力，同時要保證自己的資料的定期備份，以免出現問題。

<b>四、       </b>

<b>關注服務商提供的公告資訊</b>

維護和故障是不可避免的，再大的雲計算服務供應商，都有可能遇見這樣或那樣的故障文檔，隻要我們關注服務商所提供的公告資訊，盡可能的去提前準備，那麼就可以更換的提供服務。

這一方面做的比較好的是aws和azure，在每次出現故障後，他們都會提出故障公告，誠懇的說明故障的原因和解決方案，讓使用者明白故障的問題所在。這一方面，國内阿裡雲在完善故障通報機制，可以看到同一個故障出來阿裡雲都是通報最快，算是比較靠譜，其他雲廠商，基本上官網不會公開，則大多是能瞞則瞞，能不報就不報，但是問題總歸是問題，沒有說明反而會讓使用者更加的疑惑，其他雲廠商需要向aws、azure以及阿裡雲學習。

在維護方面，aws、azure就顯得比較坑爹了，他們過往的維護周期比較長，如xen底層的一個漏洞，無法采用熱更新，一般就需要分批停機維護胡，使用者如果沒有準備，就需要關站一天，不過好在往往會提前一周發出維護公告，聲明維護的節點，讓使用者提前做好準備。這一方面，國内遇到的還比較少，印象中如阿裡雲沒有大規模停機維護的事件，一方面是aws在前可作前車之鑒，另外也有技術上的因素。

不過，凡事也沒有一定。畢竟，雲計算也是由一個個機房組成的，不是真正飄在天空中，飄在雲上的伺服器，我們在使用傳統獨立伺服器可能會遇見的掉電、故障等問題，也會出現在雲計算的主機上，隻是相對來說，要少了很多，更加的安全。

是以，不管是aws、azure、還是阿裡雲或國内其他廠商，都在鼓勵使用者使用多個節點和可用區來部署業務，單點情況下出現的故障是不可避免的，當你使用多個節點時，出現故障的可能就大大的減小了。比如你可以在同一個可用區使用兩台主機來做主備，再另外一個可用區做備份，這種情況下，即使一個可用區出現了問題，整體的服務也不會受影響。

最後，我們來總結下如何建構高可用的應用：

1.      

健壯的代碼為高可用保駕護航

2.      

合理的架構為高并發情況下的伸縮提供可能

3.      

入口層的請求分發

4.      

業務層盡可能不存在狀态

5.      

緩存層使用分布式緩存緩解壓力

6.      

資料庫層使用主備模式進行備份

7.      

業務不單點運作

8.      

合理利用雲計算資源

9.      

注意資料的安全與備份

10.   

關注雲計算廠商的維護公告

最後，祝大家的業務都能正常的運作！