互聯(lián)網(wǎng)公司理想的技術架構！看完我收藏了

時間：2023-06-20 21:33:02 | 來源：網(wǎng)站運營

時間：2023-06-20 21:33:02 來源：網(wǎng)站運營

互聯(lián)網(wǎng)公司理想的技術架構！看完我收藏了：本文探討了互聯(lián)網(wǎng)公司的技術架構，涉及 DNS、負載均衡、長連接、API 網(wǎng)關、PUSH 推送、微服務、分布式事務以及相關支撐的基礎服務。主要是為了學習，希望可以給大家一個參考。

整體架構

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

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

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

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

域名解析

傳統(tǒng) DNS

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

DNS 的解析過程如下：

• 客戶端遞歸查詢 LocalDNS（一般是 ISP 互聯(lián)網(wǎng)服務提供商提供的邊緣 DNS 服務器）獲取 IP。
• LocalDNS 迭代查詢獲取 IP，即不斷的獲取域名服務器的地址進行查詢。

HttpDNS

移動解析（HttpDNS）基于 Http 協(xié)議向 DNS 服務器發(fā)送域名解析請求，替代了基于 DNS 協(xié)議向運營商 LocalDNS 發(fā)起解析請求的傳統(tǒng)方式。

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

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

負載均衡

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

客戶端的流量首先會到達負載均衡服務器，由負載均衡服務器通過一定的調(diào)度算法將流量分發(fā)到不同的應用服務器上面。

同時負載均衡服務器也會對應用服務器做周期性的健康檢查，當發(fā)現(xiàn)故障節(jié)點時便動態(tài)的將節(jié)點從應用服務器集群中剔除，以此來保證應用的高可用。

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

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

L4 vs L7

L4 四層負載均衡工作于處于 OSI 模型的傳輸層，主要工作是轉(zhuǎn)發(fā)。它在接收到客戶端報文后，需要了解傳輸層的協(xié)議內(nèi)容，根據(jù)預設的轉(zhuǎn)發(fā)模式和調(diào)度算法將報文轉(zhuǎn)發(fā)到應用服務器。

以 TCP 為例，當一個 TCP 連接的初始 SYN 報文到達時，調(diào)度器就選擇一臺服務器，將報文轉(zhuǎn)發(fā)給它。

此后通過查發(fā)報文的 IP 和 TCP 報文頭地址，保證此連接的后繼報文被轉(zhuǎn)發(fā)到該服務器。

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

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

LVS（IP 負載均衡技術）工作在 L4 四層以下，轉(zhuǎn)發(fā)模式有：

• DR 模式
• NAT 模式
• TUNNEL 模式
• FULL NAT 模式

①DR 模式（直接路由）







改寫請求報文的 MAC 地址，將請求發(fā)送到真實服務器，而真實服務器將響應直接返回給客戶。

要求調(diào)度器與真實服務器都有一塊網(wǎng)卡連在同一物理網(wǎng)段上，并且真實服務器需要配置 VIP。

②NAT 模式 （網(wǎng)絡地址轉(zhuǎn)換）







調(diào)度器重寫請求報文的目標地址，根據(jù)預設的調(diào)度算法，將請求分派給后端的真實服務器；真實服務器的響應報文通過調(diào)度器時，報文的源地址被重寫，再返回給客戶，完成整個負載調(diào)度過程。要求負載均衡需要以網(wǎng)關的形式存在于網(wǎng)絡中。

③TUNNEL 模式







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

④FULL NAT 模式







在 NAT 模式的基礎上做一次源地址轉(zhuǎn)換（即 SNAT），做 SNAT 的好處是可以讓應答流量經(jīng)過正常的三層路由回到負載均衡上，這樣負載均衡就不需要以網(wǎng)關的形式存在于網(wǎng)絡中了。

性能要遜色于 NAT 模式，真實服務器會丟失客戶端的真實 IP 地址。

調(diào)度算法

①輪詢

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

②加權輪詢

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

③最少連接

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

④哈希

將指定的 Key 的哈希值與服務器數(shù)目進行取模運算，獲取要求的服務器的序號 一致性哈希。

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

API 網(wǎng)關

API 網(wǎng)關（API Gateway）是一個服務器集群，對外的唯一入口。從面向?qū)ο笤O計的角度看，它與外觀模式類似。

