1 網關簡介
蘇寧金融一站式API網關是面向公網的API託管服務
為各研發團隊提供 API 的完整生命週期管理、服務契約管理、服務監控等功能。
可以使用API服務管理平臺包裝自身業務服務，將蘇寧金融的數據服務、業務邏輯及功能組件安全可靠的開放給外部調用。
提供統一解決方案
動態代理、安全防護、流控降級、智能熔斷、灰度發佈、監控告警、API MOCK調試等。
具體功能將在後文中詳細介紹。在詳細介紹功能的同時，允許我先介紹一下蘇寧金融API網關的演進路線，希望在閱讀的過程中能瞭解到我們的設計思路。當然，我們的設計還有很多不足之處，也請各位大神指出，我們將會持續改進。
2 網關起源：蘇寧金融移動服務網關（1.0）
2.1初代誕生
2013年，是互聯網金融爆發的一年。“餘額寶”、“零錢寶”等互聯網理財產品在這一年誕生，以及蓬勃發展的第三方支付、虛擬貨幣的合法化等等，都將互聯網金融一步步展露在人們的面前，因此2013年也被稱為“互聯網金融元年”。
移動APP作為互聯網模式的新寵，自然也不會放慢腳步。所以在這一年，蘇寧金融也上線了第一款移動應用——易付寶APP（現已更名為蘇寧金融APP，下文我們稱之為蘇寧金融APP）。同時，我們也上線了第一個網關係統——蘇寧金融移動服務網關。
但由於移動端在當時剛剛興起，蘇寧金融的大部分業務服務均是為PC端定製 ，並不能適應移動端需求的特性。在移動端還沒成為主流的當時，要求所有服務系統去適配移動端特性無疑也是不現實的。所以網關係統為蘇寧金融APP提供安全加密、協議轉換、流控等網關通用能力的同時，還承載了移動端特有業務邏輯封裝的職能。
所以與其說是網關，我們網關早期的系統定位更偏向於移動服務系統。
如上圖所示，早期的網關係統職能大體分為三個部分：
網關基礎服務: 提供安全防護、服務限流、服務開關、鑑權等網關基礎服務。
移動應用服務: 提供移動特有功能服務。
金融業務服務: 封裝各業務線微服務，並根據移動需求定製化封裝。
但隨著移動互聯網的發展，移動應用的便捷性等優勢慢慢體現，移動應用也逐漸成為互聯網的趨勢。各業務線的需求也開始往移動端傾斜，隨之而來的，我們原網關設計的問題也逐漸暴露出來。
2.2問題缺陷
系統職能模糊：早期的網關服務系統還承載了移動業務邏輯包裝的職能，網關功能與移動服務糅合在一起，很難清晰的定義網關服務系統職能、明確系統分工。
業務耦合緊密：所有業務的邏輯均在同一服務系統，那麼當某一業務出現問題，勢必會對其他業務同時產生影響。
研發效率較低：由於具有移動服務端的職能，各業務線的移動端需求都會集中在移動網關服務系統，網關開發部的開發效率成為了產品迭代的“瓶頸”。
版本過渡依賴：同時由於各業務的需求均需網關做改造，致使各業務線的版本迭代過於依賴網關的版本週期。
面對如此多的問題，為了保證研發效率，提升產品迭代節奏，我們只能選擇將系統拆分重構。
3 拆分重構：蘇寧金融路由網關（2.0）
比較嚴重的兩個問題，是系統職能模糊及業務耦合緊密，這兩個問題不解決，我們的系統只會越來越重，所以我們決定將系統拆分。並且為了徹底解決問題，我們決定將橫向拆分及縱向拆分同時進行。
3.1橫向拆分，明確系統職能：
我們首先要做的，就是將網關與移動業務服務剝離。將移動業務服務下沉到網關下層，由各業務線研發團隊提供完整API服務，移動應用服務單獨搭建移動服務系統承載，並提供微服務接入網關。
同時，我們將網關也橫向拆分為路由網關及API網關兩層。
路由網關
位於網關平臺最上層，利用Nginx+Lua(OpenResty) 開發的高性能web應用。
Nginx的主要應用場景如負載均衡、反向代理、代理緩存等。而OpenResty是由nginx核心+很多第三方模塊兒組成。最重要的是OpenResty集成了Lua庫，開發人員可使用Lua編寫腳本並部署於nginx運行，使nginx變成了一個web應用。
而路由網關主要利用了nginx的動態代理機制，根據請求接口地址動態路由到API網關不同業務集群或灰度集群。
當網關後臺操作路由規則配置發生變化時會將配置持久化於redis，同時將規則配置信息推送至nginx代理服務器。
當用戶發送請求時，路由網關（OpenResty）中部署的Lua腳本則根據從 redis讀取的路由規則將流量切換分流，達到灰度或A/B Test的目的。同時路由規則可以支持多種維度，如按比例、用戶標識、請求終端類型、終端版本等，可以覆蓋多種使用場景。
路由方案示意
API網關
介於路由網關與服務層之間，為適配蘇寧技術架構的中間件及組件特性，如RSF協議、zedis組件等。所以我們沒有選擇市面上主流的如zuul、kong以及spring Cloud gateway等網關組件，在學習了主流網關的功能及思路之後，我們選擇自研編寫更適用蘇寧金融技術架構體系的網關。相對於路由網關，API網關的職責則更具體一些，如請求校驗、服務流控、服務鑑權、apimock等等功能均在這一層實現，而且功能還在持續擴展中。
應用架構圖示意
為了方便我們API網關功能的持續擴展，以及實現請求與處理者之間的解耦，我們採用了責任鏈模式：
將每個處理邏輯獨立為一個handler處理器，並通過handerManager進行初始化並控制各處理器的執行順序。在各處理器職責分類並排序後，將所有處理邏輯組織成了有序的執行隊列。在API網關其他功能擴展時，可以高效快速的植入，而不會影響正常公共邏輯。
3.2縱向拆分，業務線解耦合
雖然API網關提供的基礎功能相同，但是為了避免接入網關的各業務線互相影響，我們網關根據不同的業務類型也做了一次縱向拆分。在分佈式集群架構的基礎上，按API服務業務類型分配不同集群組，進行服務部署隔離。降低各業務線服務互相之間由於發佈、大促所產生的問題可能帶來的影響，解除各業務線之間的耦合，保證網關的高可用性。
按業務線隔離部署的另一個好處是，網關也可以根據不同業務的訪問量及特性做定向擴容。當用戶發送請求時，由路由網關根據網關平臺的路由規則做動態代理到不同的集群的API網關。
3.3標準協議，適用多終端
服務協議標準化：提供標準網關https+OAuth2.0協議rest風格API，在移動APP提供服務的基礎上，也可為H5、微信小程序等提供API服務。
服務契約標準化： 之前服務API的服務契約定義規則五花八門，可讀性較差，經常對調用方產生困惑。例：
API接口路徑定義：
API服務路徑風格不統一、規範不一致、可讀性較差，如
xxxx.suning.com/account/getAccount
xxxx.suning.com/loan/loaninfo/queryloan
...
API通用參數定義：
一些各系統均可能使用的通用參數，參數名定義不同，很容易對調用方產生困惑。
會員編號：accountNo、userNo、userNum...
響應碼：responseCode、resCode、errorCode…
…
API響應碼定義：
響應碼風格不統一、缺乏唯一性、同一響應碼含義不同、不同響應碼含義相同…
成功：0000，true、000000…
失敗：5000,false,xxx_9999
接入統一API網關後，對這些定義都制定了標準化規範，提升了服務可讀性、降低服務接入成本。
接口路徑定義規則標準：
xxxx.suning.com/{業務類型}/{服務組}/{api服務名稱}
接口路徑在服務管理員配置好服務信息後自動生成，無需服務管理員重新定義。
例：xxxx.suning.com/basic/account/getAccount
xxxx.suning.com/trade/loan/getLoan
公共參數統一標準：
通過網關暴露API服務的一些公共參數制定了統一規範，同時為適配下游微服務不同定義，可以配置參數映射。
響應碼統一標準：
通過網關暴露API服務的響應碼制定了統一規範，同時為適應下游微服務不同定義，可以配置響應碼及響應文案映射。
前後端分離：
提供完成的前後端分離解決方案，明確前端開發及後端開發職責。
前端應用獨立部署，前端開發人員關注頁面跳轉、頁面渲染等邏輯，通過ajax請求調用網關API獲取頁面數據。
API網關提供網關通用能力，同時針對前端應用解決跨域訪問及跨域cookie共享等問題。
服務提供方提供完整數據及業務邏輯服務。
跨域問題：
跨域是指a頁面想獲取b頁面資源，如果a、b頁面的協議、域名、端口、子域名不同，或是a頁面ip地址，b頁面為域名地址，所進行的訪問行動都是跨域的，而瀏覽器為了安全問題會限制跨域訪問，跨域請求可以正常發出，但返回結果會被瀏覽器攔截。
解決方案：
方案一：配置白名單：設置Access-Control-Allow-Origin屬性，僅在白名單內的域名可以跨域訪問網關接口。（需針對H5訪問做定製校驗）
方案二：通過註解@CrossOrigin設置為任何域名均可以跨域訪問，但調用API接口需校驗請求方身份。（與非H5訪問方案一致）
方案三：nginx反響代理：前端應用的nginx服務器配置反向代理監聽域名訪問，當識別到特殊路徑服務，將請求分發到對應的網關服務器。
安全問題：
前後端的分離，也帶來一些安全問題。所以與網關的交互方案參考了原來與移動端的安全加密方案。
1、提供JS版本的加密方法庫及配套demo，可支持RSA/AES/國密算法加密。
2、考慮到前端的代碼都是暴露在外面並不是特別安全，所以如果H5頁面是內嵌於蘇寧金融APP的話， 我們還提供加密組件sdk供前端h5調用，同時公鑰存儲於組件內部。前端只需傳入明文及秘鑰標識即可完成加密，進一步保證安全性。
對小程序的支持：
採用標準Oauth2.0協議認證流程，提供完整的小程序接入解決方案，可以快速高效的搭建蘇寧金融的任意小程序。
4 主動轉型：蘇寧金融一站式API網關平臺（2.5）
網關的拆分重構，明確了系統定位、解除了各業務線的耦合，但是之前提到的
研發效率低、版本過渡依賴的問題不能僅僅通過拆分系統得到有效解決。所以我們在完成網關拆分重構後，將重點轉向了API服務管理，在提升服務端研發效率的同時，於金融各平臺深度合作，致力於打造金融一站式API網關平臺。
4.1服務配置化，提升研發效率
既然網關職責已經明確，API網關提供標準化的通用網關能力，那麼網關所提供的API服務就可以通過配置來生成。
所以我們提供了API服務管理平臺，可以通過可視化界面完成API的生命週期管理，可以極大的提升網關API開發效率。
4.2管理規範化，解除版本依賴
既然服務可以通過配置來實現，那麼配置工作也就可以不集中在網關管理員身上。所以我們將API權限下放到各業務線研發團隊，由網關管理員審核接入服務申請，併為服務分配服務業務類型（集群組）。各研發團隊可隨時配置API服務並上線，完全解除了研發線對網關的版本依賴。
並且明確了崗位職責權限，規範化了服務管理的流程，各業務崗位各司其職。
4.3平臺集中化，提供一站式服務：
在做API服務管理平臺架構設計的時候，我們發現API服務管理平臺很多規劃的功能與現有的金融平臺有重合。如
金融魔客平臺：提供接口契約管理及mock案例管理等功能；
金融流控平臺：提供多級、多維度流控組件及流控組閾值配置平臺；
紫金大盤監控平臺：提供服務性能監控、服務異常統計等功能；
雖然平臺很全面，但是服務端開發人員，需登錄不同的平臺才能完成服務相關配置和管理。
為了避免系統重複建設，由專業的團隊做專業的事情，我們放棄了重新搭建的想法，而是選擇與已有平臺深度合作。同時為了避免API服務管理員使用過多的平臺，操作沒有銜接性和連貫性。API服務管理平臺將這些平臺的配置界面融合嵌入，通過唯一的服務管理入口，即可完成各平臺的全部配置工作，達到一站式服務的目的：
截止目前，已接入網關的業務服務有近20組，已註冊API服務400多個，其他業務服務還在持續接入中，下圖為目前已接入網關核心服務分佈佔比：
5 未來規劃：蘇寧金融開放API網關平臺（3.0）
雖然目前我們的網關平臺已經基本成型，但是比起業界主流的網關組件還有很多不足。比如目前我們的服務只能通過平臺註冊，欠缺服務發現的功能，以及我們還在規劃中的服務編排、A\B Test等功能。所以我們也對網關平臺的3.0版本進行了重點需求規劃。
服務開放：
目前我們的網關提供還是對內體系API，近期我們將於金融開放平臺融合，提供完整開放API解決方案：開放平臺提供商戶簽約及流程，由網關暴露API服務供第三方調用。
以及其他功能規劃
閱讀更多 IT說 的文章
