限流 & 熔斷的考量
- 前言 -
限流的原則，是盡量在流量源頭限，并且是需要依據(jù)現(xiàn)有團(tuán)隊(duì)所掌握的技能來。
如上最左側(cè)便是主要流量的來源入口，首先就要限制的地方就是slb節(jié)點(diǎn)的income流量。
slb節(jié)點(diǎn)的流量特點(diǎn)是啥？加限流怎么加？限流限的是啥？
錯(cuò)了，此處是攔截，不是限流...
流量特點(diǎn)：
幾乎來自外部的流量都從這個(gè)入口過來，無論是帶業(yè)務(wù)屬性的還是不帶業(yè)務(wù)屬性的、ddos的、正常流量、爬蟲等統(tǒng)統(tǒng)從這里來。
需要攔截是啥（由于流量過了這個(gè)節(jié)點(diǎn)就是我們的應(yīng)用系統(tǒng)了，因此最好是把非業(yè)務(wù)應(yīng)用相關(guān)的流量擋住，限制住，讓它有序進(jìn)來，不要沖垮系統(tǒng)）：
ddos攻擊流量 其他通用級的不安全流量：sql注入、xss注入等
有些許限流的：
連接并發(fā)限制 每ip請求限流控制 爬蟲流量
上述是slb節(jié)點(diǎn)，但是也有團(tuán)隊(duì)考慮到本身技能，以及代碼git化存儲的原則，會把某些配置往后面的nginx/kong移，因?yàn)閟lb的配置是UI界面化的，代碼化存儲比較不直接；但是nginx/kong這種就相對容易多了，而且恢復(fù)時(shí)只要腳本到位，分分鐘就恢復(fù)一套系統(tǒng)，很方便。
nginx節(jié)點(diǎn)的流量特點(diǎn)是啥？加限流怎么加？限流限的是啥？
到了這里，ddos這種攻擊流量應(yīng)該算是過濾掉了，常見的sql注入等攻擊也過濾掉了；但是還存在爬蟲流量（有時(shí)，這種流量是我們需要的，SEO推廣等）；也會包含高級攻擊流量
因此，nginx節(jié)點(diǎn)，需要做的限流是（通用級別的限流）：
爬蟲限流、并發(fā)控制、或者過濾、又或者重定向到蜜罐系統(tǒng)（專門給爬蟲做的系統(tǒng)，和主業(yè)務(wù)系統(tǒng)隔離）
每ip請求限流
spring cloud gateway節(jié)點(diǎn)的流量特點(diǎn)是啥？加限流怎么加？限流限的是啥？
到了這里，一般普通靜態(tài)H5資源的訪問已經(jīng)沒有了（已經(jīng)重定向到其他nginx節(jié)點(diǎn)分流處理掉了）；gateway處理的都是動態(tài)編程語言需要處理的流量，這里指java。
也就是說，到了這個(gè)節(jié)點(diǎn)，開始進(jìn)入java系統(tǒng)領(lǐng)域，流量承受能力比nginx降了1個(gè)等級，需要做更多的限制。
需要做的：
普通場景下的限流
突發(fā)流量下的限流，如：秒殺等
CC攻擊+驗(yàn)簽的過濾（由于公私鑰證書一般加在java節(jié)點(diǎn)上，因此此處放java系統(tǒng)范疇，而不是slb之前，或者nginx之前）
可以在gateway 動態(tài)路由中分別配置各自的限流配置，以及上述自定義的CC+驗(yàn)簽配置
隔離性：
由于gateway流量會轉(zhuǎn)發(fā)給后端一大堆微服務(wù)，假設(shè)由于哪個(gè)java微服務(wù)處理不過來hang住了，又不想影響其他后端為服務(wù)的轉(zhuǎn)發(fā)，因此需要做隔離性。
可以：
hystrix
sentinel
guava
此處的限流和nginx的限流有啥區(qū)別？
nginx的閾值要大，因?yàn)閚ginx覆蓋的范圍不光是java領(lǐng)域，還有H5等其他范圍
nginx的限流配置維度是通用的，但是spring cloud gateway就變化多了，可以通過自定義KeyResolver來決定所需要的維度來限流，如：用戶id維度、ip維度、租戶維度等，靈活度大了。
java微服務(wù)節(jié)點(diǎn)的流量特點(diǎn)是啥？加限流怎么加？限流限的是啥？
到了這里，就是具體的微服務(wù)應(yīng)用了，單個(gè)微服務(wù)所能承受的流量，做得好的話是能用jmeter測量出來的，可以通過這個(gè)值來參考設(shè)置。
再然后，到了具體服務(wù)中了，其實(shí)限流的維度就更多了，當(dāng)然需要考量下是否需要加很多限流，脆弱敏感的服務(wù)就加些，比如計(jì)費(fèi)等，或者用其他技術(shù)做限流，如：queue，然后固定住consumer數(shù)來消費(fèi)，穩(wěn)住速率。
所采用技術(shù)和gateway一樣，也可以自己實(shí)現(xiàn)，實(shí)現(xiàn)難度都還好。
流量大的系統(tǒng)，最好是用特定技術(shù)把income請求根據(jù)不同的維度劃分好獨(dú)立的線程池，不要相互影響；由本服務(wù)發(fā)起的到其他服務(wù)的請求調(diào)用，也需要單獨(dú)的線程池來處理。總之目標(biāo)就是都獨(dú)立，不互相影響，即便其他服務(wù)慢了，自己也不慢。
因此，熔斷又出現(xiàn)了：
當(dāng)其他服務(wù)很慢，超時(shí)了，我方作為服務(wù)調(diào)用方不能被拖垮啊，這時(shí)，就斷開吧，用個(gè)指定的協(xié)議響應(yīng)暫且認(rèn)定為服務(wù)不可用之類的，等后續(xù)再補(bǔ)償回查。
當(dāng)然關(guān)鍵服務(wù)是不能這么處理的，只能是輔助服務(wù)。關(guān)鍵服務(wù)就必須要jmeter壓測提升性能。
依賴：
核心服務(wù)的梳理
輔助服務(wù)熔斷的返回值+應(yīng)對方式
核心服務(wù)的壓側(cè)
來源：
https://www.cnblogs.com/aarond/p/ratelimiter.html
