一個可快速落地的微服務網關架構實現

隨著應用與技術越來越複雜，無論研發過程或者是運維過程都面臨更多困難，為了應對上述困難，馬丁提出了微服務概念，這幾年微服務應用逐漸流行開來。微服務應用建設，應當是先建設微服務基礎設施，然後在這個基礎上拆分應用，可見微服務基礎設施建設是實施微服務的核心，而微服務網關就是其中最重要的微服務基礎設施之一。

傳統網路層的網關主要作用是鏈接和協議轉換，而微服務網關處於應用層，其主要功能是路由轉發，當然在微服務環境中，網關作為外部請求和內部系統的橋樑（外部網關）或者內部系統之間轉發的橋樑（內部網關），一定會面臨很多新的挑戰。比如：

請求流量挑戰，流量隨著時間推移不斷增長，或者流量的峰值超出系統處理極

系統穩定性，由於網關關聯了多個系統，無論哪個系統出現延遲或者異常都可能導致網關不穩定

微服務網關職責劃分，正確的職責劃分可以優化整個微服務體系，使得整個系統最優雅

微服務網關分析

從外部環境看微服務網關面對上述挑戰，因此需要深入分析。首先面對流量的挑戰，導致流量變化可能是正常請求也可能是異常請求，這時需要系統自動感知到，如果是異常流量而且接近峰值時，能自動降級或者限制該類請求，如果是正常請求則應該自動擴容，當流量下降後能自動縮容。

其次面對穩定性挑戰，導致網關不穩定可能是網關自身問題，也可能是網關依賴的其他系統，因此在網關設計中要加入異常處理、熔斷、監控以及故障轉移，從程序到運維多個層面解決穩定性問題。

最後面對職責劃分挑戰，需要從多個視角收集網關的功能點，其核心功能是路由，輔助功能有：數據安全加解密、業務無關數據驗證，另外網關還可以實現通用業務功能例如計費、用戶驗證等。

架構設計原則與方法

微服務網關設計與其他系統設計一樣，需要按照關注點不同進行分層、分離，關注點分離技術是人們廣泛使用的解決複雜問題的一種系統思維方法。通過上面的分析可知微服務網關包含了核心功能還包含了大量的其他功能，涉及到運維和開發過程，既包含功能要求也包含非功能要求，因此是個複雜的系統。

為了使系統清晰，把微服務網關分成四層，從下往上分別是運維層、服務治理層層、非核心功能層、核心功能層。在每一層內部再根據不同的關注點分離，例如在服務治理層又分離成限流、降級、監控三個部分。

微服務網關的架構設計方法，根據微服務網關面對的並發性，以及為了維持自身的高可用性，所以採用以下的方法：監控、負載均衡、限流與降級、故障轉移、集群、自動擴縮容、熔斷，才能滿足系統設計要求。

架構設計與實現

網關總體架構設計，如上圖。上面兩層給出了微服務網關的路由功能和路由表管理，下面兩層從運維和服務治理指出了如何實現高可用高性能的微服務網關，微服務網關的部署圖如下，包括了註冊中心，網關、消息隊列和網關後台管理系統，圖的下面部分是網關的下游微服務，接下來分別就主要技術點進行闡述。

負載均衡

在當前微服務技術體系中 springcloud 是最成熟的，ribbon 是其實現客戶端負載均衡的組件，其原理是服務提供者和服務消費者都註冊到註冊中心，當服務消費者發起向服務提供者的請求時，先從註冊中心拿到一組服務提供者列表，然後利用 ribbon 實現的負載均衡策略，訪問某個服務提供者。

1、引入 jar

2、在啟動類中添加註解 @LoadBalanced、@RibbonClient 等

3、創建 ribbon 的負載均衡策略類，可以實現隨機策略、順序策略等 7 中策略，可以根據業務需要選擇實現方式。

熔斷器

在微服務網關應用場景中，可能由於硬體、軟體等造成網關依賴的服務不可用，一般剛開始是局部的，小規模的，如果不加處理，故障影響的範圍越來越大，最終導致了全局性的後果，在網關應用中，網關會出現同步等待，最終網關資源被佔用耗盡。針對這類依賴服務不可用問題，一般採用熔斷機制解決這類問題。Hystrix 是 Netflix 公司設計的針對交互時超時處理和容錯的類庫，它具有保護系統的能力。

Hystrix 是由熔斷器和線程池組成，用戶請求是先到熔斷器，熔斷器根據開關狀態，如果開關是打開狀態，則不調用線程池，而調用降級服務, 熔斷器的三個狀態根據調用情況進行轉換，熔斷器根據狀態產生對應的動作。

關閉：熔斷器關閉狀態，調用失敗次數積累，到了閾值（或一定比例）則啟動熔斷機制；

