限流的原則，是儘量在流量源頭限，並且是需要依據現有團隊所掌握的技能來。

如上最左側便是主要流量的來源入口，首先就要限制的地方就是slb節點的income流量

slb節點的流量特點是啥？加限流怎麼加？限流限的是啥？

錯了，此處是攔截，不是限流...

流量特點：

  • 幾乎來自外部的流量都從這個入口過來，無論是帶業務屬性的還是不帶業務屬性的、ddos的、正常流量、爬蟲等統統從這裡來

需要攔截是啥（由於流量過了這個節點就是我們的應用系統了，因此最好是把非業務應用相關的流量擋住，限制住，讓它有序進來，不要衝垮系統）：

  • ddos攻擊流量
  • 其他通用級的不安全流量：sql注入、xss注入等

有些許限流的：

  • 連線併發限制
  • 每ip請求限流控制
  • 爬蟲流量

上述是slb節點，但是也有團隊考慮到本身技能，以及程式碼git化儲存的原則，會把某些配置往後面的nginx/kong移，因為slb的配置是UI介面化的，程式碼化儲存比較不直接；

但是nginx/kong這種就相對容易多了，而且恢復時只要指令碼到位，分分鐘就恢復一套系統，很方便。

nginx節點的流量特點是啥？加限流怎麼加？限流限的是啥？

到了這裡，ddos這種攻擊流量應該算是過濾掉了，常見的sql注入等攻擊也過濾掉了；但是還存在爬蟲流量（有時，這種流量是我們需要的，SEO推廣等）；也會包含高階攻擊流量

因此，nginx節點，需要做的限流是（通用級別的限流）：

  • 爬蟲限流、併發控制、或者過濾、又或者重定向到蜜罐系統（專門給爬蟲做的系統，和主業務系統隔離）
  • 每ip請求限流

spring cloud gateway節點的流量特點是啥？加限流怎麼加？限流限的是啥？

到了這裡，一般普通靜態H5資源的訪問已經沒有了（已經重定向到其他nginx節點分流處理調了）；gateway處理的都是動態程式語言需要處理的流量，這裡指java

也就是說，到了這個節點，開始進入java系統領域，流量承受能力比nginx降了1個等級，需要做更多的限制。

需要做的：

  • 普通場景下的限流
  • 突發流量下的限流，如：秒殺等
  • CC攻擊+驗籤的過濾（由於公私鑰證書一般加在java節點上，因此此處放java系統範疇，而不是slb之前，或者nginx之前）
  • 可以在gateway 動態路由中分別配置各自的限流配置，以及上述自定義的CC+驗籤配置

隔離性：

  • 由於gateway流量會轉發給後端一大堆微服務，假設由於哪個java微服務處理不過來hang住了，又不想影響其他後端為服務的轉發，因此需要做隔離性
  • 可以：
    • hystrix
    • sentinel
    • guava

此處的限流和nginx的限流有啥區別？

  • nginx的閾值要大，因為nginx覆蓋的範圍不光是java領域，還有H5等其他範圍
  • nginx的限流配置維度是通用的，但是spring cloud gateway就變化多了，可以通過自定義KeyResolver來決定所需要的維度來限流，如：使用者id維度、ip維度、租戶維度等，靈活度大了

java微服務節點的流量特點是啥？加限流怎麼加？限流限的是啥？

到了這裡，就是具體的微服務應用了，單個微服務所能承受的流量，做得好的話是能用jmeter測量出來的，可以通過這個值來參考設定

再然後，到了具體服務中了，其實限流的維度就更多了，當然需要考量下是否需要加很多限流，脆弱敏感的服務就加些，比如計費等，或者用其他技術做限流，如：queue，然後固定住consumer數來消費，穩住速率。

所採用技術和gateway一樣，也可以自己實現，實現難度都還好。

流量大的系統，最好是用特定技術把income請求根據不同的維度劃分好獨立的執行緒池，不要相互影響；由本服務發起的到其他服務的請求呼叫，也需要單獨的執行緒池來處理。總之目標就是都獨立，不互相影響，即便其他服務慢了 ，

自己也不慢。

因此，熔斷又出現了：

  • 當其他服務很慢，超時了，我方作為服務呼叫方不能被拖垮啊，這時，就斷開吧，用個指定的協議響應暫且認定為服務不可用之類的，等後續再補償回查。
  • 當然關鍵服務是不能這麼處理的，只能是輔助服務。關鍵服務就必須要jmeter壓側提升效能。
  • 依賴：
    • 核心服務的梳理
    • 輔助服務熔斷的返回值+應對方式
    • 核心服務的壓側