管她前浪，還是後浪？
能浪的浪，才是好浪！
源碼精品專欄
rpc 架構 dubbo 源碼解析
網絡應用架構 netty 源碼解析
消息中間件 rocketmq 源碼解析
資料庫中間件 sharding-jdbc 和 mycat 源碼解析
作業排程中間件 elastic-job 源碼解析
分布式事務中間件 tcc-transaction 源碼解析
eureka 和 hystrix 源碼解析
java 并發源碼
整體架構
域名解析
傳統dns
httpdns
負載均衡
l4 vs l7
lvs轉發模式
排程算法
api網關
api管理
全異步
鍊式處理
請求限流
熔斷降級
業務隔離
push推送
微服務體系
網際網路理想架構
本文探讨了網際網路公司的技術架構，涉及dns、負載均衡、長連接配接、api網關、push推送、微服務、分布式事務以及相關支撐的基礎服務。主要是為了學習，希望可以給大家一個參考。
app、pc以及第三方等調用方通過傳統的域名解析服務localdns擷取負載均衡器的ip，app可以通過httpdns的方式來實作更實時和靈活精準的域名解析服務。
通過負載均衡器到達統一接入層，統一接入層維護長連接配接 。
api網關作為微服務的入口，負責協定轉換、請求路由、認證鑒權、流量控制、資料緩存等。
業務server通過push推送系統來實作對端的實時推送，如im、通知等功能。
業務server之間通過專有的rpc協定實作互相調用，并通過nat網關調用外部第三方服務。
dns（domain name system）域名系統，一種分布式網絡目錄服務，用于域名與ip位址的互相轉換，能夠使人更友善的通路網際網路，而不用去記住機器的ip位址。
dns的解析過程如下：
用戶端遞歸查詢localdns（一般是isp網際網路服務提供商提供的邊緣dns伺服器）擷取ip
localdns疊代查詢擷取ip，即不斷的擷取域名伺服器的位址進行查詢
移動解析（httpdns）基于http協定向dns伺服器發送域名解析請求，替代了基于dns協定向營運商local dns發起解析請求的傳統方式，可以避免local dns造成的域名劫持和跨網通路問題，解決移動網際網路服務中域名解析異常帶來的困擾。
以騰訊雲httpdns為參考，相較于傳統localdns的優勢對比：
為了解決單台機器的性能問題以及單點問題，需要通過負載均衡将多台機器進行水準擴充，将請求流量分發到不同的伺服器上面。
用戶端的流量首先會到達負載均衡伺服器，由負載均衡伺服器通過一定的排程算法将流量分發到不同的應用伺服器上面，同時負載均衡伺服器也會對應用伺服器做周期性的健康檢查，當發現故障節點時便動态的将節點從應用伺服器叢集中剔除，以此來保證應用的高可用。
網絡負載均衡主要有硬體與軟體兩種實作方式，主流負載均衡解決方案中，硬體廠商以f5為代表，軟體主要為lvs、nginx、haproxy。
技術原理上分為l4四層負載均衡和l7七層負載均衡。
l4四層負載均衡工作于處于osi模型的傳輸層，主要工作是轉發。它在接收到用戶端封包後，需要了解傳輸層的協定内容，根據預設的轉發模式和排程算法将封包轉發到應用伺服器。以tcp為例，當一個tcp連接配接的初始syn封包到達時，排程器就選擇一台伺服器，将封包轉發給它。此後通過查發封包的ip和tcp封包頭位址，保證此連接配接的後繼封包被轉發到該伺服器。
l7七層負載均衡工作在osi模型的應用層，主要工作就是代理。七層負載均衡會與用戶端建立一條完整的連接配接并将應用層的請求解析出來，再按照排程算法選擇一個應用伺服器，并與應用伺服器建立另外一條連接配接将請求發送過去。
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 gateway）是一個伺服器叢集，對外的唯一入口。從面向對象設計的角度看，它與外觀模式類似。api網關封裝了系統内部架構，對外提供rest/http的通路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而言，線程是比較重的資源，推薦使用叢集隔離。
消息推送系統 針對不同的場景推出多種推送類型，滿足使用者的個性化推送需求，并內建了蘋果、華為、小米、fcm 等廠商管道的推送功能，在提供控制台快速推送能力的同時，也提供了服務端接入方案，友善使用者快速內建移動終端推送功能，與使用者保持互動，進而有效地提高使用者留存率，提升使用者體驗。
裝置建連、注冊、綁定使用者流程
消息推送過程
在非常多的業務場景中，當業務發生時使用者未必線上，也未必有網絡。是以，在 mps 中所有消息均會被持久化。業務發生時，mps 會嘗試做一次推送（第三方管道推送或自建的tcp 連接配接推送）。自建管道中，會通過查詢緩存來判斷使用者的終端是否有 tcp 連接配接，如果存在則推送，用戶端收到推送消息後，會給服務端回執，服務端即可更新消息狀态。如果推送失敗，或者回執丢失，使用者在下一次建立連接配接時，會重新接受消息通知，同時用戶端會進行邏輯去重。
另寫一篇文章介紹，期待！
https://github.com/yunaiv/ruoyi-vue-pro
https://github.com/yunaiv/onemall
https://github.com/yunaiv/springboot-labs