打開：熔斷器打開狀態，此時對下游的調用都內部直接返回錯誤，不走網路，但設計了一個時鐘選項，默認的時鐘達到了一定時間（這個時間一般設置成平均故障處理時間，也就是 MTTR），到了這個時間，進入半熔斷狀態；

半開：半熔斷狀態，允許定量的服務請求，如果調用都成功（或一定比例）則認為恢復了，關閉熔斷器，否則認為還沒好，又回到熔斷器打開狀態；

Hystrix 的線程隔離作用：Hystrix 在用戶請求和服務之間加入了線程池，用戶的請求將不再直接訪問服務，而是通過線程池中的空閑線程來訪問服務，如果線程池已滿，則會進行降級處理，用戶的請求不會被阻塞，至少可以看到一個執行結果（例如返回友好的提示信息），而不是無休止的等待或者看到系統崩潰。

限流

網關總會面臨高並發，限流就是在高並發情況下，限制請求總數，對於超出限流閾值的請求採用拒絕服務、降級服務手段，保證負荷不超過系統處理的上限。限流採用的演算法包括計數器、漏斗桶和令牌桶。演算法比較如下：

Bucket4j 是一款優秀的限流組件，他可以實現針對某個維度在集群中限流，例如，針對某個客戶的一個特定介面請求限流，該客戶的該介面請求可能被路由到集群中不同節點上，利用 Bucket4j 可以計算在集群中的總請求，進而實現限流。它還有其他優點例如可以通過插件實現日誌和監控，有同步和非同步介面，可以實現多個維度限流。

監控

網關係統是所有業務系統的門戶，是核心系統，網關係統可靠運行是衡量網關係統建設成敗的關鍵因素，通過系統監控可以及時了解系統運行狀態，以及可以及時發現系統運行異常，因而系統監控可以提升網關的可用性。系統監控功能主要包括：監控數據採集、監控數據分析展現、監控報警等。

在網關係統中監控數據採集主要包括：介面成功、失敗情況，為了使監控功能和網關核心功能松耦合，採用 metris 非同步埋點技術或者用通過日誌文件埋點等，數據分析可以採用 flume 收集日誌 +kafka+storm（flink）等技術進行實時計算分析，通過計算分析可以了解系統運行狀態，發現系統異常情況並進行報警。

安全

由於網關是和外部客戶交換數據，在公網上傳輸數據，因此需要保證數據安全傳輸，在網關中採用數據加密和簽名機制，加密保證數據不會泄密，簽名保證數據交互雙方身份不可抵賴以及數據的完整性。數據加密和簽名的過程和原理如下。

簽名過程：

發送者：提取消息 m 的消息摘要 h(m)，並使用自己的私鑰對摘要 h(m) 進行加密，生成簽名 s。

發送者將簽名 s 和消息 m 一起，使用接收者發過來的公鑰進行加密，獲得密文 c，發送給接收者。

驗簽過程：

接收者接受到密文後，用自己的私鑰對其解密，獲得明文消息 m 和簽名 s。

接收者使用 client 的公鑰解密數字簽名 s，獲得消息摘要 h(m)。

接收者使用相同的方法提取消息 m 的消息摘要 h(m) 與上一步解密得到的 h(m) 進行比較，如果相同則驗簽成功。

故障轉移

網關訪問下游服務集群，例如下游某個服務，分別部署在兩個節點，如果其中一個節點服務異常，那麼是希望網關能否發現有一個節點異常，並且能夠不再請求異常節點，而是全部訪問正常節點服務，這就是希望實現的故障轉移。

由於微服務網關是採用 springcloud 的技術體系，所以可供選擇的故障轉移技術有 erueka 或者 consul。

總結

本文從問題出發，從系統高可用性和高性能出發，系統的總結了微服務網關架構的技術要點，並且對相關技術點的原理和應用做了概要描述，限於篇幅和個人技術水平沒有給出詳細描述，希望給研究應用網關的同學起到拋磚引玉的作用。

作者介紹

徐進，武漢大學計算機碩士，近 20 年從業經驗，近 10 年一直從事軟體架構和系統架構，熱愛技術，現就職於拍拍信數據服務公司，從事架構師工作，前期對軟體復用有設計有興趣和和應用經驗，最近幾年對分散式架構和大數據架構有興趣和應用經驗。

喜歡技術總結和分享，之前在中文核心期刊《計算機應用》和省級優秀科技《電腦知識與技術》上發表過架構設計類文章。

當前分散式系統是大勢所趨，Google、Facebook 等大型系統架構也是以分散式系統架構為基礎。過去二十年，整個分散式系統架構演進史是從 C/S→B/S→分散式系統→網格計算→雲計算，包括目標、定位、場景，影響深遠。未來，如何從全球多域的角度去規劃分散式架構呢？

下個月深圳 ArchSummit 架構師峰會邀請了 Pinterest 武永勝、百度王耀、菜鳥網路黃浩、美團宋斌來分享他們的一手分散式系統設計經驗，這些內容一定可以助你一臂之力。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！