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

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

整體架構(gòu)

image

APP、PC以及第三方等調(diào)用方通過傳統(tǒng)的域名解析服務(wù)LocalDNS獲取負(fù)載均衡器的IP，APP可以通過HttpDNS的方式來實(shí)現(xiàn)更實(shí)時和靈活精準(zhǔn)的域名解析服務(wù)。

通過負(fù)載均衡器到達(dá)統(tǒng)一接入層，統(tǒng)一接入層維護(hù)長連接 。

API網(wǎng)關(guān)作為微服務(wù)的入口，負(fù)責(zé)協(xié)議轉(zhuǎn)換、請求路由、認(rèn)證鑒權(quán)、流量控制、數(shù)據(jù)緩存等。業(yè)務(wù)Server通過PUSH推送系統(tǒng)來實(shí)現(xiàn)對端的實(shí)時推送，如IM、通知等功能。

業(yè)務(wù)Server之間通過專有的RPC協(xié)議實(shí)現(xiàn)相互調(diào)用，并通過NAT網(wǎng)關(guān)調(diào)用外部第三方服務(wù)。

域名解析

傳統(tǒng)DNS

DNS（Domain Name System）域名系統(tǒng)，一種分布式網(wǎng)絡(luò)目錄服務(wù)，用于域名與IP地址的相互轉(zhuǎn)換，能夠使人更方便的訪問互聯(lián)網(wǎng)，而不用去記住機(jī)器的IP地址。

DNS的解析過程如下：

image

• 客戶端遞歸查詢LocalDNS（一般是ISP互聯(lián)網(wǎng)服務(wù)提供商提供的邊緣DNS服務(wù)器）獲取IP

• LocalDNS迭代查詢獲取IP，即不斷的獲取域名服務(wù)器的地址進(jìn)行查詢

HttpDNS

移動解析（HttpDNS）基于Http協(xié)議向DNS服務(wù)器發(fā)送域名解析請求，替代了基于DNS協(xié)議向運(yùn)營商Local DNS發(fā)起解析請求的傳統(tǒng)方式，可以避免Local DNS造成的域名劫持和跨網(wǎng)訪問問題，解決移動互聯(lián)網(wǎng)服務(wù)中域名解析異常帶來的困擾。

以騰訊云HttpDNS為參考，相較于傳統(tǒng)LocalDNS的優(yōu)勢對比：

負(fù)載均衡

為了解決單臺機(jī)器的性能問題以及單點(diǎn)問題，需要通過負(fù)載均衡將多臺機(jī)器進(jìn)行水平擴(kuò)展，將請求流量分發(fā)到不同的服務(wù)器上面。

客戶端的流量首先會到達(dá)負(fù)載均衡服務(wù)器，由負(fù)載均衡服務(wù)器通過一定的調(diào)度算法將流量分發(fā)到不同的應(yīng)用服務(wù)器上面，同時負(fù)載均衡服務(wù)器也會對應(yīng)用服務(wù)器做周期性的健康檢查，當(dāng)發(fā)現(xiàn)故障節(jié)點(diǎn)時便動態(tài)的將節(jié)點(diǎn)從應(yīng)用服務(wù)器集群中剔除，以此來保證應(yīng)用的高可用。

網(wǎng)絡(luò)負(fù)載均衡主要有硬件與軟件兩種實(shí)現(xiàn)方式，主流負(fù)載均衡解決方案中，硬件廠商以F5為代表，軟件主要為LVS、NGINX、HAProxy。

技術(shù)原理上分為L4四層負(fù)載均衡和L7七層負(fù)載均衡。

L4 vs L7

image

L4四層負(fù)載均衡工作于處于OSI模型的傳輸層，主要工作是轉(zhuǎn)發(fā)。它在接收到客戶端報文后，需要了解傳輸層的協(xié)議內(nèi)容，根據(jù)預(yù)設(shè)的轉(zhuǎn)發(fā)模式和調(diào)度算法將報文轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器。以TCP為例，當(dāng)一個TCP連接的初始SYN報文到達(dá)時，調(diào)度器就選擇一臺服務(wù)器，將報文轉(zhuǎn)發(fā)給它。此后通過查發(fā)報文的IP和TCP報文頭地址，保證此連接的后繼報文被轉(zhuǎn)發(fā)到該服務(wù)器。

