來源: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)的作業機制大體如下:
- Gateway 接收客戶端請求,
- 客戶端請求與路由資訊進行匹配,匹配成功的才能夠被發往相應的下游服務,
- 請求經過 Filter 過濾器鏈,執行 pre 處理邏輯,如修改請求頭資訊等,
- 請求被轉發至下游服務并回傳回應,
- 回應經過 Filter 過濾器鏈,執行 post 處理邏輯,
- 向客戶端回應應答,
請求限流
請求限流是在面對未知流量的情況下,防止系統被沖垮的最后一道有效的防線,可以針對集群、業務系統和具體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開發手冊(嵩山版)》最新發布,速速下載!
覺得不錯,別忘了隨手點贊+轉發哦!
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/445293.html
標籤:其他
