引言
所謂高可用性指的是系統如何保證比較高的服務可用率，在出現故障時如何應對，包括及時發現、故障轉移、儘快從故障中恢復等等。隨著信息技術的發展，企業越來越依賴於信息化管理，各業務應用的數據信息，主要存儲在數據庫中，企業對這些數據訪問的連續性要求越來越高，為了避免因為數據的中斷導致各種損失，數據庫的高可用已成了企業信息化建設的重中之中。同時，對於政府、電信、金融、能源、軍工等等涉及國計民生的行業或領域的關鍵業務對於關鍵數據存儲都需要高可用，必須保證數據系統7×24小時全天候運行，防止數據丟失、數據損壞。
一、高可用性方案
說了 MTBF 和 MTTR 這兩個定義，那麼具體究竟應該如何落地實踐來提高可用性呢？
首先說幾個大家可能都聽膩了的方案
一、提高冗餘度，多實例運行，用資源換可用性。
雖然道理很簡單，實現起來可不簡單，有很多很多細節上的東西需要考慮。
第一個細節：N + 2 應該是標配。
N + 2 就是說平時如果一個服務需要 1 個實例正常提供服務，那麼我們就在生產環境上應該部署 1 + 2 = 3 個節點。大家可能覺得 N + 1 很合理，也就是有個熱備份系統，比較能夠接受。但是你要想到：服務 N + 1 部署只能提供熱備容災，發佈的時候就失去保護了。
因為剛才說了， 發佈不成功的機率很高！
從另一個角度來講，服務 N + 2 說的是在丟失兩個最大的實例的同時，依然可以維持業務的正常運轉。
這其實就是最近常說的兩地三中心的概念有點像。
第二個細節： 實例之間必須對等、獨立。
千萬不要搞一大一小，或者相互依賴。否則你的 N + 2 就不是真的 N + 2。如果兩地三中心的一箇中心是需要 24 小時才能遷移過去的，那他就不是一個高可用性部署，還是叫異地災備系統吧。
第三個細節：流量控制能力非常重要。
想做到高可用，必須擁有一套非常可靠的流量控制系統。這套系統按常見的維度，比如說源 IP，目標 IP 來調度是不夠的，最好能按業務維度來調度流量。比如說按 API， 甚至按用戶類型，用戶來源等等來調度。
為什麼？因為一個高可用系統必須要支持一下幾種場景：
Isolation。A 用戶發來的請求可能和 B 用戶發來的請求同時處理的時候有衝突，需要隔離。
Quarantine。用戶 A 發來的請求可能資源消耗超標，必須能將這類請求釘死在有限的幾個節點上，從而顧全大局。
Query-of-death。大家都遇到過吧。上線之後一個用戶發來個一個異常請求直接搞掛服務。連續多發幾個，整個集群都掛沒了，高可用還怎麼做到？那麼，對這種類型的防範就是要在死掉幾臺服務器之後可以自動屏蔽類似的請求。需要結合業務去具體分析。
二丶變更管理（Change Management）
還記得影響 MTBF 最大的因子嗎？。
第一點： 線下測試（Offline Test）
線下測試永遠比線上調試容易一百倍，也安全一百倍。
這個道理很簡單，就看執行。如果各位的團隊還沒有完整的線下測試環境，那麼我的意見是不要再接新業務了，花點時間先把這個搞定。這其中包括代碼測試、數據兼容性測試、壓力測試等等。
臺上一分鐘，臺下十年功。
可用性的階段性提高，不是靠運維團隊，而是靠產品團隊。能在線下完成的測試，絕不拍腦門到線上去實驗。
第二點：灰度發佈
這個道理說起來好像也很普通，但是具體實施起來是很有講究的。
首先灰度發佈是速度與安全性作為妥協。他是發佈眾多保險的最後一道，而不是唯一的一道。如果只是為了灰度而灰度，故意人為的拖慢進度，反而造成線上多版本長期間共存，有可能會引入新的問題。
做灰度發佈，如果是勻速的，說明沒有理解灰度發佈的意義。一般來說階段選擇上從 1% -> 10% -> 100% 的指數型增長。這個階段，是根據具體業務不同按維度去細分的。
這裡面的重點在於1%並不全是隨機選擇的，而是根據業務特點、數據特點選擇的一批有極強的代表性的實例，去做灰度發佈的小白鼠。甚至於每次發佈的 第一階段用戶（我們叫 Canary / 金絲雀) ，根據每次發佈的特點不同，是人為挑選的。
如果要發佈一個只給亞洲用戶使用的功能，很明顯用美國或歐洲的集群來做發佈實驗，是沒有什麼意義的。從這個角度來想，是不是灰度發佈可做的事情很多很多？真的不只是按機器劃分這麼簡單。
回到本質：灰度發佈是上線的最後一道安全防護機制。即不能過慢，讓產品團隊過度依賴，也不能過於隨機，失去了他的意義。
總之，灰度發佈，全在細節裡。
第三點：服務必須對回滾提供支持
這點不允許商量！
這麼重要的話題，我還要用一個感嘆號來強調一下！
但是估計現實情況裡，大家都聽過各種各樣的理由吧。我這裡有三條買也買不到的祕籍，今天跟大家分享一下，保證藥到病除。
理由1：我這個數據改動之後格式跟以前的不兼容了，回退也不能正常！
祕籍1：設計、開發時候就考慮好兼容性問題！！！比如說數據庫改字段的事就不要做，改成另加一個字段就好。數據存儲格式就最好採用 protobuf 這種支持數據版本、支持前後兼容性的方案。最差的情況，也要在變更實施『之前』，想清楚數據兼容性的問題。沒有回滾腳本，不給更新，起碼做到有備而戰。
理由2：我這個變更刪掉東西了！回退之後數據也沒了！
祕籍2：你一定是在逗我。把這個變更打回去，分成兩半。第一半禁止訪問這個數據。等到發佈之後真沒問題了，再來發布第二半，第二半真正刪掉數據。這樣第一半實施之後需要回滾還可以再回去。
理由3：我這個變更發佈了之後, 其他依賴這個系統的人都拿到了錯誤的數據，再回退也沒用了，他們不會再接受老數據了！
祕籍3：這種比較常見出現在配置管理、緩存等系統中。對這類問題，最重要的就是， 應該開發一種跟版本無關的刷新機制。觸發刷新的機制應該獨立於發佈過程。 要有一個強制刷新數據的手段。
以上三個祕籍覆蓋了100%的回滾兼容性問題，如果有不存在的，請務必告訴我！
回滾兼容性問題，是一個整體難題。只有開發和運維都意識到這個問題的嚴重性，才能從整體上解決這個問題。而解決不了回滾難題，就不可能達到高可用。
三丶可用性 7 級圖表
說完了變更管理，給大家帶來一個7級圖表，可以看看自己的服務到底在哪個可用性的級別上。
當一個服務掛了的時候......
第一級：Crash with data corruption, destruction.
內存數據庫就容易這樣。出現個意外情況，所有數據全丟。寫硬盤寫到一半，掛了之後，不光進程內數據沒了，老數據都丟光了。碰上這樣的系統，我只能對你表示同情了。
第二級：Crash with new data loss.
一般來說 正常的服務都應該做到這一點...... 。掛了之後最多隻丟個幾秒之內的數據。
第三級：Crash without data loss.
要達到這一級，需要付出一定程度的技術投入。起碼搞清楚如何繞過 OS 各種 Cache，如何繞過硬件的各種坑。
第四級：No crash, but with no or very limited service, low service quality.
做的好一點的系統，不要動不動就崩潰了...... 如果一個程序能夠正常處理異常輸入，異常數據等，那麼就給剛才說的高級流控系統創造了條件。可以把其他的用戶流量導入過來，把問題流量發到一邊去，不會造成太大的容量損失。
第五級：Partial or limited service, with good to medium service quality.
這一級就還好了，如果多個業務跑在同一個實例上，那麼起碼不要全部壞掉。有部分服務，比完全沒有服務要好
第六級：Failover with significant user visible delay, near full quality of service
上升到這一級別，才摸到高可用的門，也就是有容災措施。但是可能自動化程度不高，或者是一些關鍵性問題沒有解決，所以業務能恢復，就是比較慢。
第七級：Failover with minimal to none user visible delay, near full quality
of service.
四丶高可用的服務
高可用的服務模塊為業務產品提供基礎公共服務，在大型站點中這些服務通常都獨立分佈式部署，被具體應用遠程調用。
在具體實踐中，有以下幾點高可用的服務策略可以參考：
①分級管理：核心應用和服務具有更高的優先級，比如用戶及時付款比能否評價商品更重要；
②超時設置：設置服務調用的超時時間，一旦超時後，通信框架拋出異常，應用程序則根據服務調度策略選擇重試or請求轉移到其他服務器上；
③異步調用：通過消息隊列等異步方式完成，避免一個服務失敗導致整個應用請求失敗的情況。
④服務降級：網站訪問高峰期間，為了保證核心應用的正常運行，需要對服務降級。
降級有兩種手段：一是拒絕服務，拒絕較低優先級的應用的調用，減少服務調用併發數，確保核心應用的正常運行；二是關閉功能，關閉部分不重要的服務，或者服務內部關閉部分不重要的功能，以節約系統開銷，為核心應用服務讓出資源；
⑤冪等性設計：保證服務重複調用和調用一次產生的結果相同；
五丶高可用的數據
對於大多數網站而言，數據是其最寶貴的物質資產。
保證數據高可用的主要手段有兩種：一是數據備份，二是失效轉移機制；
①數據備份：又分為冷備份和熱備份，冷備份是定期複製，不能保證數據可用性。熱備份又分為異步熱備和同步熱備，異步熱備是指多份數據副本的寫入操作異步完成，而同步方式則是指多份數據副本的寫入操作同時完成。
關係數據庫的熱備機制就是通常所說的主從同步機制，實踐中通常使用讀寫分離的方法來訪問Master和Slave數據庫，也就是說寫操作只訪問Master庫，讀操作均訪問Slave庫。
總結
以 上就是我推薦以上是對Java開發技術之高可用架構剖析問題及其優化總結，分享給大家，希望大家可以瞭解什麼是 Java開發技術之高可用架構剖析問題及其優化。覺得收穫的話可以點個關注收藏轉發一波喔，謝謝大佬們支持！
1、多寫多敲代碼，好的代碼與紮實的基礎知識一定是實踐出來的
2、可以去百度搜索騰訊課堂圖靈學院的視頻來學習一下java架構實戰案例，還挺不錯的。
最後，每一位讀到這裡的網友，感謝你們能耐心地看完。希望在成為一名更優秀的Java程序員的道路上，我們可以一起學習、一起進步。
3丶想了解學習以上課程內容可加群：469717771 驗證碼（06 必過） ~.~
