互聯網公司理想架構探討

來源：https://juejin.cn/post/6844904054921887757

互聯網理想架構

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

整體架構

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

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

API 網關作爲微服務的入口，負責協議轉換、請求路由、認證鑑權、流量控制、數據緩存等。

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

業務 Server 之間通過專有的 RPC 協議實現相互調用，並通過 NAT 網關調用外部第三方服務。

域名解析

傳統 DNS

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

DNS 的解析過程如下：

HttpDNS

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

以騰訊雲 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）的工作機制大體如下：

  1. Gateway 接收客戶端請求。

  2. 客戶端請求與路由信息進行匹配，匹配成功的才能夠被髮往相應的下游服務。

  3. 請求經過 Filter 過濾器鏈，執行 pre 處理邏輯，如修改請求頭信息等。

  4. 請求被轉發至下游服務並返回響應。

  5. 響應經過 Filter 過濾器鏈，執行 post 處理邏輯。

  6. 向客戶端響應應答。

請求限流

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

具體實現可以分爲集羣版和單機版，區別就是集羣版是使用後端統一緩存如 Redis 存儲數據，但有一定的性能損耗；單機版則在本機內存中進行存儲（推薦）。

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

熔斷降級

服務熔斷

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

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

服務降級

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

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

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

業務隔離

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

PUSH 推送

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

設備建連、註冊、綁定用戶流程

消息推送過程

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

微服務體系

TODO 另寫一篇文章介紹，期待！

參考資料

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/1iSJdr52lNyRHRIy9He6CQ

猜你喜歡