江陰建設(shè)銀行網(wǎng)站全網(wǎng)自媒體平臺(tái)大全
博客昵稱:架構(gòu)師Cool
最喜歡的座右銘:一以貫之的努力,不得懈怠的人生。
作者簡(jiǎn)介:一名退役Coder,軟件設(shè)計(jì)師/鴻蒙高級(jí)工程師認(rèn)證,在備戰(zhàn)高級(jí)架構(gòu)師/系統(tǒng)分析師,歡迎關(guān)注小弟!
博主小留言:哈嘍!各位CSDN的uu們,我是你的小弟Cool,希望我的文章可以給您帶來一定的幫助
個(gè)人百萬筆記知識(shí)庫(kù), 所有基礎(chǔ)的筆記都在這里面啦,點(diǎn)擊左邊藍(lán)字即可獲取!助力每一位未來架構(gòu)師!
歡迎大家在評(píng)論區(qū)嘮嗑指正,覺得好的話別忘了一鍵三連哦!😘
網(wǎng)關(guān)策略
- 1、流量治理
- 1-1、API鑒權(quán)
- 1-2、集群隔離
- 1-3、請(qǐng)求隔離
- 1-4、灰度發(fā)布
- 2、監(jiān)控告警
- 2-1、立體化監(jiān)控
- 2-2、多維度告警
- 3、關(guān)鍵設(shè)計(jì)
- 3-1、異步外調(diào)
- 3-2、外調(diào)鏈接池化
- 3-3、釋放連接
- 3-4、對(duì)象池化設(shè)計(jì)
- 3-5、上下文切換
- 3-6、監(jiān)控告警
- 4、解決方案
- 4-1、Shepherd API網(wǎng)關(guān)
- 4-2、Mashape Kong
- 4-3、Soul
- 4-4、Apiman
- 4-5、Gravitee
- 4-6、Tyk
- 4-7、Traefik
- 4-8、小豹API網(wǎng)關(guān)
1、流量治理
1-1、API鑒權(quán)
請(qǐng)求安全是API網(wǎng)關(guān)非常重要的能力,集成了豐富的安全相關(guān)的系統(tǒng)組件,包括有基礎(chǔ)的請(qǐng)求簽名、SSO單點(diǎn)登錄、基于SSO鑒權(quán)的UAC/UPM訪問控制、用戶鑒權(quán)Passport、商家鑒權(quán)EPassport、商家權(quán)益鑒權(quán)、反爬等等。業(yè)務(wù)研發(fā)人員只需要簡(jiǎn)單配置,即可使用。
1-2、集群隔離
API網(wǎng)關(guān)按業(yè)務(wù)線維度進(jìn)行集群隔離,也支持重要業(yè)務(wù)獨(dú)立部署。如下圖所示:
1-3、請(qǐng)求隔離
服務(wù)節(jié)點(diǎn)維度,API網(wǎng)關(guān)支持請(qǐng)求的快慢線程池隔離??炻€程池隔離主要用于一些使用了同步阻塞組件的API,例如SSO鑒權(quán)、自定義鑒權(quán)等,可能導(dǎo)致長(zhǎng)時(shí)間阻塞共享業(yè)務(wù)線程池。快慢隔離的原理是統(tǒng)計(jì)API請(qǐng)求的處理時(shí)間,將請(qǐng)求處理耗時(shí)較長(zhǎng),超過容忍閾值的API請(qǐng)求隔離到慢線程池,避免影響其他正常API的調(diào)用。除此之外,也支持業(yè)務(wù)研發(fā)人員配置自定義線程池進(jìn)行隔離。具體的線程隔離模型如下圖所示:
1-4、灰度發(fā)布
API網(wǎng)關(guān)作為請(qǐng)求入口,往往肩負(fù)著請(qǐng)求流量灰度驗(yàn)證的重任。
灰度場(chǎng)景
在灰度能力上,支持灰度API自身邏輯,也支持灰度下游服務(wù),也可以同時(shí)灰度API自身邏輯和下游服務(wù)。如下圖所示:
灰度API自身邏輯時(shí),通過將流量分流到不同的API版本實(shí)現(xiàn)灰度能力;灰度下游服務(wù)時(shí),通過給流量打標(biāo),分流到指定的下游灰度單元中。
灰度策略
支持豐富的灰度策略,可以按照比例數(shù)灰度,也可以按照特定條件灰度。
2、監(jiān)控告警
2-1、立體化監(jiān)控
API網(wǎng)關(guān)提供360度的立體化監(jiān)控,從業(yè)務(wù)指標(biāo)、機(jī)器指標(biāo)、JVM指標(biāo)提供7x24小時(shí)的專業(yè)守護(hù),如下表:
監(jiān)控模塊 | 主要功能 | |
---|---|---|
1 | 統(tǒng)一監(jiān)控Raptor | 實(shí)時(shí)上報(bào)請(qǐng)求調(diào)用信息、系統(tǒng)指標(biāo),負(fù)責(zé)應(yīng)用層(JVM)監(jiān)控、系統(tǒng)層(CPU、IO、網(wǎng)絡(luò))監(jiān)控 |
2 | 鏈路追蹤Mtrace | 負(fù)責(zé)全鏈路參數(shù)透?jìng)?、全鏈路追蹤監(jiān)控 |
3 | 日志監(jiān)控Logscan | 監(jiān)控本地日志異常關(guān)鍵字:如5xx狀態(tài)碼、空指針異常等 |
4 | 遠(yuǎn)程日志中心 | API請(qǐng)求日志、Debug日志、組件日志等可上報(bào)遠(yuǎn)程日志中心 |
5 | 健康檢查Scanner | 對(duì)網(wǎng)關(guān)節(jié)點(diǎn)進(jìn)行心跳檢測(cè)和API狀態(tài)檢測(cè),及時(shí)發(fā)現(xiàn)異常節(jié)點(diǎn)和異常API |
2-2、多維度告警
有了全面的監(jiān)控體系,自然少不了配套的告警機(jī)制,主要的告警能力包括:
告警類型 | 觸發(fā)時(shí)機(jī) | |
---|---|---|
1 | 限流告警 | API請(qǐng)求達(dá)到限流規(guī)則閾值觸發(fā)限流告警 |
2 | 請(qǐng)求失敗告警 | 鑒權(quán)失敗、請(qǐng)求超時(shí)、后端服務(wù)異常等觸發(fā)請(qǐng)求失敗告警 |
3 | 組件異常告警 | 自定義組件處理耗時(shí)長(zhǎng)、失敗率高告警 |
4 | API異常告警 | API發(fā)布失敗、API檢查異常時(shí)觸發(fā)API異常告警 |
5 | 健康檢查失敗告警 | API心跳檢查失敗、網(wǎng)關(guān)節(jié)點(diǎn)不通時(shí)觸發(fā)健康檢查失敗告警 |
3、關(guān)鍵設(shè)計(jì)
3-1、異步外調(diào)
基于Netty實(shí)現(xiàn)異步外調(diào)主要有兩種方式可以實(shí)現(xiàn):
- 方式一:建立全局Map,上線文傳遞(不參與遠(yuǎn)程傳輸)requestId,響應(yīng)時(shí)使用requestId進(jìn)行映射上游信息
- 方式二:直接將上游信息包裝成Context進(jìn)行上線文傳遞(不參與遠(yuǎn)程傳輸)
方式一需要獨(dú)立維護(hù)一個(gè)全局映射表,同時(shí)需要考慮請(qǐng)求超時(shí)和丟失的情況,否則會(huì)出現(xiàn)內(nèi)存不斷增長(zhǎng)問題。
3-2、外調(diào)鏈接池化
使用Netty實(shí)現(xiàn)API網(wǎng)關(guān)外調(diào)微服務(wù)時(shí),因建立連接需要極度消耗資源,所以需要考慮將外調(diào)的鏈接進(jìn)行池化管理,設(shè)計(jì)時(shí)需要注意以下幾點(diǎn):
- 初始化適當(dāng)連接(過多過少都不適合)
- 考慮連接能隨流量增減而進(jìn)行自動(dòng)擴(kuò)縮容
- 取出的連接需要檢查是否可用
- 連接需要考慮雙向心跳探測(cè)
3-3、釋放連接
http的鏈接是獨(dú)占的,所以在釋放的時(shí)候要特別小心,一定要等服務(wù)端響應(yīng)完了才能釋放,還有就是鏈接關(guān)閉的處理也要小心,總結(jié)如下幾點(diǎn):
-
Connection:close
-
空閑超時(shí),關(guān)閉鏈接
-
讀超時(shí)關(guān)閉鏈接
-
寫超時(shí),關(guān)閉鏈接
-
Fin,Reset
-
寫超時(shí):writeAndFlush包含Netty的encode時(shí)間和從隊(duì)列里把請(qǐng)求發(fā)出去即flush的時(shí)間。因此后端超時(shí)開始需要在真正flush成功后開始計(jì)時(shí),這樣才最接近服務(wù)端超時(shí)時(shí)間(還有網(wǎng)絡(luò)往返時(shí)間和內(nèi)核協(xié)議棧處理時(shí)間)
3-4、對(duì)象池化設(shè)計(jì)
針對(duì)高并發(fā)系統(tǒng),頻繁創(chuàng)建對(duì)象不僅有分配內(nèi)存開銷,還對(duì)gc會(huì)造成壓力。因此在實(shí)現(xiàn)時(shí),會(huì)對(duì)頻繁使用的對(duì)象(如線程池的任務(wù)task,StringBuffer等)進(jìn)行重寫,減少頻繁的申請(qǐng)內(nèi)存的開銷。
3-5、上下文切換
整個(gè)網(wǎng)關(guān)沒有涉及到IO操作,但在IO編解碼和業(yè)務(wù)邏輯都用了異步,是有兩個(gè)原因
- 防止開發(fā)寫的代碼有阻塞
- 業(yè)務(wù)邏輯打日志可能會(huì)比較多
在突發(fā)的情況下,但是我們?cè)趐ush線程時(shí),支持用Netty的IO線程替代,這里做的工作比較少,這里由異步修改為同步后(通過修改配置調(diào)整),CPU的上下文切換減少20%,進(jìn)而提高了整體的吞吐量,就是不能為了異步而異步,Zuul2的設(shè)計(jì)類似。
3-6、監(jiān)控告警
協(xié)議層
- 攻擊性請(qǐng)求。只發(fā)頭,不發(fā)/發(fā)部分body,采樣落盤,還原現(xiàn)場(chǎng),并報(bào)警
- Line or Head or Body過大的請(qǐng)求。采樣落盤,還原現(xiàn)場(chǎng),并報(bào)警
應(yīng)用層
- 耗時(shí)監(jiān)控。有慢請(qǐng)求,超時(shí)請(qǐng)求,以及tp99,tp999等
- QPS監(jiān)控和報(bào)警
- 帶寬監(jiān)控和報(bào)警。支持對(duì)請(qǐng)求和響應(yīng)的行、頭、body單獨(dú)監(jiān)控
- 響應(yīng)碼監(jiān)控。特別是400和404
- 鏈接監(jiān)控。對(duì)接入端的鏈接,以及和后端服務(wù)的鏈接,后端服務(wù)鏈接上待發(fā)送字節(jié)大小也都做了監(jiān)控
- 失敗請(qǐng)求監(jiān)控
- 流量抖動(dòng)報(bào)警。流量抖動(dòng)要么是出了問題,要么就是出問題的前兆
4、解決方案
4-1、Shepherd API網(wǎng)關(guān)
4-2、Mashape Kong
訪問地址:https://github.com/Kong/kong
4-3、Soul
訪問地址:https://github.com/Dromara/soul
4-4、Apiman
訪問地址:https://apiman.gitbooks.io/apiman-user-guide/user-guide/gateway/policies.html
4-5、Gravitee
訪問地址:https://docs.gravitee.io/apim_policies_latency.html
4-6、Tyk
訪問地址:https://tyk.io/docs
4-7、Traefik
訪問地址:https://traefik.cn
Tr?f?k 是一個(gè)為了讓部署微服務(wù)更加便捷而誕生的現(xiàn)代HTTP反向代理、負(fù)載均衡工具。 它支持多種后臺(tái) (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 來自動(dòng)化、動(dòng)態(tài)的應(yīng)用它的配置文件設(shè)置。
功能特性
- 它非???/li>
- 無需安裝其他依賴,通過Go語言編寫的單一可執(zhí)行文件
- 支持 Rest API
- 多種后臺(tái)支持:Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, 并且還會(huì)更多
- 后臺(tái)監(jiān)控, 可以監(jiān)聽后臺(tái)變化進(jìn)而自動(dòng)化應(yīng)用新的配置文件設(shè)置
- 配置文件熱更新。無需重啟進(jìn)程
- 正常結(jié)束http連接
- 后端斷路器
- 輪詢,rebalancer 負(fù)載均衡
- Rest Metrics
- 支持最小化官方docker 鏡像
- 后臺(tái)支持SSL
- 前臺(tái)支持SSL(包括SNI)
- 清爽的AngularJS前端頁(yè)面
- 支持Websocket
- 支持HTTP/2
- 網(wǎng)絡(luò)錯(cuò)誤重試
- 支持Let’s Encrypt (自動(dòng)更新HTTPS證書)
- 高可用集群模式
4-8、小豹API網(wǎng)關(guān)
訪問地址:http://www.xbgateway.com
小豹API網(wǎng)關(guān)(企業(yè)級(jí)API網(wǎng)關(guān)),統(tǒng)一解決:認(rèn)證、鑒權(quán)、安全、流量管控、緩存、服務(wù)路由,協(xié)議轉(zhuǎn)換、服務(wù)編排、熔斷、灰度發(fā)布、監(jiān)控報(bào)警等。