網際網路理想架構

VectorJin發表於2020-02-01

架構

本文探討了網際網路公司的技術架構，涉及DNS、負載均衡、長連線、API閘道器、PUSH推送、微服務、分散式事務以及相關支撐的基礎服務。主要是為了學習，希望可以給大家一個參考。

整體架構

APP、PC以及第三方等呼叫方通過傳統的域名解析服務LocalDNS獲取負載均衡器的IP，APP可以通過HttpDNS的方式來實現更實時和靈活精準的域名解析服務。

通過負載均衡器到達統一接入層，統一接入層維護長連線。

API閘道器作為微服務的入口，負責協議轉換、請求路由、認證鑑權、流量控制、資料快取等。

業務Server通過PUSH推送系統來實現對端的實時推送，如IM、通知等功能。

業務Server之間通過專有的RPC協議實現相互呼叫，並通過NAT閘道器呼叫外部第三方服務。

域名解析

傳統DNS

DNS（Domain Name System）域名系統，一種分散式網路目錄服務，用於域名與IP地址的相互轉換，能夠使人更方便的訪問網際網路，而不用去記住機器的IP地址。

DNS的解析過程如下：

客戶端遞迴查詢LocalDNS（一般是ISP網際網路服務提供商提供的邊緣DNS伺服器）獲取IP
LocalDNS迭代查詢獲取IP，即不斷的獲取域名伺服器的地址進行查詢

HttpDNS

移動解析（HttpDNS）基於Http協議向DNS伺服器傳送域名解析請求，替代了基於DNS協議向運營商Local DNS發起解析請求的傳統方式，可以避免Local DNS造成的域名劫持和跨網訪問問題，解決移動網際網路服務中域名解析異常帶來的困擾。

以騰訊雲HttpDNS為參考，相較於傳統LocalDNS的優勢對比：

優勢	騰訊雲HttpDNS	運營商LocalDNS
高速	接入節點覆蓋國內Top17運營商、東南亞及北美，解析精準，訪問迅速	使用者跨網訪問、解析異常問題
安全	繞開運營商Local DNS，無劫持，防止DNS被汙染攔截	域名解析結果被指向廣告頁面、插入第三方廣告
智慧	精確識別來源請求，訪問導向最準確節點	自身不進行域名遞迴解析，而把請求轉發給其他運營商
可靠	一個IP三地叢集容災，秒級自動故障切換，服務提供99%以上的SLA	快取伺服器運維環境參差不齊，時有故障

負載均衡

為了解決單臺機器的效能問題以及單點問題，需要通過負載均衡將多臺機器進行水平擴充套件，將請求流量分發到不同的伺服器上面。

客戶端的流量首先會到達負載均衡伺服器，由負載均衡伺服器通過一定的排程演算法將流量分發到不同的應用伺服器上面，同時負載均衡伺服器也會對應用伺服器做週期性的健康檢查，當發現故障節點時便動態的將節點從應用伺服器叢集中剔除，以此來保證應用的高可用。

網路負載均衡主要有硬體與軟體兩種實現方式，主流負載均衡解決方案中，硬體廠商以F5為代表，軟體主要為LVS、NGINX、HAProxy。

技術原理上分為L4四層負載均衡和L7七層負載均衡。

L4 vs L7

L4四層負載均衡工作於處於OSI模型的傳輸層，主要工作是轉發。它在接收到客戶端報文後，需要了解傳輸層的協議內容，根據預設的轉發模式和排程演算法將報文轉發到應用伺服器。以TCP為例，當一個TCP連線的初始SYN報文到達時，排程器就選擇一臺伺服器，將報文轉發給它。此後通過查發報文的IP和TCP報文頭地址，保證此連線的後繼報文被轉發到該伺服器。

L7七層負載均衡工作在OSI模型的應用層，主要工作就是代理。七層負載均衡會與客戶端建立一條完整的連線並將應用層的請求解析出來，再按照排程演算法選擇一個應用伺服器，並與應用伺服器建立另外一條連線將請求傳送過去。

LVS轉發模式

LVS（IP負載均衡技術）工作在L4四層以下，轉發模式有：DR模式、NAT模式、TUNNEL模式、FULL NAT模式。

DR模式（直接路由）

改寫請求報文的MAC地址，將請求傳送到真實伺服器，而真實伺服器將響應直接返回給客戶。要求排程器與真實伺服器都有一塊網路卡連在同一物理網段上，並且真實伺服器需要配置VIP。

NAT模式 （網路地址轉換）

排程器重寫請求報文的目標地址，根據預設的排程演算法，將請求分派給後端的真實伺服器；真實伺服器的響應報文通過排程器時，報文的源地址被重寫，再返回給客戶，完成整個負載排程過程。要求負載均衡需要以閘道器的形式存在於網路中。

TUNNEL模式

排程器把請求報文通過IP隧道轉發至真實伺服器，而真實伺服器將響應直接返回給客戶，所以排程器只處理請求報文。要求真實伺服器支援隧道協議和配置VIP。

FULL NAT模式

在NAT模式的基礎上做一次源地址轉換（即SNAT），做SNAT的好處是可以讓應答流量經過正常的三層路由回到負載均衡上，這樣負載均衡就不需要以閘道器的形式存在於網路中了。效能要遜色於NAT模式，真實伺服器會丟失客戶端的真實IP地址。

排程演算法

輪詢

將外部請求按順序輪流分配到叢集中的真實伺服器上，它均等地對待每一臺伺服器，而不管伺服器上實際的連線數和系統負載。

