業內通常用多少9來衡量網站的可用性，例如QQ的可用性是4個9，也就是QQ能夠保證在一年裏，服務在99.99%的時間是可用的，只有0.01%的時間不可用，大約最多53分鐘。
對於大多數網站，2個9是基本可用；3個9是叫高可用；4個9是擁有自動恢復能力的高可用。
實現高可用的主要手段是數據的冗餘備份和服務的失效轉移，這兩種手段具體可以怎麼做呢，在網關裏如何體現？
一、集羣部署
保障服務可用是網關的一個重要職責，服務通過網關開放出去，如果不是集羣部署，整個網關只有一個節點，這個節點掛了，網關就相當於掛了，這樣網關存在的意義其實不大，所以一般網關會跟根據服務器性能進行集羣部署。雖然網關可以只在一個地方部署集羣，相當於是單數據中心部署，但是企業可以根據服務性質進行地域性的數據中心部署，每個數據中心包含幾個網關節點，這樣每一個數據中心既可以當作是地區用戶的訪問中心，也能夠當作是數據的災備中心。這樣部署已經能夠保障網關的正常可用。
EOLINKER AGW（GOKU API Gateway）的集羣部署架構圖
二、負載均衡
一套完整的網關應該包含一個控制檯與多個網關節點，控制檯內的配置項對所有的節點生效。通常一臺服務器只部署一個網關節點，並且通過IP地址註冊在控制檯中，節點會通過主動/被動更新的方式獲取控制檯上的最新配置信息。
這裏說的負載均衡不是架設在網關前的負載設備（nginx或f5），而是網關節點本身的負載，網關的每個節點都能夠對所有後端進行負載。如下圖所示，每個網關節點都能夠將請求分發到服務1、服務2和服務3。也就是說，一個請求從客戶端過來，首先被負載設備（nginx）分發到某個節點，再由節點（網關）將請求分發到具體後端。
EOLINKER AGW（GOKU API Gateway）的負載均衡
三、健康檢查
儘管上面已經加了兩層負載，但是，假設我們的某個節點出了問題，或者說某個後端服務出了問題。nginx有可能會把請求負載到有問題的節點，節點也有可能會把請求負載到有問題的後端，這時候服務最終的結果仍是不可用，如果能及時把有問題的節點和有問題的後端移出負載範圍就好了。如何及時知道節點出了問題或者說是後端出了問題？其實也不難，像是監控檢查一樣，定期去檢查目標對象，對象沒有返回結果就是有問題了。
健康檢查這裏有兩種，一種是nginx對網關節點的健康檢查，另一種是網關節點對後端服務的健康檢查。
nginx如何對節點進行健康檢查，網上有很多相關教程。這裏主要探討的是網關節點對服務後端的健康檢查，我們可以對後端設定正常返回的結果（根據請求狀態碼、超時期限、或是其他條件），定期訪問後端服務，若發現返回異常，則控制檯將該後端從負載列表裏移除。發現異常時網關同樣會產生告警。移除後網關也會定期訪問該後端服務，若發現後端服務已恢復，則恢復對該後端的負載。
四、節點自動重啓
網關針對異常情況導致停止運行的節點會進行自動重啓。制臺每隔30秒去訪問一遍運行中的節點列表，若發現節點返回異常，則進行重試，若重試過程拿到正常返回，則視爲節點正常；若重試3次後節點仍返回異常，則視爲節點異常，自動重啓節點。
五、熔斷
我們可能還遇到這種情況，由於某些接口或服務的不可控因素，比如網絡連接緩慢，資源被佔用或者暫時不可用等，導致對這些服務的調用失敗，但是這些錯誤通常在一段時間內可以恢復正常。
但是，難保有些原因使錯誤結果超出預期，並且這種錯誤可能嚴重到系統的部分失去響應，甚至導致整個服務的完全不可用。比如由併發請求引起的阻塞，這種對請求的阻塞可能會佔用寶貴的系統資源，如內存，線程，數據庫連接等等，消耗的資源使其他系統不相關的部分受影響甚至拖累整個系統。在這種情況下，對客戶端立即返回錯誤可能是一種更好的選擇，等到發現服務可用的時候再恢復訪問。
判斷服務不可用就切斷對服務的訪問，這種機制像是電路的保護機制，我們都形象地稱其爲熔斷。熔斷跟心跳檢測不太一樣，心跳檢測是主動地去探測接口是否正常，而熔斷是使用過程中才會觸發的。
簡單來說，熔斷是指接口在一定時間內訪問失敗達到一定的次數，就觸發熔斷。熔斷啓動後，網關不會對該接口進行轉發，而是直接返回預先設定的內容。每隔一段時間網關會檢測接口是否恢復正常，等到接口恢復正常，網關纔會恢復對該接口的轉發。在EOLINKER AGW（GOKU API Gateway）裏熔斷是根據接口返回的狀態碼觸發的，異常的狀態碼我們能設置多個，比如說常見的404或500。
所以熔斷這個機制可以分爲三個部分：
-
熔斷條件：
-
monitorPeriod：監控期（秒），監控服務的單位時間
matchStatusCodes：觸發熔斷的異常狀態碼，一般是404、500等
minimumRequests：觸發熔斷的請求閾值，超過該閾值纔會觸發熔斷機制，因爲單位時間內請求次數過少不一定有必要觸發熔斷
failurePercent：監控期內，總請求次數的錯誤百分比，一般是50%
-
開啓熔斷：
-
breakPeriod：熔斷期（秒），此期間內網關不轉發請求，直接由網關返回下面預設的內容
statusCode：熔斷啓動，網關返回的狀態碼
header：熔斷啓動，網關返回的頭部信息
body：熔斷啓動，網關返回的body信息
-
關閉熔斷，恢復服務：
successCounts：熔斷期後，判斷請求是否恢復正常的條件，若連續請求成功次數達標，則恢復轉發，服務自動轉入監控期；否則，繼續進入熔斷期。如此反覆。
EOLINKER AGW（GOKU API Gateway）熔斷插件執行流程
六、服務降級
服務降級有點像熔斷的其中一部分，但是使用上沒有熔斷那麼苛刻，我們可以根據服務的返回來判斷是否需要進行服務降級。例如根據HTTP狀態碼，只要接口返回異常狀態碼就可以進行服務降級，接口返回正常的狀態碼，網關就會正常轉發。服務降級時，由網關返回服務降級預先設定的內容。
服務降級也能分爲三個部分：
-
降級條件：
matchStatusCodes：異常狀態碼：一般是404、500等
-
啓動服務降級，返回預設內容：
statusCode：服務降級時返回的狀態碼
-
header：服務降級時返回的頭部信息
body：服務降級時返回的body信息
-
關閉服務降級，恢復服務：
接口返回正常狀態碼即可恢復服務。
七、接口重試
雖然有很多機制保障接口的可訪問，但是一個請求報錯的原因有很多，偶然一次報錯不一定是服務不可用，最簡單的，第一次不行，應該再訪問一次或幾次，以確定結果。
請求重試可以說是網關對接口轉發的基本要求，每個接口都應該可以設置重試次數。當請求失敗後，網關應立即再次請求，直到拿到正常返回，或是達到重試閾值，再將結果返回給客戶端。
推薦一個好的springboot專欄哈：https://marketing.csdn.net/poster/108?utm_source=NEWFXDT
小結
一個請求過來，首先經過nginx的一層負載，到達網關，然後由網關負載到真實後端，若後端有問題，網關會進行重試訪問，多次訪問後仍返回失敗，可以通過熔斷或服務降級立即返回結果。而且，由於是負載均衡，網關重試時不一定會訪問到出錯的後端。
在公衆號菜單中可自行獲取專屬架構視頻資料，包括不限於 java架構、python系列、人工智能系列、架構系列，以及最新面試、小程序、大前端均無私奉獻，你會感謝我的哈
往期熱門文章：
