億級流量架構怎么做資源隔離？寫得太好了！

作者：等不到的口琴

鏈接：https://www.cnblogs.com/Courage129/p/14421585.html

為什么要資源隔離

常見的資源,例如磁盤、網路、CPU等等,都會存在競爭的問題,在構建分布式架構時,可以將原本連接在一起的組件、模塊、資源拆分開來,以便達到最大的利用效率或性能，資源隔離之后,當某一部分組件出現故障時,可以隔離故障,方便定位的同時,阻止傳播,避免出現滾雪球以及雪崩效應，

常見的隔離方式有:

• 執行緒隔離
• 行程隔離
• 集群隔離
• 機房隔離
• 讀寫隔離
• 動靜隔離
• 爬蟲隔離
• 等等

執行緒隔離

網路上很多帖子,大多是從框架開始聊的,這兒說人話其實就是對執行緒進行治理,把核心業務執行緒與非核心業務執行緒隔開,不同的業務需要的執行緒數量不同,可以設定不同的執行緒池,來舉一些框架中應用的例子,例如Netty中的主從多執行緒、Tomcat請求隔離、Dubbo執行緒模型，

Netty主從程模型

主執行緒負責認證，連接，成功之后交由從執行緒負責連接的讀寫操作，大致如下代碼：

EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();

ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup);

主執行緒是一個單執行緒，從執行緒是一個默認為cpu*2個數的執行緒池，可以在我們的業務handler中做一個簡單測驗：

public void channelRead(ChannelHandlerContext ctx, Object msg) {
	System.out.println("thread name=" + Thread.currentThread().getName() + " server receive msg=" + msg);
}

服務端在讀取資料的時候列印一下當前的執行緒：

thread name=nioEventLoopGroup-3-1 server receive msg="..."

可以發現這里使用的執行緒其實和處理io執行緒是同一個；

Dubbo執行緒隔離模型

Dubbo的底層通信框架其實使用的就是Netty，但是Dubbo并沒有直接使用Netty的io執行緒來處理業務，可以簡單在生產者端輸出當前執行緒名稱：

thread name=DubboServerHandler-192.168.1.115:20880-thread-2,...

可以發現業務邏輯使用并不是nioEventLoopGroup執行緒，這是因為Dubbo有自己的執行緒模型，可以看看官網提供的模型圖：

由圖可以知道,Dubbo服務端接收到請求后,通過調度器(Dispatcher)分發到不同的執行緒池，也簡單做一些關于調度器(Dispatcher)總結:

Dispatcher調度器可以配置訊息的處理執行緒：

• all 所有訊息都派發到執行緒池，包括請求，回應，連接事件，斷開事件，心跳等，
• direct 所有訊息都不派發到執行緒池，全部在 IO 執行緒上直接執行，
• message 只有請求回應訊息派發到執行緒池，其它連接斷開事件，心跳等訊息，直接在 IO 執行緒上執行，
• execution 只有請求訊息派發到執行緒池，不含回應，回應和其它連接斷開事件，心跳等訊息，直接在 IO 執行緒上執行，
• connection 在 IO 執行緒上，將連接斷開事件放入佇列，有序逐個執行，其它訊息派發到執行緒池，

通過看原始碼可以知道,Dubbo默認使用的執行緒池是FixedThreadPool ，執行緒數默認為200 ；

Tomcat請求執行緒隔離

Tomcat是Servelet的具體實作,在Tomcat請求支持四種請求處理方式分別為:BIO、AIO、NIO、APR

BIO模式：阻塞式I/O操作，表示Tomcat使用的是傳統Java，I/O操作(即Java.io包及其子包)，Tomcat7以下版本默認情況下是以bio模式運行的，由于每個請求都要創建一個執行緒來處理，執行緒開銷較大，不能處理高并發的場景，在幾種模式中性能也最低，