L7七層負(fù)載均衡工作在OSI模型的應(yīng)用層，主要工作就是代理。七層負(fù)載均衡會與客戶端建立一條完整的連接并將應(yīng)用層的請求解析出來，再按照調(diào)度算法選擇一個應(yīng)用服務(wù)器，并與應(yīng)用服務(wù)器建立另外一條連接將請求發(fā)送過去。

LVS轉(zhuǎn)發(fā)模式

LVS^[2]（IP負(fù)載均衡技術(shù)）工作在L4四層以下，轉(zhuǎn)發(fā)模式有：DR模式、NAT模式、TUNNEL模式、FULL NAT模式。

image

DR模式（直接路由）

image

改寫請求報文的MAC地址，將請求發(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)度器重寫請求報文的目標(biāo)地址，根據(jù)預(yù)設(shè)的調(diào)度算法，將請求分派給后端的真實(shí)服務(wù)器；真實(shí)服務(wù)器的響應(yīng)報文通過調(diào)度器時，報文的源地址被重寫，再返回給客戶，完成整個負(fù)載調(diào)度過程。要求負(fù)載均衡需要以網(wǎng)關(guān)的形式存在于網(wǎng)絡(luò)中。

TUNNEL模式

image

調(diào)度器把請求報文通過IP隧道轉(zhuǎn)發(fā)至真實(shí)服務(wù)器，而真實(shí)服務(wù)器將響應(yīng)直接返回給客戶，所以調(diào)度器只處理請求報文。要求真實(shí)服務(wù)器支持隧道協(xié)議和配置VIP。

FULL NAT模式

image

在NAT模式的基礎(chǔ)上做一次源地址轉(zhuǎn)換（即SNAT），做SNAT的好處是可以讓應(yīng)答流量經(jīng)過正常的三層路由回到負(fù)載均衡上，這樣負(fù)載均衡就不需要以網(wǎng)關(guān)的形式存在于網(wǎng)絡(luò)中了。性能要遜色于NAT模式，真實(shí)服務(wù)器會丟失客戶端的真實(shí)IP地址。

調(diào)度算法

輪詢

將外部請求按順序輪流分配到集群中的真實(shí)服務(wù)器上，它均等地對待每一臺服務(wù)器，而不管服務(wù)器上實(shí)際的連接數(shù)和系統(tǒng)負(fù)載。

加權(quán)輪詢

權(quán)值越大分配到的訪問概率越高，主要用于后端每臺服務(wù)器性能不均衡的情況下，達(dá)到合理有效的地利用主機(jī)資源。

最少連接

將網(wǎng)絡(luò)請求調(diào)度到已建立的鏈接數(shù)最少的服務(wù)器上。如果集群系統(tǒng)的真實(shí)服務(wù)器具有相近的系統(tǒng)性能，采用"最小連接"調(diào)度算法可以較好地均衡負(fù)載

哈希

將指定的Key的哈希值與服務(wù)器數(shù)目進(jìn)行取模運(yùn)算，獲取要求的服務(wù)器的序號

一致性哈希

考慮到分布式系統(tǒng)每個節(jié)點(diǎn)都有可能失效，并且新的節(jié)點(diǎn)很可能動態(tài)的增加進(jìn)來，一致性哈?？梢员ＷC當(dāng)系統(tǒng)的節(jié)點(diǎn)數(shù)目發(fā)生變化時盡可能減少訪問節(jié)點(diǎn)的移動。

API網(wǎng)關(guān)

API網(wǎng)關(guān)（API Gateway）是一個服務(wù)器集群，對外的唯一入口。從面向?qū)ο笤O(shè)計(jì)的角度看，它與外觀模式類似。API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，對外提供REST/HTTP的訪問API。同時還具有其它非業(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ǔ)功能；提供測試，預(yù)發(fā)布，發(fā)布等多種環(huán)境；提供版本管理，版本回滾。