API 網(wǎng)關封裝了系統(tǒng)內(nèi)部架構，對外提供 REST/HTTP 的訪問 API。同時還具有其他非業(yè)務相關的職責，如身份驗證、監(jiān)控、負載均衡、緩存、流量控制等。

API 管理

API 網(wǎng)關核心功能是 API 管理。提供 API 的完整生命周期管理，包括創(chuàng)建、維護、發(fā)布、運行、下線等基礎功能；提供測試，預發(fā)布，發(fā)布等多種環(huán)境；提供版本管理，版本回滾。

API 配置包括前端配置和后端配置：

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

全異步

由于 API 網(wǎng)關主要處理的是網(wǎng)絡 I/O，那么通過非阻塞 I/O 以及 I/O 多路復用，就可以達到使用少量線程承載海量并發(fā)處理，避免線程上下文切換，大大增加系統(tǒng)吞吐量，減少機器成本。

常用解決方案有 Tomcat/Jetty+NIO+Servlet3.1 和 Netty+NIO，這里推薦Netty+NIO，能實現(xiàn)更高的吞吐量。

Spring 5.0 推出的 WebFlux 反應式編程模型，特點是異步的、事件驅(qū)動的、非阻塞，內(nèi)部就是基于 Netty+NIO 或者 Servlet 3.1 Non-Blocking IO 容器實現(xiàn)的。

鏈式處理

鏈式處理即通過責任鏈模式，基于 Filter 鏈的方式提供了網(wǎng)關基本的功能，例如：路由、協(xié)議轉(zhuǎn)換、緩存、限流、監(jiān)控、日志。也可以根據(jù)實際的業(yè)務需要進行擴展，但注意不要做耗時操作。







Spring Cloud Gateway （基于 Spring WebFlux）的工作機制大體如下：

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

請求限流

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

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

常用的限流算法：

• 計數(shù)器
• 漏桶
• 令牌桶（推薦）

熔斷降級

①服務熔斷

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

熔斷是為了解決服務雪崩，特別是在微服務體系下，通常在框架層面進行處理。

內(nèi)部機制采用的是斷路器模式，其內(nèi)部狀態(tài)轉(zhuǎn)換圖如下：







②服務降級

當負荷超出系統(tǒng)整體負載承受能力時，為了保證核心服務的可用，通常可以對非核心服務進行降級。

如果返回緩存內(nèi)容或者直接返回，服務降級的粒度可以是 API 維度、功能維度、甚至是系統(tǒng)維度，但是都需要事前進行服務級別的梳理和定義。

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

業(yè)務隔離

API 網(wǎng)關統(tǒng)一了非業(yè)務層面的處理，但如果有業(yè)務處理的邏輯，不同業(yè)務之間就可能會相互影響。

要進行業(yè)務系統(tǒng)的隔離，通常可以采用線程池隔離和集群隔離，但對于 Java 而言，線程是比較重的資源，推薦使用集群隔離。

PUSH 推送

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







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







②消息推送過程







在非常多的業(yè)務場景中，當業(yè)務發(fā)生時用戶未必在線，也未必有網(wǎng)絡。因此，在 MPS 中所有消息均會被持久化。業(yè)務發(fā)生時，MPS 會嘗試做一次推送（第三方渠道推送或自建的 TCP 連接推送）。

自建渠道中，會通過查詢緩存來判斷用戶的終端是否有 TCP 連接，如果存在則推送，客戶端收到推送消息后，會給服務端回執(zhí)，服務端即可更新消息狀態(tài)。

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

微服務體系

作者：VectorJin
鏈接：https://juejin.cn/post/684490...

推薦閱讀

• PanDownload 復活了！下載速度高達 60MB/s
• 分享一些技術資料（架構、數(shù)據(jù)庫、java等），建議收藏！
• 升職加薪必備！運維工程師打怪升級進階成神之路
• 強大，10k+點贊的 SpringBoot 后臺管理系統(tǒng)竟然出了詳細教程！
• 分享一套基于SpringBoot和Vue的企業(yè)級中后臺開源項目，代碼很規(guī)范！
• 能掙錢的，開源 SpringBoot 商城系統(tǒng)，功能超全，超漂亮！

如有錯誤或其它問題，歡迎小伙伴留言評論、指正。如有幫助，歡迎點贊+轉(zhuǎn)發(fā)分享。

更多相關開源技術文章，請持續(xù)關注：民工哥本站技術專欄

我是民工哥，一個愛折騰的IT技術老司機，歡迎關注我，我們一起學習，共同成長??！