高可用的一些思考和理解

本文來源公衆號：匠心零度

在目前的互聯網大時代，在高併發等衝擊下，還必須保證服務高可用，若是服務不高可用那麼意味着：

• 系統不是7*24小時提供服務，那麼用戶體驗就特別差了，可能用戶下次不用了，留不住用戶。
• 當系統不可用的時候，對公司的形象是有所影響的，BAT相似這種技術都是象徵的。
• 最重要的一點，當系統不可用的時候，直接損失就是金錢！！！基本都是秒算損失的，依稀記得2015年5月28日攜程網癱瘓事件，按照攜程一季度財報公佈的數據，攜程宕機的損失爲平均每小時106.48萬美圓。

高可用是很是複雜的，本身水平有限，並不能涵蓋那麼多，只能說是本身對高可用的一些思考和理解。

那麼怎麼使系統高可用呢？

咱們不能讓服務器不掛，讓服務不掛，那麼怎麼樣讓這種必敗的局面不會有問題呢，就是能夠掛，服務能夠壞，那麼怎麼讓系統還能夠提供服務呢？

首先若是機器有不少，服務有不少，就算壞了一部分也沒有問題啊，必敗的局面獲得的解決。下面進行一步一步剖析，若是機器裏面存儲了特定值，那麼就不能擴展，必須是用掛的那臺機器，那麼這個是不行的，機器問題好解決，相同的配置替代是容易的，那麼應用服務也是相似，應用服務能夠不存儲狀態有關的值在任何機器而本身內部不會有存儲一些特定的特徵數據，若是有就沒辦法很容易的擴展，只有當每一個主件都是同樣的時候，無任何差別，咱們纔好替換，容易擴展，那麼這個就叫着服務的無狀態化。

假如目前服務已是無狀態化了，那麼如何讓系統動態的感知到服務掛了呢？否則請求仍是回去到掛的那臺機器，怎麼轉移到新的機器呢？那麼可能就須要服務發現與註冊了。

若是達到了上面的狀況，應對通常的狀況基本已經夠了，可是互聯網是複雜的，剛剛說的機器壞，服務壞了的問題，那麼若是網絡出現短暫不通由於怎麼辦呢？

因此服務之間應該有心跳的檢測，來按期看看是否可通（機器壞了，服務掛了，網絡不通了）反正就是不可達了。這種狀況經過服務註冊與發現便可解決，可是有時候網絡是閃斷下那麼在那種特定的狀況呢？好比剛剛a服務已經把請求發送給了b服務，b服務已經接收到請求了，那麼這個時候突然網絡斷了，可是b服務進行把邏輯處理作完成了，可是a服務反應的就是沒有響應，前臺超時了，那麼再一次觸發下，那麼若是b服務把以前的邏輯再作一遍是否存在問題呢？ 好比支付，已經付款200元，難道再付款200元嗎？這裏須要提到一個冪等性的設計概念，什麼是冪等呢，就是屢次執行結果都同樣，若是有冪等性設計那麼就不怕這種狀況了，在沒有獲得反饋狀況重試便可，也不會出現問題。

達到上面說的這些就是應對機器壞了，服務掛了，網絡不通或者閃斷等狀況已經基本沒有什麼大問題了，那麼目前互聯網都是高併發，那麼在高併發的狀況，如何來提升系統的能力的？

就和搬東西同樣，一我的慢，能夠多來點人一塊兒幫東西，因爲上面的架構是能夠添加機器，服務的，那麼很容易想到的就是多來點機器和服務。那麼這樣必定比機器少要快的，好比有5臺機器，那麼不少請求過來了，用什麼策略讓他們分攤到不一樣的機器呢？經過設備，經過一些軟件層面，可是其中必定有服務發現註冊，否則沒辦法動態知道節點變化，還有就是對一些信息的控制，黑白名單，訪問頻率等。不少時候，加機器可能看起來比較low，可是有時候的確比較有效，可是也不能一味的加機器，有些狀況加機器是解決不了的了。

機器多了的確快了，若是在服務裏面有一個阻塞方法，那麼就算服務在多也沒用，因此必須注意關於服務超時的問題，因爲服務是冪等的，就算再次執行也沒有任何關係，有了超時就不會卡好久影響到後面的服務了（下游服務宕機了，線程死鎖了，下游服務忙等等）。

關於同步，異步的一些設計模式，在有些必須順序執行的業務場景就必需要使用同步了，在非必須的這種場景那麼用異步必定比同步處理的併發量要大（因爲中間件經歷不少步驟，因此從單個請求的總時間來看並不必定有同步的快，可是從一個宏觀的角度來看提升併發的請求會大不少了）。簡單聊聊異步，在一個服務內部，異步那麼就須要提到多線程了，多線程不少有點提升cpu利用率，提升系統性能，可是實現成本要高不少了，那麼不一樣服務直接的如何異步呢，消息中間件了，（消息中間件很難，第一要保證真異步，第二須要保證不重不漏，就這2點真的很難，特別是在大數據狀況下），特別是網絡I/O須要重點考慮異步模型，不過Netty封裝的挺好了。

因爲每一個機器，或者服務都是有上限的，若是量一下泄洪式的過來而且不是他的能力能夠處理的，那麼該若是解決呢？

該問題在生活中處處可見，剛恰好國慶回家、出去玩，隨處可見該事項體現，好比過安檢的時候，有一個保安專門拿一個牌看人差很少了，讓後面的人等，等處理的查很少了，在讓後面的人進行，以後相似在等。，可是若是有級別高的，或者車快發車了，通常讓他們先過，在軟件架構裏面應該叫限流、服務降級，通常有兩種控制策略（1，拒絕部分請求，2，關閉部分服務）可能以前的時候都提到了關閉部分服務，不過如今不推薦了（畢竟也是公司技術實力的體現），目前重點說的是關於拒絕部分請求，關於這塊的控制在那裏添加？就是那塊須要控制，應該每層都須要加下該控制。

依稀記得行業裏面有句話，高併發、高可用三大法寶：限流、降級、緩存，關於緩存，你們應該接觸的最多，互聯網業務特色就是讀多寫少，那麼就很是適合使用緩存了。

因爲因此請求在一個服務，擴展仍是很差擴展，並且統一服務裏面有些調用特別多，有些調用就比較少，由於繼續劃分，繼續拆，這樣仍是能夠再次提升併發。

微服務了，微服務概念不少，首先提到的就是搞垂直拆分，很容易理解，以後垂直業務可能也不少，還須要繼續水平拆分，（這裏一切的拆分依據都是根據本身公司的業務，理解越深才的越好）。

經過上面的這些，服務能夠掛，機器能夠壞，網絡不通或者閃斷的問題都解決了，而且能夠提升併發，盡最大努力來讓服務高可用。那麼因爲這麼作帶來了不少問題，因此須要把這些修改帶來的問題解決：

• 之前在一個服務裏面，對於事務的控制很容易，那麼微服務以後，事務的控制就顯的特別重要了，不少時候咱們不能強一致性，可是咱們能夠作到最終一致性就是能夠的。
• 調用鏈監控也就顯得特別重要了，一塊兒的還有預警也特別重要了。
• 分佈式日誌也顯得特別重要了。
• 高級的jstack、Btrace在真實環境就是特別重要的。

結束語

本人水平有限，不免會有一些理解誤差的地方，若是發現，歡迎各位積極指出，感謝！！！