216
網關平台架構分享
概述
由於物種起源、曆史變革等不可控因素，我們的後端服務有A、B平台之分。A平台開發之初，對外出口就設定在網關上，一直被叫做A網關。B平台的架構大致是，後端各個業務係統，服務治理、RPC，使用dubbox，對外有兩個web 服務層應用（controller層），分別對應車機和手機端入口，通過注冊中心獲取各個業務服務提供者信息，rpc調用之。後端服務層應用，其實是沒分車機和手機的。再上麵就是nignx了，做反向代理和web服務層的負載均衡。B的服務架構優缺點比較明顯，就說說主要的缺點了（為後麵說網關做鋪墊），web層的兩個應用，需要依賴後端對外提供服務的所有應用，耦合度太大，不容易擴展；各個業務開發小組都會去開發和維護這兩個應用，導致混亂和相互幹擾；並且在這層的處理邏輯不統一，有簡單的參數校驗、也有寫了業務處理邏輯；每次係統更新上線，基本是每個小組負責人都要通宵。目前的情況是，B平台在做服務改造（牛X的說法，微服務改造）；首先，接入網關係統，丟棄掉web層的兩個應用，這樣就省去了都去開發維護這兩個應用的工作，業務開發人員能更集中關注自己的獨立業務服務；網關通過泛化調用，與各個業務服務沒有耦合、強依賴。上線流程也能做到各服務獨立、不限時段上線。這樣統一了網關這個出入口，也是為了後麵平台上雲，服務其他車廠提供能力。
以後就沒有A網關啦，隻有大斑馬網關。吼吼哈哈。。。
特點
- 高擴展性，可以任意增加部署節點；
- 高穩定性，線上環境持續運行，無任何異常出現；
- 高性能，這是網關最基本也是最重要的特性；
- API動態開放、測試、發布；
- 實時的API、車架號調用情況統計報表展示
- 支持接口灰度發布，根據灰度策略，動態路由調用；
- 熔斷、超時保護，異常調用量達到設置的比率時，會開啟熔斷機製；
架構圖
網關的主要功能在於統一對外調用的出入口，達到對外部請求的統一安全校驗、認證、參數校驗、對內部服務的發現、路由、負載均衡調用，統一封裝格式化輸出等。同時網關會記錄每個調用請求的信息，包括API名稱、版本號、入參、輸出、總的消耗時間、RPC消耗時間等。每條記錄信息會發送到MQ，由流計算統計功能處理，得到準實時的API調用情況報表。
對照上圖，圖中連線上的序號表示在邏輯上的先後；沒序號的為通過MQ消息來異常處理的邏輯
（1） 部署開發完成的微服務應用，成功部署後，開放的服務接口信息會注冊到服務注冊中心；
（2） 開發人員在網關管理台，錄入需要開放的API信息，網關管理台服務端會保存開放的API元數據信息到數據庫；
（3） 網關係統會定時到數據庫加載API元數據信息到網關服務的內存中，會涉及內存中API信息的增、刪、改。目前API數目在600左右，所以這樣定時全量加載不會有性能問題。後麵API數目增長很大的話，可使用外部緩存或者網關控製台有API的增刪改時通過mq消息通知來單條操作；
（4） 網關係統根據加載的API元數據信息，初始化並緩存該API對應的RPC服務引用；同時通過服務注冊中心，監聽和刷新服務提供者注冊在注冊中心的信息；
（5） 終端通過http/https請求到網關，網關根據參數協議解析請求參數，再做權限校驗、安全認證、參數校驗等處理；
（6） 根據調用的API信息，路由到具體的後端服務，進行rpc；對捕獲的各種異常，做對應的解析，得到異常碼和異常信息；對調用結果做格式化輸出（json/xml），返回終端；
（7） 網關對每個外部調用都會記錄該次調用的信息，包括API名稱、版本、入參、請求時間、返回時間、rpc消耗毫秒數、總消耗毫秒數、請求IP、服務端IP、異常碼等；記錄信息會通過異步方式發送到MQ；
Storm流計算服務通過拉取MQ中的每條調用信息記錄，做實時的統計，維度包括每日總調用量、總異常調用量、業務異常調用量、服務異常調用量，API、appKey、車架號維度的統計基本相同，增加異常調用的異常碼和對應的異常數量。
網關管理台服務端也會去拉取MQ中的每條調用信息記錄，批量存儲到odps，可做離線分析。
網關管理台的主要功能有，API錄入、API開放管理、API測試、API批量測試、API文檔、API調用監控報表等。
內部結構圖
網關集群部署，相互獨立。通過前端負載均衡服務，對外提供服務。網關服務內部主要邏輯模塊有網關上下文、請求上下文、調用器、熔斷器、調用鏈數據采集等組成。
網關支持不同的後端微服務平台，在錄入API時，可以選擇不同的服務協議。初始化網關上下文時，根據配置開關，確定是否加載對應的微服務平台環境配置（Env）。不同的Env對應不同的調用器（IInvoker），不同的調用器，有自己的前後處理器鏈（PreHandler、AfterHandler）。這樣就能做到針對不同的後端平台服務，做不同的調用前後邏輯處理。
網關的熔斷器通過Hystrix實現，主要關注的配置項有如下幾個：
1） 對依賴調用隔離策略，使用信號量隔離。信號量使用300；
2） 熔斷後，允許再次嚐試請求的間隔毫秒數；使用3000毫秒；
3） 失敗請求量占總請求量的百分比大於50%時，開啟熔斷；失敗請求包括服務異常、超時、超信號量拒絕；
4） 調用後端服務，超時時間毫秒數默認為5000毫秒；該配置項在API的管理頁麵可修改，實時生效；
Hystrix內部對每個Command的配置做了緩存，防止每次調用時，都要去初始化和加載各個配置項。針對第4項，網關做了對應的改造，為了使某個API的超時時間修改能實時生效，網關增加了類來繼承Hystrix的HystrixPropertiesStrategy類，重寫了類中的getCommandPropertiesCacheKey方法，該方法返回的字符串即為緩存Command配置的key。重寫後返回的key由API的key加上超時時間組成。這樣超時時間改變後，能重新加載。
性能
網關初始化時，通過上下文，緩存了所有依賴的對象或資源。對API元數據和rpc服務引用，采用初始化時緩存，後台線程定時刷新；對服務引用對象ReferenceService，其實緩存的是他的包裝類ReferenceServiceWarp，該包裝類內部持有ReferenceService和一個AtomicInteger類型的計數值。某個ReferenceService對象被幾個API引用，該計數值就為幾；當計數數值為0時，該ReferenceServiceWarp對象就可以被注銷回收了。ReferenceService與API是一對多的關係，就如一個服務接口類包含多個方法一樣的道理。
外部請求進來，在網關的處理邏輯中不涉及數據庫操作、外部緩存交互等；主要的性能瓶頸有兩個地方，一個是用戶認證和權限校驗接口，另一個是後端服務業務接口；
針對後端業務接口，需要優化處理邏輯，對依賴調用需要設置超時時間；對熱點接口，還可以增大dubbo線程池的線程數。
測試同事對網關做過很多次性能以及穩定性測試，下麵列出一組單機性能測試數據，
200並發，TPS：6537，平均響應時間：31.65ms，網關部署硬件：4核 8G
以上的測試結果，是在後端業務接口，無複雜邏輯和耗時操作的情況下的。所以最後的瓶頸在施壓機上。
安全
安全性方麵，目前網關做的有以下幾個方麵：
1）https調用；
2）對於指定需要授權的API，調用時需要傳入公共參數token，網關做token有效性驗證；
3）簽名校驗，每個外部調用都需要帶上公共參數sign，網關做簽名串sign校驗。要通過網關接入後端服務能力接口，需要在第三方開發者係統裏申請和創建應用，每個應用會分配對應的appKey和appSecret。簽名串就是通過入參、appKey、appSecret，並根據一定的規則生成得到；
4）時間戳，每個調用url有效性為生成該url時間的前後10分鍾以內；
B平台服務為後接入，並且車機和手機端調用方式和參數已不可能更改；所以對B服務接口調用時有效性和權限等的校驗，網關委托給一個專門的服務接口，該接口會做token驗證、用戶和車架號關係驗證、是否車主調用驗證等。
最後
目前整個網關係統已作為後端基礎服務，為各個業務應用對外提供穩定的能力輸出，在業務服務的開發流程中，網關管理台也提供有力支撐，包括接口測試、調用監控、異常信息查看等；
下一篇會列出網關的主要一些類圖，方便理解。
最後更新：2017-07-05 14:02:52