業務高可用是我們每個專案的需求，一個經常故障的專案，會讓我們覺得不靠譜而選擇放棄，從而導致專案的失敗。今天，我們來聊一聊，如何讓你自己的業務能夠更加穩固的執行！
本次我們從四個不同的角度，來分析，如何讓我們的應用更加穩固，平穩執行。
- 程式架構
優秀的程式碼
優秀的程式碼非常重要，即使我們擁有最好的硬體資源和架構，如果我們沒有一套健壯的程式碼，其他資源再好都沒有用，所以程式碼在設計和編寫時，應當注意程式碼的健壯程度。優秀的程式碼不止開發起來方便，同時維護成本也較低，對於後續的優化來說，健壯的程式碼會讓優化人員更加容易的找到問題的關鍵。
合理的架構
一個大型的、負載的單體應用可能會讓你的整個開發進度緩慢、部署困難。所以，為了解決這種問題，不妨在開發初期便將應用程式設計為微服務架構的程式，雖然可能會提升程式之間的溝通難度，但卻為你的應用提供了後續自由伸縮的可能，幫你解決後期發展起來的伸縮難題。
對於已經上線的應用，整體微服務化可能是非常困難的，畢竟你不可能讓整個團隊重新開發一套系統出來，這樣的情況下，不妨把核心的、請求量較高的業務單獨拆分出來，作為一個服務，讓每一個服務都變成專注與單一的責任和功能的小的區塊，更好的對外提供服務。
- 資源架構
在雲端計算的時代，雲端計算大行其道，為各行各業提供計算能力的支援，合理的利用雲端計算所提供的能力，就能幫助我們更加輕鬆的去做好應用的高可用。
一般來說，我們的每一個應用大體上都可以分為四層：入口層、業務層、快取層、資料庫層。當我們做好每一層的優化，那麼我們的應用本身對於可能出現的問題進行避免。
入口層
入口層通常的情況下指的是Nginx、Apache等層面的東西，來負責應用的入口。一般情況下，我們會將應用程式定位在某一個IP，那麼如果我們這個IP當機了，就會導致服務的不可用，所以，在入口層我們不妨使用負載均衡，通過對壓力的評估和成本的預估以及技術實現的難度，我們可以選擇自建負載均衡或者使用雲服務商提供的負載均衡器，在這樣的情況下，當我們入口層後面的業務出現了單點故障時，可以自動藉助於負載均衡的健康檢查和請求分發的機制，把請求轉發分配到可用的節點，保證服務的正常運轉。
業務層
業務層通常是由PHP、Java、Python、Go等寫的邏輯程式碼構成的，需要依賴於後臺資料庫及一些快取層面的東西。如何實現業務層的高可用呢？最核心的就是，業務層不要有狀態,將狀態分散到快取層和資料庫。目前大家通常喜歡將以下幾種資料放入業務層。
第一個是session，即使用者登入相關的資料，但好的做法是將session放在資料庫裡，或者一個比較穩定的快取系統中。
第二個是快取，在訪問資料庫時，如果一個查詢很慢，就希望將這些結果暫時放到程式裡，下次再做查詢時就不用再訪問資料庫了。
一個簡單的原則就是業務層不要有狀態。在業務層沒有狀態時，一臺業務層伺服器當掉了之後，Nginx/Apache會自動將所有的請求打到另外一臺業務層的伺服器上。由於沒有狀態，兩臺伺服器沒有任何差異，所以使用者完全感受不到。如果把session放在業務層裡面的話，那麼面臨的問題是，這個使用者以前是登入在一臺機器上的，這個程式死掉後，使用者就會被登出了。
快取層
非常簡單的架構裡是沒有快取這個概念的。但在訪問量上來之後，MySQL之類的資料庫扛不住了，比如在SATA盤裡跑MySQL，QPS到達200、300甚至500時，MySQL的效能會大幅下降，這時就可以考慮用快取層來擋住絕大部分服務請求，提升系統整體的容量。
快取層如果希望實現高可用的架構，最好的方案就是將快取層分的細一些，採用分散式的快取或者是雲端計算服務商提供的雲快取能力，來減輕資料庫層的壓力。
資料庫層
在資料庫層面實現高可用，通常是在軟體層面來做。例如，MySQL有主從模式(Master-Slave)，還有主主模式(Master-Master)都能滿足需求。MongoDB也有ReplicaSet的概念,基本都能滿足大家的需求。
- 雲端計算資源利用
上述的內容，主要還是和開發層面有關的，接下來我們來聊聊和運維強相關的內容
業務不單點
無論我們怎麼對伺服器的能力進行優化，終歸是有個上限的，而且，單點伺服器也更容易出現安全的故障問題。即便是雲端計算，也無法保證業務的永久可執行，即便是國內TOP1的阿里雲，也出現過機房光纜被挖斷過。所以，不要指望雲端計算服務商為你提供絕對可用的服務，更何況，在他們自己的服務等級協議裡也不是100%。
所以，對於我們自己來說，要讓自己的應用盡可能的不要單機執行，即使你的應用是單體服務，也可以讓他跑在同一個節點的不同可用區（節點故障很少見）、不同節點的多個可用區（異地多活）、甚至，為了保證業務的執行，不要相信一家服務商，你可以同時採購多家的雲端計算資源（如果預算足夠），就算有百分之一的可能，這個服務商掛掉了，你還可以切換到別的服務商去提供服務。
合理利用雲資源
除了雲端計算最基礎的計算能力，我們往往會購買一些附加的業務，比如雲資料庫、雲快取、雲端儲存等等。
通過雲端儲存，我們可以將非結構化的附件資料，儲存到雲服務商所提供的物件儲存服務中，減少本地的檔案儲存壓力，同時為業務伺服器減少IO讀寫壓力，更加專注於運算。
通過雲快取，我們可以在使用同一個可用區的多臺主機時，將狀態進行同步。幫助我們的應用同步狀態，以免使用者登入狀態的丟失。
通過雲資料庫，我們可以藉助雲服務廠商所提供的能力，來擴充我們資料庫的多備份、主從分離等等。讓我們的業務資料查詢請求進行分流，避免單一資料庫的讀寫壓力過大而導致業務的崩潰。
利用雲端計算供應商的提供能力，能夠為你自己維護減輕壓力，把精力放在業務本身。
注意備份保安全
雲服務商不是神，我們自己部署伺服器會出現的問題，雲服務商同樣也會出現，只是他們可能比我們的優勢在於能夠更好的去幫我們儲存資料，避免資料的丟失。同時藉助數異地雙活、異地多活、資料三備份等技術，保證我們資料的安全和可靠。我們在使用雲服務商為我們提供的種種安全措施的同時，看清楚人家的能力，同時要保證自己的資料的定期備份，以免出現問題。
- 關注服務商提供的公告資訊
維護和故障是不可避免的，再大的雲端計算服務供應商，都有可能遇見這樣或那樣的故障文件，只要我們關注服務商所提供的公告資訊，儘可能的去提前準備，那麼就可以更換的提供服務。
這一方面做的比較好的是AWS和Azure，在每次出現故障後，他們都會提出故障公告，誠懇的說明故障的原因和解決方案，讓使用者明白故障的問題所在。這一方面，國內阿里雲在完善故障通報機制，可以看到同一個故障出來阿里雲都是通報最快，算是比較靠譜，其他雲廠商，基本上官網不會公開，則大多是能瞞則瞞，能不報就不報，但是問題總歸是問題，沒有說明反而會讓使用者更加的疑惑，其他雲廠商需要向AWS、Azure以及阿里雲學習。
在維護方面，AWS、Azure就顯得比較坑爹了，他們過往的維護週期比較長，如Xen底層的一個漏洞，無法採用熱升級，一般就需要分批停機維護胡，使用者如果沒有準備，就需要關站一天，不過好在往往會提前一週發出維護公告，宣告維護的節點，讓使用者提前做好準備。這一方面，國內遇到的還比較少，印象中如阿里雲沒有大規模停機維護的事件，一方面是AWS在前可作前車之鑑，另外也有技術上的因素。
不過，凡事也沒有一定。畢竟，雲端計算也是由一個個機房組成的，不是真正飄在天空中，飄在雲上的伺服器，我們在使用傳統獨立伺服器可能會遇見的掉電、故障等問題，也會出現在雲端計算的主機上，只是相對來說，要少了很多，更加的安全。
所以，不管是AWS、Azure、還是阿里雲或國內其他廠商，都在鼓勵使用者使用多個節點和可用區來部署業務，單點情況下出現的故障是不可避免的，當你使用多個節點時，出現故障的可能就大大的減小了。比如你可以在同一個可用區使用兩臺主機來做主備，再另外一個可用區做備份，這種情況下，即使一個可用區出現了問題，整體的服務也不會受影響。
最後，我們來總結下如何構建高可用的應用：
- 健壯的程式碼為高可用保駕護航
- 合理的架構為高併發情況下的伸縮提供可能
- 入口層的請求分發
- 業務層儘可能不存在狀態
- 快取層使用分散式快取緩解壓力
- 資料庫層使用主備模式進行備份
- 業務不單點執行
- 合理利用雲端計算資源
- 注意資料的安全與備份
- 關注雲端計算廠商的維護公告
最後，祝大家的業務都能正常的執行！