輕鬆構建微服務之服務治理

微信公衆號：內核小王子
關注可瞭解更多關於數據庫，JVM內核相關的知識;
若是你有任何疑問也能夠加我pigpdong[^1]

API網關

依據系統的運行狀況,自動的進行流量調度,在無需人工干預的狀況下,提高整個系統的穩定性,,讓系統應對爆品等突發事件的時候,在依賴彈性計算進行擴容的時間窗口內避免底層資源被耗盡.

流量調度通常放在API網關裏面作,因此API網關須要有如下特色,業務邏輯簡單,可以支持在管理後臺動態修改服務配置,性能要高能夠抗住高流量.

因此服務治理最好也能夠在api網關裏作,服務熔斷,以及負載均衡,流量控制等,固然API網關還應該把協議轉換,請求安全校驗的工做作掉.

上圖爲一個API網關架構圖,一個總的gateway接入全部流量,而後分發給二級gateway,下面咱們具體看下一個gateway應該作哪些事情

• 請求路由 調用端不在須要知道服務的具體地址,只須要將請求發給網關,由網關層進行轉發

• 服務註冊 因爲服務調用統一交給網關進行轉發,那麼網關就須要知道全部服務提供方的實例地址,全部服務提供方,須要將信息註冊給網關,或者網關從註冊中心獲取後進行緩存.

• 負載均衡 網關層能夠實如今多個服務實例之間進行負載均衡,例如round robin或者設置權重

• 安全管理 用戶的鑑權統一防治gateway作,以及對用戶惡意攻擊的防範.

• 流量控制 在監控到某個服務可能過載後能夠對該服務進行熔斷設計,避免該服務拖垮其餘服務,也包括一些重試,限流等

• 灰度發佈 因爲網關層能夠作服務的管理功能,那麼就能夠在網關層實現灰度發佈,對不一樣版本的服務導入不一樣的流量

• API聚合 能夠在網關層將多個單一的微服務進行簡單的聚合,將各個微服務的返回結果進行聚合,這樣就能夠避免用戶端和服務端頻繁的業務調用,若是有複雜的業務邏輯建議仍是放在底層服務實現.

• 應用監控 網關層因爲是全部微服務調用鏈路的起點,能夠展現分佈式鏈路追蹤的分析統計結果,提供每一個服務的吞吐量,響應時間,返回碼的性能統計報表

• 彈力設計 網關層由於要接入大量流量,因此自身應該高可用,因此自身可以進行熔斷和自動擴容等機制

降級

降級咱們通常有如下方案

• 中止次要服務 當系統監控到某個服務不可用,或者即將突破可以抗住的壓力,能夠將該服務停掉,不在請求該服務,或者直接返回一個通用的code

• 下降一致性要求 當大量流量進入的時候,咱們能夠經過異步的方式處理請求,異步可能沒法保證業務的強一致性,可是若是咱們能夠接受最終一致性能夠採用這種方案,另外就是使用緩存,緩存可能和底層數據不一致,可是底層須要可以處理或規避這種風險

• 簡化功能 正常狀況下一個頁面可能須要返回大量的信息,那麼在降級後能夠只返回必要的信息,那麼其餘沒必要要信息對應的服務就能夠不用調用了

熔斷

當某個服務不可用後,而調用方的請求還在不停的重試,致使浪費CPU而且等待超時,下降系統的QPS,而熔斷器模式能夠檢測到系統不可用後不在調用該服務,繼續執行其餘流程,熔斷器須要可以記錄服務單位時間或者最近服務調用失敗的次數,而且能夠支持配置當到達某一個量化的閾值後就進行熔斷,同時支持當服務恢復後能夠自動解除熔斷限制.
目前Netfix的Hystrix已經中止維護,開源實現咱們能夠借鑑阿里的sentinel

限流

當某個服務在達到能夠支持的請求閾值後,而服務調用方還在不停的發起,咱們能夠對該服務進行限流,例如拒絕新來的請求,或者返回一個通用的返回碼,也能夠對服務進行降級,減小返回的信息,只返回核心數據等.也有一些業務在監控到某些服務達到閾值後,將優先給有白名單的用戶分配資源,而對其餘的用戶進行限流策略.或者延時處理.

限流目前有兩種流行的算法

隊列算法

按先進先出,將請求進行排隊緩存,若是要支持VIP用戶,也能夠用優先級隊列,這樣白名單用戶將會比普通用戶早一點獲取資源

漏桶算法

如圖漏桶算法,將流入表明用戶請求,而流出表明處理請求,漏桶須要設置一個桶的大小,就是容量,能夠是一個隊列,用來存放尚未處理的請求,而底下的桶洞控制請求處理的速度,當新的請求達到桶的容量後,就執行拒絕策略.因此在針對突發流量的狀況下缺少效率.

令牌桶算法

以必定的速率往桶裏放入令牌,而後每一個請求都須要從桶裏拿出一個令牌,一個桶能保存的最大令牌數有限制,當請求速度太快就會致使桶裏沒有多餘的令牌,那麼就會將請求進行拒絕策略,若是請求太少就會致使桶裏令牌裝滿溢出,因此令牌桶有必定的在突發流量狀況下能夠支持繼續處理請求.