來(lái)自：掘金，作者：VectorJin
鏈接：https://juejin.im/post/5e353a14e51d453cf422c6cb

本文探討了互聯(lián)網(wǎng)公司的技術(shù)架構(gòu)^[1]贺辰，涉及DNS禀崖、負(fù)載均衡稽物、長(zhǎng)連接巢价、API網(wǎng)關(guān)倒得、PUSH推送、微服務(wù)厨幻、分布式事務(wù)以及相關(guān)支撐的基礎(chǔ)服務(wù)相嵌。主要是為了學(xué)習(xí)，希望可以給大家一個(gè)參考况脆。

整體架構(gòu)

image

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地址帕涌。

DNS的解析過(guò)程如下：

image

• 客戶端遞歸查詢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ì)比：

負(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

image

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^[2]（IP負(fù)載均衡技術(shù)）工作在L4四層以下灭将，轉(zhuǎn)發(fā)模式有：DR模式、NAT模式后控、TUNNEL模式庙曙、FULL NAT模式。

image

DR模式（直接路由）

image

改寫(xiě)請(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)換）

image

調(diào)度器重寫(xiě)請(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)文的源地址被重寫(xiě)泽台，再返回給客戶什荣，完成整個(gè)負(fù)載調(diào)度過(guò)程。要求負(fù)載均衡需要以網(wǎng)關(guān)的形式存在于網(wǎng)絡(luò)中怀酷。

TUNNEL模式

image

調(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桅锄。

FULL NAT模式

image

在NAT模式的基礎(chǔ)上做一次源地址轉(zhuǎn)換（即SNAT），做SNAT的好處是可以讓?xiě)?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)輪詢

權(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)教幚?/p>

鏈?zhǔn)教幚砑赐ㄟ^(guò)責(zé)任鏈模式州疾，基于 Filter 鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：路由皇拣、協(xié)議轉(zhuǎn)換严蓖、緩存、限流、監(jiān)控颗胡、日志毫深。也可以根據(jù)實(shí)際的業(yè)務(wù)需要進(jìn)行擴(kuò)展，但注意不要做耗時(shí)操作杭措。

image

Spring cloud gateway （基于 Spring WebFlux）的工作機(jī)制大體如下：

1. Gateway 接收客戶端請(qǐng)求费什。
2. 客戶端請(qǐng)求與路由信息進(jìn)行匹配，匹配成功的才能夠被發(fā)往相應(yīng)的下游服務(wù)手素。
3. 請(qǐng)求經(jīng)過(guò) Filter 過(guò)濾器鏈，執(zhí)行 pre 處理邏輯瘩蚪，如修改請(qǐng)求頭信息等泉懦。
4. 請(qǐng)求被轉(zhuǎn)發(fā)至下游服務(wù)并返回響應(yīng)。
5. 響應(yīng)經(jīng)過(guò) Filter 過(guò)濾器鏈疹瘦，執(zhí)行 post 處理邏輯崩哩。
6. 向客戶端響應(yīng)應(yīng)答。

請(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í)

服務(wù)熔斷

當(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)換圖如下：

image

服務(wù)降級(jí)

當(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è)性化推送需求漆枚，并集成了蘋(píng)果创译、華為、小米浪读、FCM 等廠商渠道的推送功能昔榴，在提供控制臺(tái)快速推送能力的同時(shí)，也提供了服務(wù)端接入方案碘橘，方便用戶快速集成移動(dòng)終端推送功能互订，與用戶保持互動(dòng)，從而有效地提高用戶留存率痘拆，提升用戶體驗(yàn)仰禽。

image

設(shè)備建連、注冊(cè)纺蛆、綁定用戶流程

image

消息推送過(guò)程

image

在非常多的業(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ù)體系

image

參考資料

[1]原文鏈接: https://juejin.im/post/5e353a14e51d453cf422c6cb

[2]LVS項(xiàng)目介紹: http://www.linuxvirtualserver.org/zh/lvs1.html

[3]從Maglev到Vortex: https://www.infoq.cn/article/Maglev-Vortex/

[4]LB 負(fù)載均衡的層次結(jié)構(gòu): https://www.cnblogs.com/mindwind/p/5339657.html

[5]美團(tuán)l4負(fù)載均衡: https://blog.csdn.net/gaopeiliang/article/details/54864410

[6]談?wù)勏蘖魉惴ǖ膸追N實(shí)現(xiàn): http://www.reibang.com/p/76cc8ba5ca91

[7]高并發(fā)之服務(wù)熔斷與降級(jí): http://www.reibang.com/p/cda7c0366089

[8]螞蟻金服消息推送 MPS 架構(gòu)及流程設(shè)計(jì): https://juejin.im/post/5c63ab376fb9a049f43bce85