為什麼要資源隔離
常見的資源,例如磁盤、網絡、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之後，系統線程隔離變得更靈活了。可以劃分核心業務隊列和非核心業務隊列:
線程隔離小總結
資源一旦出現問題，雖然是隔離狀态，想要讓資源重新可用，很難做到不重新開機jvm。
線程池内部線程如果出現OOM、FullGC、cpu耗盡等問題也是無法控制的
線程隔離，隻能保證在配置設定線程這個資源上進行隔離，并不能保證整體穩定性
程序隔離這種思想其實并不陌生,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.
了解下兩點：
隔離的細粒度太高，數百個執行個體需要隔離，此時用線程池做隔離開銷過大
通常這種都是非網絡調用的情況下
機房隔離主要目的有兩個,一方面是将不同區域的使用者資料隔離到不同的地區,例如湖北的資料放在湖北的伺服器,浙江的放在浙江伺服器,等等,這樣能解決資料容量大，計算密集，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是盜用者的，騙取流量。