背景
background
在微服務的概念流行之前，API網關就已經存在了，最初是作為開放平臺，面向合作伙伴提供OpenApi。隨著後來微服務的流行，API網關作為系統邊界，將所有的服務聚集在一起，是統一的入口，這就要求API網關能夠滿足不同類型應用、不同場景的需求；在技術上，也面臨著可用性、靈活性、安全性等不同的挑戰。
隨著中通內部應用的大量開發，越來越多的業務系統需要能夠快速開發接入，而且要保證安全穩定。所以我們決定採用網關來代理後端服務，同時抽取統一管控服務的流控、鑑權、負載均衡等等，目前市面上已經存在一些開源的網關係統，比如Spring Cloud、Kong等等，由於現在系統中已經存在大量的dubbo服務，所以我們決定通過自研網關來實現網關的通用功能以及一些定製化的開發。
使用場景
在中通，網關主要有以下幾種使用場景：
1. 面向第三方合作平臺： 我們將內部的下單、物流查詢等接口通過API網關提供給商家、合作伙伴調用；
2. 面向移動APP；
3. 面向WEB應用：一般在前後端分離的場景下使用，後端開發人員開發服務通過API網關暴露給前端。
4. 跨語言服務調用：中通內部存在多種語言並存的情況，有跨語言調用的情況。
只需維護一個服務，即可面向多端輸出；只需調整API定義，即可實現對APP、設備、web端等多種終端的支持，避免多個場景多套API，大幅降低開發成本。
架構與設計
Architecture and Design
設計目標
1. 動態配置：能夠動態新增API；
2. 彈性化：動態限流與熔斷，幫助後端抵擋流量高峰；
3. 安全性：滿足不同場景下的鑑權、安全需求；
4. 無狀態：更好的支持橫向擴展；
5. 高可用：網關作為系統內的單點，必須做到高可用。
以下是核心功能框架圖
特點與優勢
1. 安全性： 網關可為開發者提供多種授權訪問API的方式，從而來消除後端代碼的授權問題。網關目前支持中天SSO、簽名、時間戳、JWT等驗證方式。
2. 彈性： 網關可幫助開發人員限制API的併發數和每秒最大請求數，從而讓後端操作可以抵擋流量高峰。還可以通過緩存 API 調用的輸出來避免每次都調用後端，從而提升性能，並縮短終端用戶遇到的延遲。
3. 生命週期管理： 在發佈了 API 之後，開發人員可能會需要構建和測試增強現有功能或添加新功能的新版本。API 網關 支持可以同時操作修改每個API 版本，以便在發佈新 API 版本之後，現有應用可以繼續調用先前的版本。Api網關還支持自定義切換版本的規則以便線上灰度測試。
4. 協議轉換： 網關提供將Dubbo服務轉為HTTP協議接口的功能；網關還提供將請求數據投遞到用戶指定MQ的功能以滿足低延遲的需求。
5. 操作監控： 當 API 發佈並處於使用狀態後，網關會為開發者提供指標控制面板，監控對服務的調用情況。涵蓋了 API 調用次數、延遲數據和錯誤率。你還可以在kibana中指定關鍵詞搜索某次調用，也可以通過kibana來自定義統計API的調用情況。
6. 專為開發者設計： 通過網關，開發者可以迅速的將服務提供成http接口，並可以根據需求自定義多種授權方式；可以迅速搭建基於天工（內部前端框架）-網關的後臺管理系統，開發者無需關注sso、session的問題，專注於業務邏輯的開發。
7. 節省時間： 網關提供完善的API文檔、調用調試、Mock等功能，開發人員無需自己編寫接口文檔。
分層實現
中通網關在邏輯上分為四層
1. 接入層，負責請求參數的解析
2. 攔截器層，負責實現網關鑑權、灰度、限流等核心功能
3. 映射層，負責將請求參數映射轉換為後端服務所需要的參數
4. 調用層，負責將轉換後的參數調用後端服務的功能
高可用
網關作為一個單點，一旦發生故障是災難性的，我們採用了以下的設計來增加保障網關的高可用性：
1. 限流與熔斷： 我們給API提供了不同維度的限流，基於用戶和API的維度，可以對每個用戶每分鐘（每小時、每天）的調用量做限制，也可以對每個API的併發數量做限制。在任何分佈式環境裡，故障是難以避免的，我們經常遇到後端服務異常或者超時的情況，這時我們通過引入hystrix來隔離API，使得一個API出現故障時，不會拖累API網關造成整個API網關故障。又因為我們一個API網關包含了幾百個API，如果使用線程池的方式，線程會過多，所以我們採用信號量的方式。我們通過apollo配置中心對hystrix的配置進行管理，使得hystrix配置可以被動態修改。
2. 線程隔離： 我們將耗時較長的API隔離開來，放入單獨的線程池中執行，當其出現超時或者其他異常時，不會影響其他API的調用。
3. HTTP服務的負載均衡： 由於dubbo自帶了負載均衡策略，所以我們對http服務做了負載均衡。目前我們對http服務提供了兩種策略，一種是普通的輪循，一種是可以感知服務節點狀態的輪循，我們參考了netflix ribbon的設計，會定期的訪問http服務，如果服務不可用，則將其從可用列表中移除，如果可用，則將其添加到可用列表中去。
4. 弱依賴第三方服務：我們對所有的API配置、以及Session信息做了本地緩存，在數據庫、Redis出現異常時也不影響接口的訪問，由此來降低因第三方服務、中間件不穩定導致的網關故障
網關模塊
1. Gateway Web：網關API入口；
2. Gateway Portal：統一的管理界面，開發人員可以在此創建配置API。
日誌與異常
為了讓後端開發人員能方便的查詢API調用日誌，我們將API調用的參數、耗時、異常等打印到logback，通過logkit收集到kafka，然後消費採集到elasticsearch，通過kibana對日誌進行查詢和展示。除此之外，我們還定期的對日誌進行不同維度的統計（調用量、錯誤率等），在控制檯中展示查詢。
WEB應用SSO插件
WEB應用SSO插件是我們調研公司內部當前瀏覽器端開發的情況推出的前端中臺解決方案，結合前端的天工模板，旨在解決當前Web開發中存在的問題，提升開發效率。
這套解決方案有以下的功能：
1. 統一交互前後端交互標準；
2. SSO登入登出、權限控制等均由天工模板、網關來實現；
3. 提供統一的數據簽名、黑白名單、防刷等安全防護；
4. Apicenter提供統一的文檔生成、模擬調用、數據mock功能；
5. 提供前端設計器，通過拖拽組件創建前端頁面。
下圖是接入Web應用接入網關之前與接入之後的情況：
接入之前：
接入之後：
技術細節
全異步化
同步調用受限於線程數量，而線程資源寶貴，在 API 網關這類高併發應用場景下，一定比例的 API 超時就會讓所有調用的 RT 升高，異步化的引入徹底的隔離 API 之間的影響。網關在 Servlet 線程在進行完 API 調用前置校驗後，使用Dubbo和AsyncHttpclient 發起遠程服務調用，並結束和回收到該線程
1. 使用異步Servlet
2. 使用異步Dubbo
3. 使用異步HTTP庫（AsyncHttpclient）
灰度
原理
網關支持同一個API有多個版本，在API被調用時，灰度控制相關的攔截器會在後端服務被調用前執行腳本，根據執行結果確定版本。為了方便開發人員編寫，我們支持js和groovy兩種語言的腳本。
應用場景
在腳本中，可以取到HTTP請求的參數、header、IP地址等信息，也可以取到當前登錄用戶的信息。由此，就可以方便的根據請求參數、根據登錄用戶和網點來決定調用哪個版本的API。
遇到的問題
problem
dubbo初始化導致heap溢出
沒有提供者的Dubbo服務不能不停的初始化，我們有一次線上好幾個節點同時出現了故障，排查出來是dubbo服務不停的初始化造成的內存溢出。是因為線上一個Dubbo服務下線了，但是網關的API沒有下線，而且調用方也沒有停止調用，就導致這個dubbo服務一直不停的初始化。我們先將API下線，並調整了同一個服務兩次初始化的間隔時間臨時解決了這個問題。
後端服務超時導致網關阻塞
由於servlet默認是阻塞式調用，後端服務大量超時，導致網關線程被佔用無法釋放，無法接收新的請求，通過異步Servlet和多級線程池的方式，隔離後端服務對網關造成的影響
總結
summary
網關在中通現狀
中通的API網關目前服務了內部的眾多系統——掌中通、掌上神州、網投系統等，目前日均調用量達到13億，峰值調用約3萬qps。
未來的展望
1. 未來網關將會作為中颱解決方案的一員，應用於中通的各種系統，不管是移動端還是瀏覽器Web端，都有網關的身影；
2. 網關將會提供一系列SDK工具，涵蓋API的創建，文檔的生成與查看，服務的Mock與測試等，為開發人員提供方便的服務。