API配置包括 前端配置 和 后端配置 。前端配置指的是Http相關(guān)的配置，如HTTP 方法、URL路徑，請求參數(shù)等。后端配置指的是微服務(wù)的相關(guān)配置，如服務(wù)名稱、服務(wù)參數(shù)等。這樣通過API配置，就完成了前端Http到后端微服務(wù)的轉(zhuǎn)換。

全異步

由于API網(wǎng)關(guān)主要處理的是網(wǎng)絡(luò)I/O，那么通過非阻塞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ū)動的、非阻塞，內(nèi)部就是基于Netty+NIO 或者 Servlet 3.1 Non-Blocking IO容器 實(shí)現(xiàn)的。

鏈?zhǔn)教幚?/p>

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

image

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

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

請求限流

請求限流是在面對未知流量的情況下，防止系統(tǒng)被沖垮的最后一道有效的防線?？梢葬槍骸I(yè)務(wù)系統(tǒng)和具體API維度進(jìn)行限流。

具體實(shí)現(xiàn)可以分為集群版和單機(jī)版，區(qū)別就是集群版是使用后端統(tǒng)一緩存如Redis存儲數(shù)據(jù)，但有一定的性能損耗；單機(jī)版則在本機(jī)內(nèi)存中進(jìn)行存儲（推薦）。

常用的限流算法：計(jì)數(shù)器、漏桶、令牌桶（推薦）

熔斷降級

服務(wù)熔斷

當(dāng)下游的服務(wù)因?yàn)槟撤N原因突然變得不可用或響應(yīng)過慢，上游服務(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ù)降級

當(dāng)負(fù)荷超出系統(tǒng)整體負(fù)載承受能力時，為了保證核心服務(wù)的可用，通常可以對非核心服務(wù)進(jìn)行降級，如果返回緩存內(nèi)容或者直接返回。

服務(wù)降級的粒度可以是API維度、功能維度、甚至是系統(tǒng)維度，但是都需要事前進(jìn)行服務(wù)級別的梳理和定義。

真實(shí)場景下，通常是在服務(wù)器負(fù)載超出閾值報警之后，管理員決定是擴(kuò)容還是降級。

業(yè)務(wù)隔離

API網(wǎng)關(guān)統(tǒng)一了非業(yè)務(wù)層面的處理，但如果有業(yè)務(wù)處理的邏輯，不同業(yè)務(wù)之間就可能會相互影響。要進(jìn)行業(yè)務(wù)系統(tǒng)的隔離，通?？梢圆捎镁€程池隔離和集群隔離，但對于Java而言，線程是比較重的資源，推薦使用集群隔離。

PUSH推送

消息推送系統(tǒng) 針對不同的場景推出多種推送類型，滿足用戶的個性化推送需求，并集成了蘋果、華為、小米、FCM 等廠商渠道的推送功能，在提供控制臺快速推送能力的同時，也提供了服務(wù)端接入方案，方便用戶快速集成移動終端推送功能，與用戶保持互動，從而有效地提高用戶留存率，提升用戶體驗(yàn)。

image

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

image

消息推送過程

image

在非常多的業(yè)務(wù)場景中，當(dāng)業(yè)務(wù)發(fā)生時用戶未必在線，也未必有網(wǎng)絡(luò)。因此，在 MPS 中所有消息均會被持久化。業(yè)務(wù)發(fā)生時，MPS 會嘗試做一次推送（第三方渠道推送或自建的TCP 連接推送）。自建渠道中，會通過查詢緩存來判斷用戶的終端是否有 TCP 連接，如果存在則推送，客戶端收到推送消息后，會給服務(wù)端回執(zhí)，服務(wù)端即可更新消息狀態(tài)。如果推送失敗，或者回執(zhí)丟失，用戶在下一次建立連接時，會重新接受消息通知，同時客戶端會進(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.itdecent.cn/p/76cc8ba5ca91

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

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