本文來源公衆號：匠心零度
在目前的互聯網大時代，在高併發等衝擊下，還必須保證服務高可用，如果服務不高可用那麼意味着：
- 系統不是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在真實環境就是特別重要的。
結束語
本人水平有限，難免會有一些理解偏差的地方，如果發現，歡迎各位積極指出，感謝！！！