一套互聯網公司理想架構，建議收藏。。。

來源：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的解析過程如下：

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

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另寫一篇文章介紹，期待！

參考資料

• http://www.linuxvirtualserver.org/zh/lvs1.html
• https://www.infoq.cn/article/Maglev-Vortex/
• https://www.cnblogs.com/mindwind/p/5339657.html
• https://blog.csdn.net/gaopeiliang/article/details/54864410
• https://www.jianshu.com/p/76cc8ba5ca91
• https://www.jianshu.com/p/cda7c0366089
• https://juejin.im/post/6844903775912607758

近期熱文推薦：

1.1,000+ 道 Java面試題及答案整理(2022最新版)

2.勁爆！Java 協程要來了。。。

3.Spring Boot 2.x 教程，太全了！

4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！

5.《Java開發手冊（嵩山版）》最新發布，速速下載！

覺得不錯，別忘了隨手點贊+轉發哦！