NIO模式：同步非阻塞I/O操作，是一個基于緩沖區、并能提供非阻塞I/O操作的API，它擁有比傳統I/O操作具有更好的并發性能，

在Tomcat7版本之后,Tomcat把連接介入和業務處理拆分成兩個執行緒池來處理，即:

可以使用獨立的執行緒池來維護servlet的創建，連接器connector能介入的請求肯定比業務復雜的servlet處理的個數要多，在中間，Tomcat加入了佇列，來等待servlet執行緒池空閑，這兩步是Tomcat內核完成的，在一階段無法區分具體業務或資源，所以只能在連接介入，servlet初始化完成后我們根據自己的業務線去劃分獨立的連接池，

這樣做,獨立的業務或資源中如果出現崩潰，不會影響其他的業務執行緒，從而達到資源隔離和服務降級的效果，

在使用了servlet3之后，系統執行緒隔離變得更靈活了，可以劃分核心業務佇列和非核心業務佇列:

執行緒隔離小總結

1. 資源一旦出現問題，雖然是隔離狀態，想要讓資源重新可用，很難做到不重啟jvm，
2. 執行緒池內部執行緒如果出現OOM、FullGC、cpu耗盡等問題也是無法控制的
3. 執行緒隔離，只能保證在分配執行緒這個資源上進行隔離，并不能保證整體穩定性

行程隔離

行程隔離這種思想其實并不陌生,Linux作業系統中,利用檔案管理系統將各個行程的虛擬記憶體與實際的物理記憶體映射起來,這樣做的好處是避免不同的行程之間相互影響,而在分布式系統中,執行緒隔離不能完全隔離故障避免雪崩,例如某個執行緒組耗盡記憶體導致OOM,那么其他執行緒組勢必也會受影響,所以行程隔離的思想是,CPU、記憶體等等這些資源也通過不同的虛擬機來做隔離，

具體操作是,將業務邏輯進行拆分成多個子系統(拆分原則可以參考:Redis集群拆分原則之AKF)，實作物理隔離，當某一個子系統出現問題，不會影響到其他子系統，

集群隔離

如果系統中某個業務模塊包含像搶購、秒殺、存盤I/O密集度高、網路I/o高、計算I/O高這類需求的時候，很容易在并發量高的時候因為這種功能把整個模塊占有的資源全部耗盡，導致回應編碼甚至節點不可用，

像上圖的的拆分之后,如果某一天購物人數瞬間暴增,電商交易功能模塊可能受影響,損壞后導致電商模塊其他的瀏覽查詢也無法使用,因此就要建立集群進行隔離,具體來說就是繼續拆分模塊,將功能微服務化，

解決方案

• 獨立拆分模塊
• 微服務化

可以使用hystrix在微服務中隔離分布式服務故障，他可以通過執行緒和信號量進行隔離，

執行緒池隔離與信號量隔離對比

這兒同上面的執行緒隔離,不多贅述,簡單敘述一下hystrix的兩種隔離方式的區別:

信號量隔離

說人話就是,很多執行緒涌過來,要去獲得信號量,獲得了才能繼續執行,否則先進入佇列等待或者直接fallback回呼

最重要的是，信號量的呼叫是同步的，也就是說，每次呼叫都得阻塞呼叫方的執行緒，直到結果回傳，這樣就導致了無法對訪問做超時（只能依靠呼叫協議超時，無法主動釋放）

官網對信號量隔離的描述建議

• Generally the only time you should use semaphore isolation for HystrixCommands is when the call is so high volume (hundreds per second, per instance) that the overhead of separate threads is too high; this typically only applies to non-network calls.

理解下兩點：

1. 隔離的細粒度太高，數百個實體需要隔離，此時用執行緒池做隔離開銷過大
2. 通常這種都是非網路呼叫的情況下

機房隔離

