互聯網公司理想的技術架構！看完我收藏了

本文探討了互聯網公司的技術架構，涉及 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 鏈接，若是存在則推送，客戶端收到推送消息後，會給服務端回執，服務端便可更新消息狀態。

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

微服務體系

做者：VectorJin
連接：https://juejin.cn/post/684490...