點(diǎn)擊上方[全棧開發(fā)者社區(qū)]→右上角[...]→[設(shè)為星標(biāo)?]
點(diǎn)擊領(lǐng)取全棧資料：全棧資料
本文探討了某互聯(lián)網(wǎng)公司的技術(shù)架構(gòu)，涉及DNS、負(fù)載均衡、長(zhǎng)連接、API網(wǎng)關(guān)、PUSH推送、微服務(wù)、分布式事務(wù)以及相關(guān)支撐的基礎(chǔ)服務(wù)。
整體架構(gòu)
APP、PC以及第三方等調(diào)用方通過(guò)傳統(tǒng)的域名解析服務(wù)LocalDNS獲取負(fù)載均衡器的IP，APP可以通過(guò)HttpDNS的方式來(lái)實(shí)現(xiàn)更實(shí)時(shí)和靈活精準(zhǔn)的域名解析服務(wù)。通過(guò)負(fù)載均衡器到達(dá)統(tǒng)一接入層，統(tǒng)一接入層維護(hù)長(zhǎng)連接 。API網(wǎng)關(guān)作為微服務(wù)的入口，負(fù)責(zé)協(xié)議轉(zhuǎn)換、請(qǐng)求路由、認(rèn)證鑒權(quán)、流量控制、數(shù)據(jù)緩存等。業(yè)務(wù)Server通過(guò)PUSH推送系統(tǒng)來(lái)實(shí)現(xiàn)對(duì)端的實(shí)時(shí)推送，如IM、通知等功能。業(yè)務(wù)Server之間通過(guò)專有的RPC協(xié)議實(shí)現(xiàn)相互調(diào)用，并通過(guò)NAT網(wǎng)關(guān)調(diào)用外部第三方服務(wù)。域名解析
傳統(tǒng)DNS
DNS（Domain Name System）域名系統(tǒng)，一種分布式網(wǎng)絡(luò)目錄服務(wù)，用于域名與IP地址的相互轉(zhuǎn)換，能夠使人更方便的訪問(wèn)互聯(lián)網(wǎng)，而不用去記住機(jī)器的IP地址。
- 客戶端遞歸查詢LocalDNS（一般是ISP互聯(lián)網(wǎng)服務(wù)提供商提供的邊緣DNS服務(wù)器）獲取IP
- LocalDNS迭代查詢獲取IP，即不斷的獲取域名服務(wù)器的地址進(jìn)行查詢
HttpDNS
移動(dòng)解析（HttpDNS）基于Http協(xié)議向DNS服務(wù)器發(fā)送域名解析請(qǐng)求，替代了基于DNS協(xié)議向運(yùn)營(yíng)商Local DNS發(fā)起解析請(qǐng)求的傳統(tǒng)方式，可以避免Local DNS造成的域名劫持和跨網(wǎng)訪問(wèn)問(wèn)題，解決移動(dòng)互聯(lián)網(wǎng)服務(wù)中域名解析異常帶來(lái)的困擾。以騰訊云HttpDNS為參考，相較于傳統(tǒng)LocalDNS的優(yōu)勢(shì)對(duì)比：
| 優(yōu)勢(shì) | 騰訊云HttpDNS | 運(yùn)營(yíng)商LocalDNS |
| 接入節(jié)點(diǎn)覆蓋國(guó)內(nèi)Top17運(yùn)營(yíng)商、東南亞及北美，解析精準(zhǔn)，訪問(wèn)迅速 | 用戶跨網(wǎng)訪問(wèn)、解析異常問(wèn)題 |
| 繞開運(yùn)營(yíng)商Local DNS，無(wú)劫持，防止DNS被污染攔截 | 域名解析結(jié)果被指向廣告頁(yè)面、插入第三方廣告 |
| 精確識(shí)別來(lái)源請(qǐng)求，訪問(wèn)導(dǎo)向最準(zhǔn)確節(jié)點(diǎn) | 自身不進(jìn)行域名遞歸解析，而把請(qǐng)求轉(zhuǎn)發(fā)給其他運(yùn)營(yíng)商 |
| 一個(gè)IP三地集群容災(zāi)，秒級(jí)自動(dòng)故障切換，服務(wù)提供99%以上的SLA | 緩存服務(wù)器運(yùn)維環(huán)境參差不齊，時(shí)有故障 |
負(fù)載均衡
為了解決單臺(tái)機(jī)器的性能問(wèn)題以及單點(diǎn)問(wèn)題，需要通過(guò)負(fù)載均衡將多臺(tái)機(jī)器進(jìn)行水平擴(kuò)展，將請(qǐng)求流量分發(fā)到不同的服務(wù)器上面。客戶端的流量首先會(huì)到達(dá)負(fù)載均衡服務(wù)器，由負(fù)載均衡服務(wù)器通過(guò)一定的調(diào)度算法將流量分發(fā)到不同的應(yīng)用服務(wù)器上面，同時(shí)負(fù)載均衡服務(wù)器也會(huì)對(duì)應(yīng)用服務(wù)器做周期性的健康檢查，當(dāng)發(fā)現(xiàn)故障節(jié)點(diǎn)時(shí)便動(dòng)態(tài)的將節(jié)點(diǎn)從應(yīng)用服務(wù)器集群中剔除，以此來(lái)保證應(yīng)用的高可用。網(wǎng)絡(luò)負(fù)載均衡主要有硬件與軟件兩種實(shí)現(xiàn)方式，主流負(fù)載均衡解決方案中，硬件廠商以F5為代表，軟件主要為L(zhǎng)VS、NGINX、HAProxy。技術(shù)原理上分為L(zhǎng)4四層負(fù)載均衡和L7七層負(fù)載均衡。
L4 vs L7
L4四層負(fù)載均衡工作于處于OSI模型的傳輸層，主要工作是轉(zhuǎn)發(fā)。它在接收到客戶端報(bào)文后，需要了解傳輸層的協(xié)議內(nèi)容，根據(jù)預(yù)設(shè)的轉(zhuǎn)發(fā)模式和調(diào)度算法將報(bào)文轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器。以TCP為例，當(dāng)一個(gè)TCP連接的初始SYN報(bào)文到達(dá)時(shí)，調(diào)度器就選擇一臺(tái)服務(wù)器，將報(bào)文轉(zhuǎn)發(fā)給它。此后通過(guò)查發(fā)報(bào)文的IP和TCP報(bào)文頭地址，保證此連接的后繼報(bào)文被轉(zhuǎn)發(fā)到該服務(wù)器。L7七層負(fù)載均衡工作在OSI模型的應(yīng)用層，主要工作就是代理。七層負(fù)載均衡會(huì)與客戶端建立一條完整的連接并將應(yīng)用層的請(qǐng)求解析出來(lái)，再按照調(diào)度算法選擇一個(gè)應(yīng)用服務(wù)器，并與應(yīng)用服務(wù)器建立另外一條連接將請(qǐng)求發(fā)送過(guò)去。
LVS轉(zhuǎn)發(fā)模式
LVS（IP負(fù)載均衡技術(shù)）工作在L4四層以下，轉(zhuǎn)發(fā)模式有：DR模式、NAT模式、TUNNEL模式、FULL NAT模式。改寫請(qǐng)求報(bào)文的MAC地址，將請(qǐng)求發(fā)送到真實(shí)服務(wù)器，而真實(shí)服務(wù)器將響應(yīng)直接返回給客戶。要求調(diào)度器與真實(shí)服務(wù)器都有一塊網(wǎng)卡連在同一物理網(wǎng)段上，并且真實(shí)服務(wù)器需要配置VIP。NAT模式 （網(wǎng)絡(luò)地址轉(zhuǎn)換）調(diào)度器重寫請(qǐng)求報(bào)文的目標(biāo)地址，根據(jù)預(yù)設(shè)的調(diào)度算法，將請(qǐng)求分派給后端的真實(shí)服務(wù)器；真實(shí)服務(wù)器的響應(yīng)報(bào)文通過(guò)調(diào)度器時(shí)，報(bào)文的源地址被重寫，再返回給客戶，完成整個(gè)負(fù)載調(diào)度過(guò)程。要求負(fù)載均衡需要以網(wǎng)關(guān)的形式存在于網(wǎng)絡(luò)中。
調(diào)度器把請(qǐng)求報(bào)文通過(guò)IP隧道轉(zhuǎn)發(fā)至真實(shí)服務(wù)器，而真實(shí)服務(wù)器將響應(yīng)直接返回給客戶，所以調(diào)度器只處理請(qǐng)求報(bào)文。要求真實(shí)服務(wù)器支持隧道協(xié)議和配置VIP。在NAT模式的基礎(chǔ)上做一次源地址轉(zhuǎn)換（即SNAT），做SNAT的好處是可以讓應(yīng)答流量經(jīng)過(guò)正常的三層路由回到負(fù)載均衡上，這樣負(fù)載均衡就不需要以網(wǎng)關(guān)的形式存在于網(wǎng)絡(luò)中了。性能要遜色于NAT模式，真實(shí)服務(wù)器會(huì)丟失客戶端的真實(shí)IP地址。調(diào)度算法
將外部請(qǐng)求按順序輪流分配到集群中的真實(shí)服務(wù)器上，它均等地對(duì)待每一臺(tái)服務(wù)器，而不管服務(wù)器上實(shí)際的連接數(shù)和系統(tǒng)負(fù)載。權(quán)值越大分配到的訪問(wèn)概率越高，主要用于后端每臺(tái)服務(wù)器性能不均衡的情況下，達(dá)到合理有效的地利用主機(jī)資源。將網(wǎng)絡(luò)請(qǐng)求調(diào)度到已建立的鏈接數(shù)最少的服務(wù)器上。如果集群系統(tǒng)的真實(shí)服務(wù)器具有相近的系統(tǒng)性能，采用"最小連接"調(diào)度算法可以較好地均衡負(fù)載將指定的Key的哈希值與服務(wù)器數(shù)目進(jìn)行取模運(yùn)算，獲取要求的服務(wù)器的序號(hào)考慮到分布式系統(tǒng)每個(gè)節(jié)點(diǎn)都有可能失效，并且新的節(jié)點(diǎn)很可能動(dòng)態(tài)的增加進(jìn)來(lái)，一致性哈希可以保證當(dāng)系統(tǒng)的節(jié)點(diǎn)數(shù)目發(fā)生變化時(shí)盡可能減少訪問(wèn)節(jié)點(diǎn)的移動(dòng)。
API網(wǎng)關(guān)
API網(wǎng)關(guān)（API Gateway）是一個(gè)服務(wù)器集群，對(duì)外的唯一入口。從面向?qū)ο笤O(shè)計(jì)的角度看，它與外觀模式類似。API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，對(duì)外提供REST/HTTP的訪問(wèn)API。同時(shí)還具有其它非業(yè)務(wù)相關(guān)的職責(zé)，如身份驗(yàn)證、監(jiān)控、負(fù)載均衡、緩存、流量控制等。
API管理
API網(wǎng)關(guān)核心功能是 API 管理。提供 API 的完整生命周期管理，包括創(chuàng)建、維護(hù)、發(fā)布、運(yùn)行、下線等基礎(chǔ)功能；提供測(cè)試，預(yù)發(fā)布，發(fā)布等多種環(huán)境；提供版本管理，版本回滾。
API配置包括 前端配置 和 后端配置 。前端配置指的是Http相關(guān)的配置，如HTTP 方法、URL路徑，請(qǐng)求參數(shù)等。后端配置指的是微服務(wù)的相關(guān)配置，如服務(wù)名稱、服務(wù)參數(shù)等。這樣通過(guò)API配置，就完成了前端Http到后端微服務(wù)的轉(zhuǎn)換。
全異步
由于API網(wǎng)關(guān)主要處理的是網(wǎng)絡(luò)I/O，那么通過(guò)非阻塞I/O以及I/O多路復(fù)用，就可以達(dá)到使用少量線程承載海量并發(fā)處理，避免線程上下文切換，大大增加系統(tǒng)吞吐量，減少機(jī)器成本。常用解決方案有 Tomcat/Jetty+NIO+servlet3.1 和 Netty+NIO，這里推薦Netty+NIO，能實(shí)現(xiàn)更高的吞吐量。Spring 5.0 推出的WebFlux反應(yīng)式編程模型，特點(diǎn)是異步的、事件驅(qū)動(dòng)的、非阻塞，內(nèi)部就是基于Netty+NIO 或者 Servlet 3.1 Non-Blocking IO容器 實(shí)現(xiàn)的。
鏈?zhǔn)教幚?/h3>
鏈?zhǔn)教幚砑赐ㄟ^(guò)責(zé)任鏈模式，基于 Filter 鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：路由、協(xié)議轉(zhuǎn)換、緩存、限流、監(jiān)控、日志。也可以根據(jù)實(shí)際的業(yè)務(wù)需要進(jìn)行擴(kuò)展，但注意不要做耗時(shí)操作。Spring cloud gateway （基于 Spring WebFlux）的工作機(jī)制大體如下：
- 客戶端請(qǐng)求與路由信息進(jìn)行匹配，匹配成功的才能夠被發(fā)往相應(yīng)的下游服務(wù)。
- 請(qǐng)求經(jīng)過(guò) Filter 過(guò)濾器鏈，執(zhí)行 pre 處理邏輯，如修改請(qǐng)求頭信息等。
- 請(qǐng)求被轉(zhuǎn)發(fā)至下游服務(wù)并返回響應(yīng)。
- 響應(yīng)經(jīng)過(guò) Filter 過(guò)濾器鏈，執(zhí)行 post 處理邏輯。
請(qǐng)求限流
請(qǐng)求限流是在面對(duì)未知流量的情況下，防止系統(tǒng)被沖垮的最后一道有效的防線?？梢葬槍?duì)集群、業(yè)務(wù)系統(tǒng)和具體API維度進(jìn)行限流。具體實(shí)現(xiàn)可以分為集群版和單機(jī)版，區(qū)別就是集群版是使用后端統(tǒng)一緩存如Redis存儲(chǔ)數(shù)據(jù)，但有一定的性能損耗；單機(jī)版則在本機(jī)內(nèi)存中進(jìn)行存儲(chǔ)（推薦）。常用的限流算法：計(jì)數(shù)器、漏桶、令牌桶（推薦）
熔斷降級(jí)
當(dāng)下游的服務(wù)因?yàn)槟撤N原因突然變得不可用或響應(yīng)過(guò)慢，上游服務(wù)為了保證自己整體服務(wù)的可用性，不再繼續(xù)調(diào)用目標(biāo)服務(wù)，直接返回，快速釋放資源。如果目標(biāo)服務(wù)情況好轉(zhuǎn)則恢復(fù)調(diào)用。熔斷是為了解決服務(wù)雪崩，特別是在微服務(wù)體系下，通常在框架層面進(jìn)行處理。內(nèi)部機(jī)制采用的是斷路器模式，其內(nèi)部狀態(tài)轉(zhuǎn)換圖如下：當(dāng)負(fù)荷超出系統(tǒng)整體負(fù)載承受能力時(shí)，為了保證核心服務(wù)的可用，通?？梢詫?duì)非核心服務(wù)進(jìn)行降級(jí)，如果返回緩存內(nèi)容或者直接返回。服務(wù)降級(jí)的粒度可以是API維度、功能維度、甚至是系統(tǒng)維度，但是都需要事前進(jìn)行服務(wù)級(jí)別的梳理和定義。真實(shí)場(chǎng)景下，通常是在服務(wù)器負(fù)載超出閾值報(bào)警之后，管理員決定是擴(kuò)容還是降級(jí)。業(yè)務(wù)隔離
API網(wǎng)關(guān)統(tǒng)一了非業(yè)務(wù)層面的處理，但如果有業(yè)務(wù)處理的邏輯，不同業(yè)務(wù)之間就可能會(huì)相互影響。要進(jìn)行業(yè)務(wù)系統(tǒng)的隔離，通?？梢圆捎镁€程池隔離和集群隔離，但對(duì)于Java而言，線程是比較重的資源，推薦使用集群隔離。PUSH推送
消息推送系統(tǒng) 針對(duì)不同的場(chǎng)景推出多種推送類型，滿足用戶的個(gè)性化推送需求，并集成了蘋果、華為、小米、FCM 等廠商渠道的推送功能，在提供控制臺(tái)快速推送能力的同時(shí)，也提供了服務(wù)端接入方案，方便用戶快速集成移動(dòng)終端推送功能，與用戶保持互動(dòng)，從而有效地提高用戶留存率，提升用戶體驗(yàn)。
在非常多的業(yè)務(wù)場(chǎng)景中，當(dāng)業(yè)務(wù)發(fā)生時(shí)用戶未必在線，也未必有網(wǎng)絡(luò)。因此，在 MPS 中所有消息均會(huì)被持久化。業(yè)務(wù)發(fā)生時(shí)，MPS 會(huì)嘗試做一次推送（第三方渠道推送或自建的TCP 連接推送）。自建渠道中，會(huì)通過(guò)查詢緩存來(lái)判斷用戶的終端是否有 TCP 連接，如果存在則推送，客戶端收到推送消息后，會(huì)給服務(wù)端回執(zhí)，服務(wù)端即可更新消息狀態(tài)。如果推送失敗，或者回執(zhí)丟失，用戶在下一次建立連接時(shí)，會(huì)重新接受消息通知，同時(shí)客戶端會(huì)進(jìn)行邏輯去重。微服務(wù)體系
覺(jué)得本文對(duì)你有幫助？請(qǐng)分享給更多人
關(guān)注「全棧開發(fā)者社區(qū)」加星標(biāo)，提升全棧技能
本公眾號(hào)會(huì)不定期給大家發(fā)福利，包括送書、學(xué)習(xí)資源等，敬請(qǐng)期待吧！
如果感覺(jué)推送內(nèi)容不錯(cuò)，不妨右下角點(diǎn)個(gè)在看轉(zhuǎn)發(fā)朋友圈或收藏，感謝支持。
好文章，留言、點(diǎn)贊、在看和分享一條龍吧??
