网关 架构演进及实践
因公眾號更改推送規(guī)則,請點“在看”并加“星標(biāo)”第一時間獲取精彩技術(shù)分享
點擊關(guān)注#互聯(lián)網(wǎng)架構(gòu)師公眾號,領(lǐng)取架構(gòu)師全套資料 都在這里
0、2T架構(gòu)師學(xué)習(xí)資料干貨分
上一篇:分布式系統(tǒng)設(shè)計模式,你用過哪些?
大家好,我是互聯(lián)網(wǎng)架構(gòu)師!
網(wǎng)關(guān)是每個大公司系統(tǒng)都具備的一個重要的模塊,今天這篇是關(guān)于網(wǎng)關(guān)架構(gòu)演進(jìn)的,相信能給大家?guī)砗芏鄦l(fā)。
1、前言
天翼賬號是中國電信打造的互聯(lián)網(wǎng)賬號體系產(chǎn)品,利用中國電信管道優(yōu)勢為企業(yè)提供用戶身份認(rèn)證能力。其中網(wǎng)關(guān)系統(tǒng)是天翼賬號對外能力開放體系的重要組成:業(yè)務(wù)側(cè)它以集中入口、集中計費、集中鑒權(quán)管控為目標(biāo),技術(shù)側(cè)它支持隔離性、可配置、易開發(fā)、動態(tài)路由、可降級、高并發(fā)等場景。
自 2017 年天翼賬號網(wǎng)關(guān)系統(tǒng)上線以來,歷經(jīng)數(shù)次互聯(lián)網(wǎng)的營銷大促活動,特別是 2021 年的春節(jié)紅包活動和剛過去雙 11 活動,天翼賬號網(wǎng)關(guān)系統(tǒng)在 10 萬級 QPS 和 10 億級日請求量的情況下,各項指標(biāo)依然保持平穩(wěn),順利保障合作方活動的開展。在天翼賬號產(chǎn)品能力不斷提升的背后,是天翼賬號網(wǎng)關(guān)系統(tǒng)架構(gòu)技術(shù)迭代發(fā)展的過程。
2、天翼賬號網(wǎng)關(guān)演進(jìn)
2.1 重點演進(jìn)歷程介紹
2017 年~ 2021 年天翼賬號網(wǎng)關(guān)系統(tǒng)經(jīng)歷數(shù)次重要更迭升級,每次升級都給產(chǎn)品帶來新的發(fā)展機會,系統(tǒng)總體演進(jìn)過程如下:
2.2 天翼賬號網(wǎng)關(guān)系統(tǒng) 1.0
2017 年初,天翼賬號技術(shù)團隊基于開源微服務(wù)網(wǎng)關(guān) Zuul 組件開展了網(wǎng)關(guān)系統(tǒng) 1.0 的建設(shè)。Zuul 是 Spring Cloud 工具包 Netflix 分組的開源微服務(wù)網(wǎng)關(guān),它和 Eureka、ribbon、hystrix 等組件配合使用,本質(zhì)是通過一系列的核心 filter,來實現(xiàn)請求過程的認(rèn)證安全、動態(tài)路由、數(shù)據(jù)轉(zhuǎn)化、熔斷保護(hù)等功能。其系統(tǒng)核心運行流程如下:
2018 年中,隨著天翼賬號推出免密認(rèn)證系列產(chǎn)品的快速發(fā)展,網(wǎng)關(guān)系統(tǒng) 1.0 的缺點日益凸顯主要表現(xiàn)在兩個方面:
性能瓶頸:?微服務(wù)網(wǎng)關(guān) Zuul 組件基于 Servlet 框架構(gòu)建,采用的是阻塞和多線程方式實現(xiàn),高并發(fā)下內(nèi)部延遲嚴(yán)重,會造成連接增多和線程增加等情況,導(dǎo)致阻塞發(fā)生,在實際業(yè)務(wù)應(yīng)用中單機性能在 1000 QPS 左右。
靈活度有限:為了實現(xiàn)路由和 Filter 動態(tài)配置,研發(fā)人員需要花費時間去整合開源適配 Zuul 組件控制系統(tǒng)。
為應(yīng)對業(yè)務(wù)高峰,技術(shù)側(cè)常采用橫向擴展實例的策略來實現(xiàn)對高并發(fā)的支持,該策略給系統(tǒng)穩(wěn)定性帶來一定的風(fēng)險,同時部署大量的網(wǎng)關(guān)服務(wù)器也提高產(chǎn)品的運營維護(hù)成本,因此網(wǎng)關(guān)系統(tǒng)架構(gòu)升級迫在眉睫。
2.3 天翼賬號網(wǎng)關(guān)系統(tǒng) 2.0
2.3.1 技術(shù)選型
互聯(lián)網(wǎng)企業(yè)常見的方案有基于 Openresty 的 Kong、Orange,基于 Go 的 Tyk 和基于 Java 的 Zuul:
apiaxle、api-umbrella:?考慮到學(xué)習(xí)成本和項目后期發(fā)展的兼容性,其語言和框架不在團隊優(yōu)先考慮范圍
Zuul:目前正在應(yīng)用中,Zuul 處理請求的方式是針對每個請求都啟用一個線程來處理。通常情況下,為了提高性能,所有請求被放到處理隊列中,等待空閑線程來處理。當(dāng)存在大量請求超時后會造成 Zuul 線程阻塞,目前只能通過橫向擴展 Zuul 實例實現(xiàn)對高并發(fā)的支持。而 Zuul2.0 將 HTTP 請求的處理方式從同步變成了異步,以此提升處理性能。但團隊內(nèi)部對繼續(xù)采用 Zuul 比較慎重,原因主要有以下兩點:
版本穩(wěn)定性需要斟酌 ,Zuul 的開源社區(qū)比較活躍,一直在更新狀態(tài)
應(yīng)用企業(yè)較少,除了 Netflix,目前 Zuul 在企業(yè)中的應(yīng)用還比較少,性能和穩(wěn)定性方面還有待觀察
Nginx:?高性能的 HTTP 和反向代理 Web 服務(wù)器,應(yīng)用場景涉及負(fù)載均衡、反向代理、代理緩存、限流等場景。但 Nginx 作為 Web 容器應(yīng)用場景較少。Nginx 性能優(yōu)越,而 Nginx 開發(fā)主要是以 C/C++ 模塊的形式進(jìn)行,整體學(xué)習(xí)和開發(fā)成本偏高。Nginx 團隊開發(fā)了 NginxScript,可以在 Nginx 中使用 JavaScript 進(jìn)行動態(tài)配置變量和動態(tài)腳本執(zhí)行。
目前行業(yè)應(yīng)用非常成熟的擴展是由章亦春將 Lua 和 Nginx 黏合的 ngx_Lua 模塊,將 Nginx 核心、LuaJIT、ngx_Lua 模塊、多功能 Lua 庫和常用的第三方 Nginx 模塊整合成為 OpenResty。開發(fā)人員安裝 OpenResty,使用 Lua 編寫腳本,部署到 Nginx Web 容器中運行,能輕松地開發(fā)出高性能的 Web 服務(wù)。OpenResty 具有高性能,易擴展的特點,成為了團隊首選。同時也面臨兩個選項:
基于 OpenResty 自建,例如:一個類似于某東 JEN 的系統(tǒng)
對開源框架二次開發(fā),例如:Kong、Orange
根據(jù)調(diào)研結(jié)果,團隊衡量學(xué)習(xí)成本和開發(fā)周期等因素,最終決定采用對 Kong 框架二次開發(fā)的方案。以下是調(diào)研后的一些對比總結(jié),僅供參考,如有疏漏,請不吝指出。
2.3.2 架構(gòu)升級
天翼賬號技術(shù)團隊制定了網(wǎng)關(guān)系統(tǒng) 2.0 演進(jìn)方案,部署架構(gòu)如圖:
自研插件
除了 Kong 網(wǎng)關(guān)自帶的原生組件外,2.0 網(wǎng)關(guān)系統(tǒng)還相繼研發(fā)出:加密鑒權(quán)、日志處理、參數(shù)轉(zhuǎn)換、接口協(xié)議、消息隊列、服務(wù)穩(wěn)定、鏈路追蹤及其它等 8 大類共計約 30 多個組件。豐富的自研組件,保障了系統(tǒng)架構(gòu)平穩(wěn)的升級和業(yè)務(wù)的靈活性:
支持產(chǎn)品 Appkey 認(rèn)證,SSL/TLS 加密,支持針對 IP 或應(yīng)用的黑、白名單
符合自身業(yè)務(wù)的協(xié)議插件,包括了常見的加密、簽名算法和國密 sm2,sm3,sm4 等金融級別的算法
監(jiān)控和統(tǒng)計方面增加了基于 Redis、Kafka 的異步日志匯聚、統(tǒng)計方式,并支持 Zipkin、Prometheus 的追蹤、監(jiān)控
增加多種按業(yè)務(wù)精細(xì)化分類的限流熔斷策略,進(jìn)一步完善服務(wù)保障體系
改造上游
利用 Go 語言的高并發(fā)特性,對上游并發(fā)量大的微服務(wù)進(jìn)行重構(gòu)。
2.3.3 效果
網(wǎng)關(guān) 2.0 通過對 Kong 組件自研插件的開發(fā)和改造,實現(xiàn)了符合產(chǎn)品特性、業(yè)務(wù)場景的相關(guān)功能,也抽象了網(wǎng)關(guān)的通用功能。相較于 1.0 版本,具備以下優(yōu)點:
支持插件化,方便自定義業(yè)務(wù)開發(fā)
支持橫向擴展,高性能、高并發(fā)、多級緩存
高可用、高穩(wěn)定性,具備隔離、限流、超時與重試、回滾機制
插件熱啟用,即插即拔、動態(tài)靈活、無需重啟,能快速適用業(yè)務(wù)變化
為了驗證新架構(gòu)的性能,團隊對網(wǎng)關(guān)系統(tǒng) 2.0 進(jìn)行了壓測:
結(jié)果 1:17:26 在當(dāng)前測試環(huán)境下 QPS 在 1.2W 左右
結(jié)果 2:18:06 取消 Prometheus、流量控制、日志、權(quán)限校驗等插件,QPS 達(dá)到 1.3W+
壓測結(jié)果表明,天翼賬號網(wǎng)關(guān)系統(tǒng) 2.0 已經(jīng)達(dá)到單機萬級 QPS,自研插件運行效率較高,對于網(wǎng)關(guān)性能的影響較小。
天翼賬號網(wǎng)關(guān)系統(tǒng) 2.0 初期是基于 Kong-v0.14.0 版本開發(fā),運行至 2019 年 5 月時,Kong 已經(jīng)更新到 v1.1.X 版本,有很多重要的功能和核心代碼更新,而且為了便于跟 Kubernetes 集成,團隊決定將版本升至 v1.1.X。
通過同步遷移、并行運行的方式天翼賬號網(wǎng)關(guān)系統(tǒng) 2.1 于 2019 年 9 月完成 Kong-v1.3 版本的升級。期間天翼賬號網(wǎng)關(guān)系統(tǒng)仍平穩(wěn)地完成了 2018 年阿里雙 11 活動、2019 年春節(jié)活動等大型高并發(fā)場景的支撐工作。2020 年 3 月,網(wǎng)關(guān) 2.1 及底層微服務(wù)完成了鏡像化改造,即可通過 Kubernetes 自動編排容器的方式部署,在動態(tài)擴容等方面有較大的提升。
2.4 天翼賬號網(wǎng)關(guān)系統(tǒng) 3.0
隨著免密認(rèn)證逐漸成為互聯(lián)網(wǎng)應(yīng)用作為首選登錄方式,互聯(lián)網(wǎng)頭部企業(yè)要求認(rèn)證產(chǎn)品 SLA 相關(guān)技術(shù)指標(biāo)對齊其內(nèi)部指標(biāo),為了支撐產(chǎn)品精細(xì)化運營和進(jìn)一步的發(fā)展,保障產(chǎn)品 SLA 合同及性能指標(biāo),技術(shù)團隊制定了網(wǎng)關(guān)系統(tǒng) 3.0 演進(jìn)方案。
3.0 網(wǎng)關(guān)部署架構(gòu)圖如下:
2.4.1 DP(Data Plane) 升級
2.4.1.1 Kong 組件升級
團隊摸余(魚)工程師對開源項目 Kong 的版本發(fā)布一直保持著較高的關(guān)注度,總結(jié)兩年來 Kong 主要版本升級新特性:
考慮到 Kong 2.5.0 版本為剛剛發(fā)布的版本,采用的企業(yè)用戶不多,且開源社區(qū)對之前發(fā)布的 V2.4.0 版有較好的評價,因此團隊評審后決定升級到 V2.4.0。
Kong 2.4.0 采用 OpenResty1.19.3.1,基于 Nginx 1.19.3,官方文檔測試單 Worker 可達(dá) 269,423 QPS。以 2.0 版本同樣環(huán)境壓測,天翼賬號網(wǎng)關(guān)系統(tǒng) 3.0(Kong 2.4) QPS 可達(dá)到 2W+,對比天翼賬號網(wǎng)關(guān) 2.X(Kong 1.3) QPS 1W+,性能預(yù)估可提升 80% 以上。
Kong 2.4.0 組件采用控制面 / 數(shù)據(jù)面(CP/DP) 混合部署新模式,具備以下優(yōu)勢:
功能解耦
混合部署模式,CP 負(fù)責(zé)將配置數(shù)據(jù)推動到 DP 節(jié)點,DP 節(jié)點負(fù)責(zé)流量數(shù)據(jù)處理。
運行穩(wěn)定
當(dāng) CP 不可用時,DP 可按照本地存儲的配置進(jìn)行流量業(yè)務(wù)處理,待 CP 恢復(fù),DP 會自動連接更新配置。
支持多語言插件
在原有 Lua 插件的基礎(chǔ)上,支持使用 JavaScript 、TypeScript、GO 編寫插件,后端 GO 語言團隊可進(jìn)行相關(guān)擴展。
支持 UDP 代理
Routes、Services、Load Balancing、日志插件支持 UDP 代理,滿足業(yè)務(wù)發(fā)展需要。
2.4.1.2 精確網(wǎng)關(guān)分組
頂層采用分域名業(yè)務(wù)隔離,同時根據(jù)業(yè)務(wù)特性、保障級別、訪問并發(fā)量等特點,對網(wǎng)關(guān)集群進(jìn)行分組,完成子業(yè)務(wù)關(guān)聯(lián)性解耦,在應(yīng)對大流量沖擊時降低對業(yè)務(wù)的影響,同時方便運維側(cè)精準(zhǔn)擴容。
2.4.1.3 混合云
新建阿里云節(jié)點,作為天翼賬號產(chǎn)品雙活系統(tǒng)的補充節(jié)點,在高并發(fā)時可由 DNS 調(diào)度實現(xiàn)自動切換,確保提供無間斷的服務(wù)。
2.4.2 CP(Control Plane) 升級
2.4.2.1 優(yōu)化調(diào)用鏈路
增加 Consul 作為服務(wù)發(fā)現(xiàn)、配置管理中心服務(wù),替換原有 Nginx 層路由功能。對 Kong 組件提供 DNS 路由及發(fā)現(xiàn)服務(wù),通過 Check 方式檢查微服務(wù)是否可用。
2.4.2.2 新增插件
DP 緩存控制插件
Kong 2.4 采用 DP 和 CP 混合部署模式,DP 平面的節(jié)點無管理端口,原 Kong 1.3 通過 admin API 管理緩存的模式無法適用現(xiàn)有場景,因此研發(fā)了 c-cache-manage 插件,添加后,可通過數(shù)據(jù)層面 URL 請求對 DP 緩存進(jìn)行管理。
流量復(fù)制插件
為了測試網(wǎng)關(guān) 3.0 的適用性,團隊自研流量復(fù)制插件,復(fù)制現(xiàn)網(wǎng)流量對網(wǎng)關(guān) 3.0 進(jìn)行測試,整個測試過程不影響現(xiàn)網(wǎng)環(huán)境。
插件運行流程如下:
Konga 配置界面參考:
Prometheus 插件改造
為了更好的展示 DP 和 CP 層面的數(shù)據(jù),對自帶 Prometheus 插件進(jìn)行改造,增加 DP、CP 角色維度,區(qū)分并收集數(shù)據(jù)平面相關(guān)監(jiān)控指標(biāo)。
2.4.2.3 完善預(yù)警監(jiān)控
在系統(tǒng)原有的監(jiān)控的基礎(chǔ)上,增加業(yè)務(wù)處理監(jiān)控,通過業(yè)務(wù)處理監(jiān)控,可將異常被動通知,轉(zhuǎn)為主動發(fā)現(xiàn)。業(yè)務(wù)出現(xiàn)異常,可第一時間協(xié)助客戶處理,提升系統(tǒng)的效能。
2.4.3 效果
演進(jìn)完成后天翼賬號網(wǎng)關(guān)系統(tǒng) 3.0 具備以下優(yōu)勢:
高并發(fā),可支撐十萬級 QPS
高可用 ,保障系統(tǒng) SLA 達(dá)到 99.96%
靈活性伸縮性、 DNS 調(diào)度自動切換,可通過阿里云 ACK 迅速擴容
豐富開發(fā)和應(yīng)用場景,支持多語言插件(Go、Javascript、Lua), 支持 UDP 代理
天翼賬號網(wǎng)關(guān)系統(tǒng) 3.0 的部署,有效地保障了系統(tǒng)服務(wù) SLA 等各項指標(biāo)的達(dá)成。在今年雙 11 期間十萬級并發(fā)高峰時,系統(tǒng) TP99 保持在 20MS 以內(nèi),總體表現(xiàn)非常穩(wěn)定。
3、后序
天翼賬號網(wǎng)關(guān)經(jīng)過多次演進(jìn),已日趨完善,總結(jié)其優(yōu)勢如下:
系統(tǒng)性能大幅度提升,天翼賬號網(wǎng)關(guān)系統(tǒng) 3.0 相較 1.0 性能提升 20 倍以上
統(tǒng)一網(wǎng)關(guān)流量入口,超過 90% 以上流量由天翼賬號網(wǎng)關(guān)系統(tǒng)管控
系統(tǒng)可用性得到加強,建立了基于 DNS 調(diào)度自動切換的三節(jié)點、混合云穩(wěn)定架構(gòu)
標(biāo)準(zhǔn)化可復(fù)用的插件,如頻控限流、降級熔斷、流量復(fù)制、API 協(xié)議等標(biāo)準(zhǔn)化插件
豐富的多語言插件能力,Lua、Go、Javascript 的插件,可滿足不同技術(shù)團隊的需求
天翼賬號網(wǎng)關(guān)系統(tǒng)在中國電信統(tǒng)一賬號能力開放平臺中處于舉足輕重的地位,它的迭代升級,為平臺十萬級高并發(fā)提供了堅實的保障,也為系統(tǒng)維護(hù)減少了難度、提升了便捷性,順利支撐業(yè)務(wù)達(dá)成億級收入規(guī)模。天翼賬號技術(shù)團隊在 follow 業(yè)界主流網(wǎng)關(guān)技術(shù)的同時,也注重強化網(wǎng)關(guān)插件的標(biāo)準(zhǔn)化、服務(wù)化建設(shè),希望通過網(wǎng)關(guān)能力反哺其它產(chǎn)品賦能大網(wǎng)。隨著中國電信服務(wù)化、容器化、全面上云的戰(zhàn)略推進(jìn),天翼賬號網(wǎng)關(guān)的系統(tǒng)架構(gòu)也將隨之變化,從全傳統(tǒng)環(huán)境到部分云化再到全量上云,不斷的向更貼近業(yè)務(wù),更適用技術(shù)發(fā)展的形態(tài)演進(jìn)。
? 來源:
? xie.infoq.cn/article/c6703d216c43c2b522b9b4ffa
相關(guān)閱讀:
1、Alibaba開源內(nèi)網(wǎng)高并發(fā)編程手冊.pdf
2、2T架構(gòu)師學(xué)習(xí)資料干貨分享
3、10000+TB 資源,阿里云盤,牛逼!!
4、基本涵蓋了Spring所有核心知識點總結(jié)
? · END ·
最后,關(guān)注公眾號互聯(lián)網(wǎng)架構(gòu)師,在后臺回復(fù):2T,可以獲取我整理的 Java 系列面試題和答案,非常齊全。
如果這篇文章對您有所幫助,或者有所啟發(fā)的話,幫忙掃描下發(fā)二維碼關(guān)注一下,您的支持是我堅持寫作最大的動力。
求一鍵三連:點贊、轉(zhuǎn)發(fā)、在看。
總結(jié)
以上是生活随笔為你收集整理的网关 架构演进及实践的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 1024电商项目的邮箱验证码与图形验证码
- 下一篇: redis 缓存 key常量命名规则