由于物種起源、曆史變革等不可控因素，我們的後端服務有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） 10秒内失敗請求量占總請求量（大于20）的百分比大于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驗證、使用者和車架号關系驗證、是否車主調用驗證等。
目前整個網關系統已作為後端基礎服務，為各個業務應用對外提供穩定的能力輸出，在業務服務的開發流程中，網關管理台也提供有力支撐，包括接口測試、調用監控、異常資訊檢視等；
下一篇會列出網關的主要一些類圖，友善了解。