轉載請註明原創出處，謝謝！
在目前的網際網路大時代，在高併發等衝擊下，還必須保證服務高可用，如果服務不高可用那麼意味著：
- 系統不是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、Btrack在真實環境就是特別重要的。
今天大概就這麼多了，希望對大家有所幫助，自己也在學習思考，希望大家多多關注，多多支援，順手點贊點贊，謝謝！！！
查閱更多歷史，歡迎關注個人公眾號！！！
