## 為什麼要資源隔離 常見的資源,例如磁碟、網路、CPU等等,都會存在競爭的問題,在構建分散式架構時,可以將原本連線在一起的元件、模組、資源拆分開來,以便達到最大的利用效率或效能。資源隔離之後,當某一部分元件出現故障時,可以隔離故障,方便定位的同時,阻止傳播,避免出現滾雪球以及雪崩效應。 常見的隔離方式有: - 執行緒隔離 - 程序隔離 - 叢集隔離 - 機房隔離 - 讀寫隔離 - 動靜隔離 - 爬蟲隔離 - 等等 ## 執行緒隔離 網路上很多帖子,大多是從框架開始聊的,這兒說人話其實就是對執行緒進行治理,把核心業務執行緒與非核心業務執行緒隔開,不同的業務需要的執行緒數量不同,可以設定不同的執行緒池,來舉一些框架中應用的例子,例如Netty中的主從多執行緒、Tomcat請求隔離、Dubbo執行緒模型。 ### Netty主從程模型  主執行緒負責認證，連線，成功之後交由從執行緒負責連線的讀寫操作，大致如下程式碼： ```java EventLoopGroup bossGroup = new NioEventLoopGroup(1); EventLoopGroup workerGroup = new NioEventLoopGroup(); ServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup); ``` 主執行緒是一個單執行緒，從執行緒是一個預設為cpu*2個數的執行緒池，可以在我們的業務handler中做一個簡單測試： ```java public void channelRead(ChannelHandlerContext ctx, Object msg) { System.out.println("thread name=" + Thread.currentThread().getName() + " server receive msg=" + msg); } ``` 服務端在讀取資料的時候列印一下當前的執行緒： ```java thread name=nioEventLoopGroup-3-1 server receive msg="..." ``` 可以發現這裡使用的執行緒其實和處理io執行緒是同一個； ### Dubbo執行緒隔離模型 Dubbo的底層通訊框架其實使用的就是Netty，但是Dubbo並沒有直接使用Netty的io執行緒來處理業務，可以簡單在生產者端輸出當前執行緒名稱： ```java 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操作具有更好的併發效能。關於NIO,可以參考我這篇部落格:[NIO非阻塞網路程式設計原理](https://www.cnblogs.com/Courage129/p/14223988.html) 在Tomcat7版本之後,Tomcat把連線介入和業務處理拆分成兩個執行緒池來處理，即:  可以使用獨立的執行緒池來維護servlet的建立。聯結器connector能介入的請求肯定比業務複雜的servlet處理的個數要多，在中間，Tomcat加入了佇列，來等待servlet執行緒池空閒。這兩步是Tomcat核心完成的，在一階段無法區分具體業務或資源，所以只能在連線介入，servlet初始化完成後我們根據自己的業務線去劃分獨立的連線池。 這樣做,獨立的業務或資源中如果出現崩潰，不會影響其他的業務執行緒，從而達到資源隔離和服務降級的效果。 在使用了servlet3之後，系統執行緒隔離變得更靈活了。可以劃分核心業務佇列和非核心業務佇列:  ### 執行緒隔離小總結 1. 資源一旦出現問題，雖然是隔離狀態，想要讓資源重新可用，很難做到不重啟jvm。 2. 執行緒池內部執行緒如果出現OOM、FullGC、cpu耗盡等問題也是無法控制的 3. 執行緒隔離，只能保證在分配執行緒這個資源上進行隔離，並不能保證整體穩定性 ## 程序隔離 程序隔離這種思想其實並不陌生,Linux作業系統中,利用檔案管理系統將各個程序的虛擬記憶體與實際的實體記憶體對映起來,這樣做的好處是避免不同的程序之間相互影響,而在分散式系統中,執行緒隔離不能完全隔離故障避免雪崩,例如某個執行緒組耗盡記憶體導致OOM,那麼其他執行緒組勢必也會受影響,所以程序隔離的思想是,CPU、記憶體等等這些資源也通過不同的虛擬機器來做隔離。 具體操作是,將業務邏輯進行拆分成多個子系統(拆分原則可以參考:[Redis叢集拆分原則之AKF](https://www.cnblogs.com/Courage129/p/14344151.html))，實現物理隔離，當某一個子系統出現問題，不會影響到其他子系統。  ## 叢集隔離 如果系統中某個業務模組包含像搶購、秒殺、儲存I/O密集度高、網路I/o高、計算I/O高這類需求的時候，很容易在併發量高的時候因為這種功能把整個模組佔有的資源全部耗盡，導致響應編碼甚至節點不可用。像上圖的的拆分之後,如果某一天購物人數瞬間暴增,電商交易功能模組可能受影響,損壞後導致電商模組其他的瀏覽查詢也無法使用,因此就要建立叢集進行隔離,具體來說就是繼續拆分模組,將功能微服務化。 ### 解決方案 - 獨立拆分模組 - 微服務化 可以使用hystrix在微服務中隔離分散式服務故障。他可以通過執行緒和訊號量進行隔離。 ### 執行緒池隔離與訊號量隔離對比 這兒同上面的執行緒隔離,不多贅述,簡單敘述一下hystrix的兩種隔離方式的區別: | **隔離方式** | **是否支援超時** | **是否支援熔斷** | **隔離原理** | **是否是非同步呼叫** | **資源消耗** | | -------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -------------------- | -------------------------------------- | -------------------------------------------- | | **執行緒池隔離** | 支援，可直接返回 | 支援，當執行緒池到達maxSize後，再請求會觸發fallback介面進行熔斷 | 每個服務單獨用執行緒池 | 可以是非同步，也可以是同步。看呼叫的方法 | 大，大量執行緒的上下文切換，容易造成機器負載高 | | **訊號量隔離** | 不支援，如果阻塞，只能通過呼叫協議（如：socket超時才能返回） | 支援，當訊號量達到maxConcurrentRequests後。再請求會觸發fallback | 通過訊號量的計數器 | 同步呼叫，不支援非同步 | 小，只是個計數器 | ### 訊號量隔離 說人話就是,很多執行緒湧過來,要去獲得訊號量,獲得了才能繼續執行,否則先進入佇列等待或者直接fallback回撥 最重要的是，訊號量的呼叫是同步的，也就是說，每次呼叫都得阻塞呼叫方的執行緒，直到結果返回。這樣就導致了無法對訪問做超時（只能依靠呼叫協議超時，無法主動釋放） 官網對訊號量隔離的描述建議 - Generally the only time you should use semaphore isolation for `HystrixCommand`s 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內容分發](https://www.cnblogs.com/Courage129/p/14363627.html) ## 爬蟲隔離 **建立合適的規則,將爬蟲請求轉移到另外的叢集**。 目前我們開發的都是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來完成更復雜的邏輯，實現一個流量閘道器，軟防