業內通常用多少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。
所以熔斷這個機制可以分為三個部分：
successcounts：熔斷期後，判斷請求是否恢復正常的條件，若連續請求成功次數達標，則恢復**，服務自動轉入監控期；否則，繼續進入熔斷期。如此反覆。
eolinker agw(goku api gateway)熔斷外掛程式執行流程
服務降級有點像熔斷的其中一部分，但是使用上沒有熔斷那麼苛刻，我們可以根據服務的返回來判斷是否需要進行服務降級。例如根據http狀態碼，只要介面返回異常狀態碼就可以進行服務降級，介面返回正常的狀態碼，閘道器就會正常**。服務降級時，由閘道器返回服務降級預先設定的內容。
服務降級也能分為三個部分：
matchstatuscodes：異常狀態碼：一般是404、500等
statuscode：服務降級時返回的狀態碼
介面返回正常狀態碼即可恢復服務。
雖然有很多機制保障介面的可訪問，但是乙個請求報錯的原因有很多，偶然一次報錯不一定是服務不可用，最簡單的，第一次不行，應該再訪問一次或幾次，以確定結果。
請求重試可以說是閘道器對介面**的基本要求，每個介面都應該可以設定重試次數。當請求失敗後，閘道器應立即再次請求，直到拿到正常返回，或是達到重試閾值，再將結果返回給客戶端。
乙個請求過來，首先經過nginx的一層負載，到達閘道器，然後由閘道器負載到真實後端，若後端有問題，閘道器會進行重試訪問，多次訪問後仍返回失敗，可以通過熔斷或服務降級立即返回結果。而且，由於是負載均衡，閘道器重試時不一定會訪問到出錯的後端。
往期精選(見【架構師修煉】wx公號)
分布式資料之快取技術，一起來揭開其神秘面紗
分布式資料複製技術，今天就教你真正分身術
資料分布方式之雜湊與一致性雜湊，我就是個神運算元
分布式儲存系統三要素，掌握這些就離成功不遠了
想要設計乙個好的分布式系統，必須搞定這個理論
分布式通訊技術之發布訂閱，乾貨滿滿
分布式通訊技術之遠端呼叫：rpc
訊息佇列broker主從架構詳細設計方案，這一篇就搞定主從架構
訊息中介軟體路由中心你會設計嗎，不會就來學學
訊息佇列訊息延遲解決方案，跟著做就行了
秒殺系統每秒上萬次下單請求，我們該怎麼去設計
【分布式技術】分布式系統排程架構之單體排程，非掌握不可
cdn加速技術，作為開發的我們真的不需要懂嗎？
煩人的快取穿透問題，今天教就你如何去解決
分布式快取高可用方案，我們都是這麼幹的
每天百萬交易的支付系統，生產環境該怎麼設定jvm堆記憶體大小
你的成神之路我已替你鋪好，沒鋪你來捶我
如何設定Ubuntu做閘道器
linux做伺服器沒什麼好說的，好用就乙個字。硬體需求 一台安裝ubuntu的pc。兩塊網絡卡。配置很簡單，假設有兩個網段的網路 0和1，分別是 192.168 0.0和 192.168 sudo ifconfig eth0 192.168 0.1 netmask 255.255 255.0 up ...
Linux 設定閘道器
以下的實操都是在redhat7.3上 網絡卡是電腦內建的硬體又叫網路介面卡，是用來聯網用的網路介面 mac是網絡卡的標識id 閘道器是用來 訊息的裝置，就是發訊息要經過閘道器 閘道器相當與乙個門口，你要出去必須找到這個門口 路由器就是這個門口，你想出去就要告訴你的電腦門在那 把真實主機變成路由器,手...
linux閘道器設定
1.linux中eth0為外網ip 外網閘道器 外網dns設定，eth1為內網ip 172.22.0.0 16 不設定閘道器 dns。2.啟動linux核心中的ip 功能 使得 net.ipv4.ip forward 1 重啟網路 etc init.d network restart 3.配置ipt...