想進入互聯網公司，怎能不知道互聯網的技術架構！

• 2020 年 2 月 24 日
• 筆記

本文探討了互聯網公司的技術架構，涉及 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 協議向運營商 LocalDNS 發起解析請求的傳統方式。

它可以避免 LocalDNS 造成的域名劫持和跨網訪問問題，解決移動互聯網服務中域名解析異常帶來的困擾。

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

負載均衡

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

客戶端的流量首先會到達負載均衡伺服器，由負載均衡伺服器通過一定的調度演算法將流量分發到不同的應用伺服器上面。

同時負載均衡伺服器也會對應用伺服器做周期性的健康檢查，當發現故障節點時便動態的將節點從應用伺服器集群中剔除，以此來保證應用的高可用。

網路負載均衡主要有硬體與軟體兩種實現方式，主流負載均衡解決方案中，硬體廠商以 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 連接，如果存在則推送，客戶端收到推送消息後，會給服務端回執，服務端即可更新消息狀態。

如果推送失敗，或者回執丟失，用戶在下一次建立連接時，會重新接受消息通知，同時客戶端會進行邏輯去重。

微服務體系