機房隔離主要目的有兩個,一方面是將不同區域的用戶資料隔離到不同的地區,例如湖北的資料放在湖北的服務器,浙江的放在浙江服務器,等等,這樣能解決資料容量大，計算密集，i/o（網路）密集度高的問題,相當于將流量分在了各個區域，

另一方面,機房隔離也是為了保證安全性,所有資料都放在一個地方,如果發生自然災害或者爆炸等災害時,資料將全都丟失,所以把服務建立整體副本（計算服務、資料存盤），在多機房內做異地多活或冷備份、是微服務資料異構的放大版本，

如果機房層面出現問題的時候，可以通過智能dns、httpdns、負載均衡等技術快速切換,讓區域用戶盡量不收影響，

資料讀寫隔離

通過主從模式，將mysql、redis等資料存盤服務集群化，讀寫分離，那么在寫入資料不可用的時候，也可以通過重試機制 臨時通過其他節點讀取到資料，

多節點在做子網劃分的時候，除了異地多活，還可以做資料中心，所有資料在本地機房crud 異步同步到資料中心，資料中心再去分發資料給其他機房,那么資料臨時在本地機房不可用的時候，就可以嘗試連接異地機房或資料中心，

靜態隔離

主要思路是將一些靜態資源分發在邊緣服務器中,因為日常訪問中有很多資源是不會變的,所以沒必要每次都想從主服務器上獲取,可以將這些資料保存在邊緣服務器上降低主服務器的壓力，

有一篇很詳細的講解參考:全域負載均衡與CDN內容分發

爬蟲隔離

建立合適的規則,將爬蟲請求轉移到另外的集群 ，

目前我們開發的都是API介面，并且多數都是開放的API介面，也就是說，只要有人拿到這個介面，任何人都可以通過這個API介面獲取資料，如果是網路爬蟲請求速度快，獲取的資料多，不僅會對服務器造成影響,不用多久，爬蟲方完全可以用我們API的介面來開發一個同樣的網站，開放平臺的API介面呼叫需要限制其頻率，以節約服務器資源和避免惡意的頻繁呼叫,在大型互聯網專案中，對于web服務和網路爬蟲的訪問流量能達到5:1，甚至更高，有的系統有時候就會因為爬蟲流量過高而導致資源耗盡，服務不可用，解決策略大致兩個方面:

一是限流，限制訪問的頻率;

二是將爬蟲請求轉發到固定地方，

爬蟲限流

• 登錄/會話限制
• 下載限流
• 訪問頻率
• ip限制，黑白名單

想要分辨出來一個訪問是不是爬蟲，可以簡單的使用nginx來分析ua處理

UA介紹

User Agent 簡稱UA，就是用戶代理，通常我們用瀏覽器訪問網站，在網站的日志中，我們的瀏覽器就是一種UA，

禁止特定UA訪問,例如最近有個網站A抄襲公司主站B的內容，除了域名不同，內容、圖片等都完全是我們主站的內容，出現這種情況，有兩種可能:

一種是：它用爬蟲抓取公司主站B的內容并放到自己服務器上顯示；

另一種是：通過將訪問代理至公司主站B，而域名A是盜用者的，騙取流量，

無論怎樣，都要禁止這種行為的繼續，有兩種方法解決：

1）禁止IP

2）禁止UA

從nginx日志觀察，訪問者的代理IP經常變，但是訪問UA卻是固定的，因而可以禁止UA，

nginx不僅可以處理ua來分離流量，還可以通過更強大的openresty來完成更復雜的邏輯，實作一個流量網關，軟防火墻，

近期熱文推薦：

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

2.別在再滿屏的 if/ else 了，試試策略模式，真香！！

3.臥槽！Java 中的 xx ≠ null 是什么新語法？

4.Spring Boot 2.5 重磅發布，黑暗模式太炸了！

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

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

標籤：其他

上一篇：C語言 __LINE__ - C語言零基礎入門教程

下一篇：記一次stormOOM例外的產生與解決