加權輪詢

權值越大分配到的訪問概率越高，主要用於後端每臺伺服器效能不均衡的情況下，達到合理有效的地利用主機資源。

最少連線

將網路請求排程到已建立的連結數最少的伺服器上。如果叢集系統的真實伺服器具有相近的系統效能，採用"最小連線"排程演算法可以較好地均衡負載

雜湊

將指定的Key的雜湊值與伺服器數目進行取模運算，獲取要求的伺服器的序號

一致性雜湊

考慮到分散式系統每個節點都有可能失效，並且新的節點很可能動態的增加進來，一致性雜湊可以保證當系統的節點數目發生變化時儘可能減少訪問節點的移動。

API閘道器

API閘道器（API Gateway）是一個伺服器叢集，對外的唯一入口。從物件導向設計的角度看，它與外觀模式類似。API閘道器封裝了系統內部架構，對外提供REST/HTTP的訪問API。同時還具有其它非業務相關的職責，如身份驗證、監控、負載均衡、快取、流量控制等。

API管理

API閘道器核心功能是 API 管理。提供 API 的完整生命週期管理，包括建立、維護、釋出、執行、下線等基礎功能；提供測試，預釋出，釋出等多種環境；提供版本管理，版本回滾。

API配置包括 前端配置 和 後端配置 。前端配置指的是Http相關的配置，如HTTP 方法、URL路徑，請求引數等。後端配置指的是微服務的相關配置，如服務名稱、服務引數等。這樣通過API配置，就完成了前端Http到後端微服務的轉換。

全非同步

由於API閘道器主要處理的是網路I/O，那麼通過非阻塞I/O以及I/O多路複用，就可以達到使用少量執行緒承載海量併發處理，避免執行緒上下文切換，大大增加系統吞吐量，減少機器成本。

常用解決方案有 Tomcat/Jetty+NIO+servlet3.1 和 Netty+NIO，這裡推薦Netty+NIO，能實現更高的吞吐量。Spring 5.0 推出的WebFlux反應式程式設計模型，特點是非同步的、事件驅動的、非阻塞，內部就是基於Netty+NIO 或者 Servlet 3.1 Non-Blocking IO容器實現的。

鏈式處理

鏈式處理即通過責任鏈模式，基於 Filter 鏈的方式提供了閘道器基本的功能，例如：路由、協議轉換、快取、限流、監控、日誌。也可以根據實際的業務需要進行擴充套件，但注意不要做耗時操作。

Spring cloud gateway （基於 Spring WebFlux）的工作機制大體如下：

Gateway 接收客戶端請求。
客戶端請求與路由資訊進行匹配，匹配成功的才能夠被髮往相應的下游服務。
請求經過 Filter 過濾器鏈，執行 pre 處理邏輯，如修改請求頭資訊等。
請求被轉發至下游服務並返回響應。
響應經過 Filter 過濾器鏈，執行 post 處理邏輯。
向客戶端響應應答。

請求限流

請求限流是在面對未知流量的情況下，防止系統被沖垮的最後一道有效的防線。可以針對叢集、業務系統和具體API維度進行限流。

具體實現可以分為叢集版和單機版，區別就是叢集版是使用後端統一快取如Redis儲存資料，但有一定的效能損耗；單機版則在本機記憶體中進行儲存（推薦）。

常用的限流演算法：計數器、漏桶、令牌桶（推薦）

熔斷降級

服務熔斷

當下遊的服務因為某種原因突然變得不可用或響應過慢，上游服務為了保證自己整體服務的可用性，不再繼續呼叫目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復呼叫。

熔斷是為了解決服務雪崩，特別是在微服務體系下，通常在框架層面進行處理。內部機制採用的是斷路器模式，其內部狀態轉換圖如下：

服務降級

當負荷超出系統整體負載承受能力時，為了保證核心服務的可用，通常可以對非核心服務進行降級，如果返回快取內容或者直接返回。

服務降級的粒度可以是API維度、功能維度、甚至是系統維度，但是都需要事前進行服務級別的梳理和定義。

真實場景下，通常是在伺服器負載超出閾值報警之後，管理員決定是擴容還是降級。

業務隔離

API閘道器統一了非業務層面的處理，但如果有業務處理的邏輯，不同業務之間就可能會相互影響。要進行業務系統的隔離，通常可以採用執行緒池隔離和叢集隔離，但對於Java而言，執行緒是比較重的資源，推薦使用叢集隔離。

PUSH推送

訊息推送系統針對不同的場景推出多種推送型別，滿足使用者的個性化推送需求，並整合了蘋果、華為、小米、FCM 等廠商渠道的推送功能，在提供控制檯快速推送能力的同時，也提供了服務端接入方案，方便使用者快速整合移動終端推送功能，與使用者保持互動，從而有效地提高使用者留存率，提升使用者體驗。

裝置建連、註冊、繫結使用者流程

訊息推送過程

在非常多的業務場景中，當業務發生時使用者未必線上，也未必有網路。因此，在 MPS 中所有訊息均會被持久化。業務發生時，MPS 會嘗試做一次推送（第三方渠道推送或自建的TCP 連線推送）。自建渠道中，會通過查詢快取來判斷使用者的終端是否有 TCP 連線，如果存在則推送，客戶端收到推送訊息後，會給服務端回執，服務端即可更新訊息狀態。如果推送失敗，或者回執丟失，使用者在下一次建立連線時，會重新接受訊息通知，同時客戶端會進行邏輯去重。