1. Sentinel 到底是什么以及為什么突然要“找替代”先說結(jié)論Sentinel 是阿里開源的一套“流量防護”組件和 Hystrix 是一個賽道的東西。它做的核心事情是三件流量控制說白了就是限流、熔斷降級下游掛了別把調(diào)用方拖死和系統(tǒng)負載保護防止整機夯死。這套東西在 Spring Cloud Alibaba 體系里基本是標配也是國內(nèi)很多 Java 團隊微服務治理的第一選擇。但成熟的東西不等于沒有槽點。我接觸 Sentinel 時間不短了從最早的 1.6 到 1.7、1.8 一路用過來最直觀的感受是單機限流很好用控制臺很簡陋集群限流配置起來很痛苦規(guī)則持久化完全是后加的能力。而且社區(qū)迭代從 1.8.6 開始明顯放緩有很多 issue 掛著沒人理新功能基本停滯。于是“有沒有更合適的替代方案”就變成一個繞不開的話題。而在微服務和云原生這里所謂“替代”其實也不只是替代 Sentinel 一個組件而是要回答一個更底層的問題流量防護和網(wǎng)關治理這件事到底放在哪個層次做是放在應用進程里代碼庫方式還是交給基礎設施層網(wǎng)關/服務網(wǎng)格Resilience4j、Envoy、Kong 恰好代表了三條不同的路線Resilience4jJava 生態(tài)里的“純進程內(nèi)”容錯庫走的是 Hystrix 的遺志路線輕量、不依賴任何中間件。Envoy數(shù)據(jù)面代理跑在服務網(wǎng)格里Istio/Consul Connect 的底座主打高性能轉(zhuǎn)發(fā)和治理能力下沉。KongAPI 網(wǎng)關專門管理南北向流量核心賣點是插件架構和一鍵接入已有系統(tǒng)。這三個東西和 Sentinel 并不是完全同層的東西但在選型的時候很多人卻會把它們擺在一起糾結(jié)原因只有一個大家都想“用一件東西解決流量治理”。所以這篇我按從業(yè)者的視角把四個方案的真實優(yōu)缺點、適用邊界、以及與 Sentinel 的關系都講清楚最后給一條比較好落地的選型路線。2. 四個選手的“底子”逐個拆解2.1 Sentinel不能只看開源版要看它的設計精髓Sentinel 的核心競爭優(yōu)勢有兩個。一個是對 Java 生態(tài)的原生貼合你只要引入sentinel-core寫個SphU.entry(資源名)立刻就能拿到流量統(tǒng)計、限流判斷、熔斷判斷這些能力。另一個是它的鏈路和統(tǒng)計模型它把每個請求抽象成資源然后把資源的調(diào)用鏈路記錄下來基于滑動窗口做精確的實時統(tǒng)計?；瑒哟翱谶@種設計比 Hystrix 的“固定時間桶”要精細得多尤其是在秒級毛刺流量下Sentinel 的統(tǒng)計不會出現(xiàn)窗口邊界突變的問題。Sentinel 的限流規(guī)則支持 QPS 直接限流、并發(fā)線程數(shù)限流、熱點參數(shù)限流還有一個冷啟動Warm Up和勻速排隊Rate Limiter模式。冷啟動這個很實用比如新服務剛上線如果瞬間放開全部 QPS數(shù)據(jù)庫連接池和線程池很容易被打爆。生產(chǎn)上我一般給新接口配冷啟動 限流閾值的組合效果比一次性硬限流到底要好。但它的痛點也很實在開源版控制臺Dashboard被好多人吐槽“像內(nèi)部工具”沒有權限體系沒有審計節(jié)點列表在集群規(guī)模大了之后刷新也不流暢。集群限流要先單獨搭一個 Token Server配置鏈路長而且這個 Token Server 本身還要做高可用很多團隊直接放棄。規(guī)則推送到客戶端依賴sentinel-datasource-*擴展雖然有 Nacos、Apollo、Redis、ZK 等實現(xiàn)但都是社區(qū)維護沒有官方統(tǒng)一標準。我用過一個比較踩坑的場景Spring Cloud Alibaba 項目里接 Sentinel規(guī)則放在 Nacos 里結(jié)果在控制臺改規(guī)則后配置被本地文件覆蓋了服務一重啟規(guī)則就丟。當時排查了很久最后才發(fā)現(xiàn)是spring.cloud.sentinel.datasource和 Dashboard 推流同時存在時的優(yōu)先級沖突。這個問題現(xiàn)在依然有網(wǎng)上一搜一大片只能說生態(tài)里的這些“內(nèi)傷”真的只有用久了才知道。2.2 Resilience4j輕量到極致但別指望它做“限流”Resilience4j 繼承了 Hystrix 退出歷史舞臺后的位置可以說是 Spring Cloud Circuit Breaker 在 Java 生態(tài)的默認實現(xiàn)。它的核心思想不是“中間件”而是一個函數(shù)式庫你直接在業(yè)務代碼里用CircuitBreaker.decorateSupplier(...)包一層就拿到了熔斷能力。這種東西最大的優(yōu)點就是侵入可控不存在任何外部依賴。它的能力模塊有熔斷CircuitBreaker、隔離Bulkhead支持信號量和固定線程池兩種、限流RateLimiter、重試Retry、緩存Cache和基于時間的限時器TimeLimiter。注意這里的 RateLimiter 做的是“勻速通過 拒絕多余請求”的 Java 進程內(nèi)限流形態(tài)類似 Guava RateLimiter但沒有精確到資源維度的實時統(tǒng)計也不像 Sentinel 的滑動窗口那樣能對抗秒級抖動的流量。隔離是 Resilience4j 的亮點。信號量隔離非常輕量默認 10 個并發(fā)許可適合 IO 密集但本身沒線程池的業(yè)務。線程池隔離則更像 Hystrix 的原始做法把外部調(diào)用丟到獨立線程池里跑耗盡也不會污染主線程。不過我提醒一句線程池隔離有上下文傳遞的坑特別是MDC、ThreadLocal、SecurityContext這些東西要自己寫裝飾器去傳否則鏈路追蹤和用戶信息全丟。這個坑我踩了好幾次。它的短板說實話也源于“輕量”二字。沒有控制臺、沒有動態(tài)規(guī)則中心、沒有集群概念。規(guī)則只能寫在代碼里或從配置中心拉運行時很難像 Sentinel 那樣通過 Dashboard 去調(diào)閾值。所以它更適合“夠用就好”的項目而不是“需要運營流量治理平臺”的系統(tǒng)。2.3 Envoy把治理能力下沉到 SidecarEnvoy 是 Istio 默認的數(shù)據(jù)面代理用 C 寫的性能和并發(fā)能力極其優(yōu)秀。它的核心思想是把微服務的流量治理能力從業(yè)務進程里抽離出來放進一個和業(yè)務容器并肩部署的 Sidecar 進程里。業(yè)務代碼只需要關心業(yè)務邏輯限流、熔斷、重試、超時、可觀測性全部由 Sidecar 搞定。Envoy 的限流能力和 Sentinel 不是一回事。它內(nèi)置的是本地限流HTTP Local Rate Limit Filter / Network Local Rate Limit Filter可以按請求、按連接、按虛擬主機維度做簡單的 QPS 限制。但更細粒度的、需要全局統(tǒng)計的限流它自己不承擔而是通過rate_limit_service把請求外包給外部的 gRPC 服務去判定。這個設計很符合 Envoy 的定位它是高效的轉(zhuǎn)發(fā)器不是業(yè)務規(guī)則處理器。熔斷降級方面Envoy 有一套主動健康檢查被動健康檢查的組合拳。主動檢查是負載均衡器定期探測上游節(jié)點被動檢查則是當某個節(jié)點的連續(xù)錯誤數(shù)或連續(xù) 5xx 超過閾值時將節(jié)點標記為不健康進入被熔斷的狀態(tài)。這個機制非常適合 Kubernetes 環(huán)境下的服務治理因為它天然感知服務實例的存活狀態(tài)。但它的問題是復雜度明顯更高。你需要理解 Envoy 的監(jiān)聽器、路由、過濾器鏈、集群、端點整套概念配置又是基于 yaml 的聲明式 DSL任何一個字段語義理解不對線上流量就會出岔子。如果沒有 Istio 或 Consul 這種控制面來生成配置單靠人手寫 Envoy 配置去維護一整個服務網(wǎng)格那運維成本是災難級的。我自己試過手寫 Envoy 配置去轉(zhuǎn)發(fā) HTTP/2 到 HTTP/1.1 并加 mTLS折騰了兩天才跑通其中半天都是在排查證書和 SNI 的問題。2.4 KongAPI 網(wǎng)關賽道上的老江湖Kong 是 API 網(wǎng)關基于 OpenResty/Nginx 構建天生處理的就是“外部流量進入內(nèi)部系統(tǒng)”這一層。它有非常成熟的插件體系認證、限流、轉(zhuǎn)換、日志、可觀測性都可以通過插件即插即用地掛到服務或路由上。限流插件Rate Limiting支持本地限流和基于 Redis 的分布式限流對 API 網(wǎng)關場景來說已經(jīng)夠用。Kong 在控制層面做得比 Envoy 更“產(chǎn)品化”。Kong Manager企業(yè)版或者開源版的 Admin API 都可以用來管理 Service、Route、Upstream、Target。而kong manager 節(jié)點主動健康檢查配置這種需求對應的就是 Upstream 里的healthchecks配置塊可以配主動探測的路徑、間隔、超時以及被動熔斷的容忍度參數(shù)。Kong 的這套健康檢查 UI 比 Envoy 那種純配置文件友好得多。它的定位非常清晰管好 API 的入口。所以如果你需要的是南北向流量治理比如多個外部調(diào)用方訪問你的微服務集群Kong 是最容易上手的選擇。但如果你希望服務之間互相調(diào)用的時候也有熔斷和限流Kong 就使不上勁了因為它的模型就是“站在前面擋流量”不是一個旁路數(shù)據(jù)面。還有一個很現(xiàn)實的問題Kong 很多高級功能都在企業(yè)版里開源社區(qū)版里連kong manager界面都要自己想辦法社區(qū)版主要通過開源的kong-manager或第三方 UI 去實現(xiàn)。想要健康檢查可視化、多租戶管理、RBAC 權限這類能力得上企業(yè)版或自己拿 Admin API 二次封裝。選擇 Kong 之前要搞清楚你們要的是網(wǎng)關還是服務治理平臺。要是混為一談后面很容易騎虎難下。3. 同場競技關鍵維度橫向?qū)Ρ葘Ρ染S度SentinelResilience4jEnvoyKong定位微服務流量治理組件Java 進程內(nèi)容錯庫云原生數(shù)據(jù)面代理API 網(wǎng)關部署形態(tài)應用內(nèi) SDK應用內(nèi)函數(shù)庫Sidecar/獨立代理獨立網(wǎng)關實例適用語言Java有其他語言版本但不常用Java任何語言任何語言常用于微服務集群入口流量統(tǒng)計模型滑動窗口精確到秒無統(tǒng)一統(tǒng)計模型連接/請求級別的本地統(tǒng)計Redis 統(tǒng)計/本地窗口統(tǒng)計限流能力QPS、并發(fā)線程、熱點參數(shù)、勻速排隊、冷啟動RateLimiter進程內(nèi)本地限流 外接限流服務限流插件支持 Redis 分布式限流熔斷能力支持基于響應時間/異常比例支持功能很強通過異常值檢測剔除實例支持被動健康檢查剔除節(jié)點動態(tài)規(guī)則支持需要 datasource 擴展有限支持需自集成配置中心支持通過 xDS 下發(fā)支持通過 Admin API / DB-less 配置控制臺/可視化開源版有 Dashboard較簡陋無需搭配控制面Istio/ConsulKong Manager企業(yè)版 / 三方 UI資源開銷中JVM 內(nèi)極低較高每實例一個 Sidecar中高獨立網(wǎng)關集群運維復雜度低-中低高中學習成本中有一定概念門檻低較高概念多配置復雜中插件機制好上手與 Kubernetes 集成一般一般極強強有 Ingress Controller社區(qū)活躍度更新放緩問題堆積活躍極活躍活躍商業(yè)支持有阿里云商業(yè)化版本無有平臺支持云廠商有 Kong Enterprise這個表格基本把四個方案的底盤都擺出來了。可以明顯看到Sentinel 和 Resilience4j 站在“進程內(nèi)”這一側(cè)Envoy 和 Kong 站在“基礎設施”這一側(cè)。它們不是直接替代關系而是治理層次不同。選型真正的難題在于你到底需要在哪個層次做流量防護以及現(xiàn)有團隊能接受多高的運維成本。拿現(xiàn)實業(yè)務舉例一個 Java 單體或者少量微服務、沒有上 K8s 的團隊引入 Envoy 屬于殺雞用牛刀邊緣前提條件太多一個異構語言、多服務大規(guī)模部署在 Kubernetes 上的團隊用 Sentinel 又會發(fā)現(xiàn)監(jiān)控指標和基礎設施完全割裂數(shù)據(jù)沒法統(tǒng)一。選型先選層次層次定了再選具體產(chǎn)品這樣才不會糾結(jié)“A 和 B 哪個好”這種無解問題。4. 決策路徑到底怎么選4.1 常見選型誤區(qū)第一個誤區(qū)是“拿網(wǎng)關對比進程庫”。有人糾結(jié)“Kong 比 Sentinel 功能多很多是不是可以替代”錯了。Kong 管的是南北向流量Sentinel 管的是服務調(diào)用鏈路里的東西向流量。你把 Sentinel 去掉、只留 Kong服務 A 調(diào)服務 B 的時候照樣沒有熔斷降級因為流量根本沒經(jīng)過網(wǎng)關。反過來你在應用里都接入了 Sentinel但對外 API 入口沒有統(tǒng)一限流攻擊流量依然能打穿后端。第二個誤區(qū)是“想用一個方案解決所有問題”。實際落地的系統(tǒng)往往是Kong/Envoy 負責入口統(tǒng)一治理Sentinel/Resilience4j 負責應用內(nèi)部容錯兩者共存。我去過的不少中大型團隊最后都是雙軌制網(wǎng)關層用 Envoy 或 Kong業(yè)務層用 Sentinel 或 Resilience4j。第三個誤區(qū)是“覺得開源就是免費”。所有做選型的人都應該算一筆賬開源組件的原廠免費能力有多少你自己拿人力和時間去補充的能力有多少。Sentinel 開源版的控制臺、規(guī)則持久化、權限審計你要自己搭Envoy 要 K8s 控制面才能發(fā)揮全部價值得找 Istio 團隊或云廠商托管Kong 的高級特性要買企業(yè)版開源版有時候給你留的坑比省下的授權費更大。4.2 不同場景的選型建議第一類場景Java 微服務已有 Spring Cloud Alibaba 生態(tài)團隊規(guī)模不大不需要大規(guī)?？梢暬卫砥脚_。這時候真的沒必要大動干戈換掉 Sentinel。Sentinel 的弱項雖然是控制臺和集群管理但只要規(guī)則持久化做好接 Nacos 或 Redis單機限流和熔斷的效果已經(jīng)足夠優(yōu)秀而且全鏈路監(jiān)控還能和 Alibaba Sentinel Dashboard 或遷移到 Prometheus 配合。如果要換也建議只把 Resilience4j 作為替代 Hystrix 場景的輕量方案去評估而不是推翻整套 SCA。第二類場景追求極簡、不想引入任何中間件業(yè)務代碼本身就是核心資產(chǎn)。我建議選 Resilience4j。它連 Nacos 都不用規(guī)則寫死在配置里足夠簡單直接。尤其是那種“項目就五六個服務、團隊沒有運維、領導不想懂流量治理”的情況Resilience4j 的收益最高因為根本不產(chǎn)生額外組件要維護。代價是你不具備動態(tài)調(diào)規(guī)則的能力改閾值必須發(fā)版但在小團隊里這是能接受的。第三類場景上了 Kubernetes服務數(shù)量多、異構語言多希望流量治理治理能力下沉基建。這種直接看 Envoy配合 Istio/Contour 這類控制面。治理邏輯和業(yè)務代碼解耦服務 A 調(diào)服務 B 的流量可以在 Sidecar 這一層透明攔截、透明熔斷對業(yè)務代碼零侵入。尤其是已經(jīng)擁抱多語言Java、Go、Node.js 混編的團隊用 Envoy 能實現(xiàn)治理能力統(tǒng)一不用為每種語言各配一套 SDK這個價值遠大于學習 Envoy 配置花費的時間。不過我要專門提醒一點Envoy 的熔斷和超時策略不要一上來就全局開。最穩(wěn)妥的方式是先在測試環(huán)境隨便亂調(diào)把各種異常場景上游慢、下游掛、流量暴增都模擬一遍再確定合理的請求超時、重試次數(shù)、熔斷閾值。真線上出了問題流量表現(xiàn)會和你在測試環(huán)境看到的完全不一樣。第四類場景對外 API 比較多需要認證、限流、日志、API 生命周期管理等問題一并解決。那就上 Kong。它天然是“處理外部請求”的入口插件機制讓認證和限流能快速加上且通過 Upstream 的健康檢查能有效管理后端服務實例的上下線。這里補充一個實用配置Kong Upstream 的主動健康檢查一般配成這樣curl -X PATCH http://localhost:8001/upstreams/my_upstream \ -H Content-Type: application/json \ -d { healthchecks: { active: { type: http, http_path: /healthz, healthy: { interval: 10, successes: 3 }, unhealthy: { interval: 10, http_failures: 3, tcp_failures: 3, timeouts: 2 } }, passive: { type: http, healthy: { http_statuses: [200, 201, 301, 302], successes: 3 }, unhealthy: { http_statuses: [429, 503], timeouts: 2, http_failures: 2 } } } }注意successes和http_failures的取值直接決定節(jié)點被摘除的速度。值配太小容易一抖就摘、忽上忽下配太大會讓已掛節(jié)點繼續(xù)接收流量好幾秒。這個是線上調(diào)優(yōu)最容易忽視的細節(jié)。4.3 綜合選型決策表團隊狀態(tài)推薦組合Java 單體/小微服務、想省事Spring Cloud Sentinel 或 Resilience4jJava 微服務、已上 K8s、有平臺團隊Sentinel規(guī)則持久化 Envoy/Istio入口統(tǒng)一治理異構語言微服務、K8s 原生Envoy/Istio Kong或直接用 Envoy Ingress外部 API 多、需要高可控入口Kong網(wǎng)關層治理獨立成團隊資源緊張、不想碰運維Resilience4j最簡單或全托管云原生網(wǎng)關5. 實戰(zhàn)經(jīng)驗與避坑記錄5.1 Sentinel 規(guī)則持久化Redis 數(shù)據(jù)源的一個正確打開方式前面提到了spring cloud sentinel datasource redis集群這個熱搜詞對應的痛點。Sentinel 接 Redis 數(shù)據(jù)源時最容易踩的坑是序列化方式不一致。規(guī)則數(shù)據(jù)存進 Redis 之前要先轉(zhuǎn)成 Sentinel 端能識別的 JSON 格式比如下面這種[ { resource: order_service:create, count: 100, grade: 1, limitApp: default, strategy: 0, controlBehavior: 0 } ]grade1表示按 QPS 限流controlBehavior0表示直接拒絕1是 Warm Up2是勻速排隊。很多新手在 Redis 里塞了一堆普通 JSON 卻發(fā)現(xiàn)規(guī)則不生效多半是字段名對不上比如把count寫成了qps或者 Parse 的時候報JsonSyntaxException日志還被吞掉。建議在集成時先寫一個單元測試往 Redis 塞一條規(guī)則然后啟動應用看日志里是否出現(xiàn)[SentinelRule]的推送記錄這個是最快的問題定位方式。集群環(huán)境下還要注意Sentinel 每個應用實例都會獨立從 Redis 拉規(guī)則如果規(guī)則被 Dashboard 動態(tài)推送覆蓋過就可能出現(xiàn)“Nacos 里是對的、Redis 里是舊的、Dashboard 看到的是最新的”這種三份配置不一致的情況。我的處理經(jīng)驗是控制臺不要直接改規(guī)則所有規(guī)則變更都走配置中心的版本管理流程Dashboard 只用來查看實時監(jiān)控。這樣能避免 90% 的規(guī)則漂移問題。5.2 Envoy 限流千萬別指望默認配置一步到位Envoy 的本地限流 Filter 配置是指定route級別或者virtual host級生效的不是自動對所有請求生效。我第一次用的時候配了全局 Cluster 的限流結(jié)果發(fā)現(xiàn)根本不起作用折騰了半天才搞清楚本地限流要掛在http_filters里并指定domain和descriptor。一個典型配置長這樣http_filters: - name: envoy.filters.http.local_ratelimit typed_config: type: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit stat_prefix: http_local_rate_limiter filter_enabled: default_value: numerator: 100 denominator: HUNDRED filter_enforced: default_value: numerator: 100 denominator: HUNDRED descriptors: - entries: - key: request_headers value: some_header token_bucket: max_tokens: 100 tokens_per_fill: 10 fill_interval: 1s這個其實只是“本地速率限制”單位是每秒 10 個令牌最大容量 100。如果你期望的是“全局限流”比如所有實例共享一個桶那 Envoy 本身不干這事還是得接外部的限流服務比如 Envoy Rate Limit Service gRPC。要評估運維成本這是很多人最終放棄 Envoy 的原因之一——因為一套完整的限流方案你得自己部署一個全局限流服務還要考慮它的高可用。5.3 Kong 健康檢查主動檢查與被動檢查的配合Kong 的健康檢查比 Envoy 更直觀但依然有配置陷阱。很多團隊只配了主動檢查active忘掉被動檢查passive結(jié)果后端服務已經(jīng)開始大面積超時但主動檢查的/healthz探針依然返回 200流量全部被送達問題節(jié)點。正確做法是主動被動同時開主動檢查固定間隔去請求/healthz用于發(fā)現(xiàn)“長時間不健康”的節(jié)點頻率不要太高5~10 秒一次否則會產(chǎn)生大量無意義探活請求。被動檢查基于真實請求的返回碼和超時情況用于快速發(fā)現(xiàn)突發(fā)故障節(jié)點比如連續(xù) 2~3 次返回 503 就立刻把節(jié)點標記為不健康。生產(chǎn)上這套配合能基本做到 1~3 秒內(nèi)摘除故障節(jié)點。但還有個細節(jié)Kong 從獲取環(huán)形均衡列表到真正摘除節(jié)點有一個收斂時間如果有多個 Kong 節(jié)點每個節(jié)點的狀態(tài)更新不是瞬時一致的需要依賴 Redis如果開啟或 Kong 的數(shù)據(jù)庫集群模式來同步。冷啟動階段偶爾會看到短暫把流量打到已摘除節(jié)點的情況這個可以用 Upstream 的healthchecks.active.timeout和重試策略去緩解。5.4 Resilience4j 滑動窗口的類型選擇Resilience4j 的熔斷器有兩種窗口COUNT_BASED滑動計數(shù)窗口和TIME_BASED滑動時間窗口。選擇不對熔斷效果天差地別。例如低頻請求接口每分鐘 10 次如果用默認的COUNT_BASED 滑動窗口大小 100那么一次失敗根本不足以觸發(fā)任何比例判斷因為窗口還沒被填滿但用TIME_BASED 窗口 60 秒則能實時根據(jù)最近一分鐘內(nèi)的請求成敗計算熔斷概率。另一個反例高并發(fā)接口配TIME_BASED且窗口過小會讓熔斷判斷的統(tǒng)計噪聲明顯變大結(jié)果閾值很容易被瞬間抖動戳破。我的經(jīng)驗是對外部依賴自身 QPS 較高的接口用COUNT_BASED窗口 100 或 200對低頻但重要的調(diào)用用TIME_BASED窗口 30 或 60 秒無論哪種窗口failureRateThreshold別配 50% 以下否則稍微一個毛刺就把接口熔斷了恢復期間用戶會直接感受到服務不可用。6. 最后的個人體會做了一個完整對比我再分享一個實際體感。我們團隊有一個老系統(tǒng)Java 微服務有七八個服務沒有上 Kubernetes線上跑著 Spring Cloud Sentinel。后來因為要統(tǒng)一對外 API 入口引入了 KongSentinel 繼續(xù)留在服務內(nèi)部做接口級限流和熔斷。這套雙軌制維持到現(xiàn)在生產(chǎn)表現(xiàn)很穩(wěn)定沒出過大問題。在這個過程中我最大的體會是選型不是找最“厲害”的技術而是找和你團隊運維能力、系統(tǒng)架構階段匹配的一套組合。Sentinel 的確有各種讓人想吐槽的小毛病但它在“Java 微服務 需要動態(tài)規(guī)則 需要精細流控算法”這個場景里依然是國內(nèi)最順手的方案。Resilience4j 適合“我不想要運維負擔”的人Envoy 適合已經(jīng)上云原生、愿花時間打磨基礎設施的團隊Kong 則是在“對外 API 入口治理”這個不可回避的問題上最好的補位選手。最后再提醒一個容易忽略的點無論你最終選了哪套方案規(guī)則配置和閾值調(diào)整一定要進入版本管理。我見過不止一次因為有人在線上臨時改規(guī)則、調(diào)閾值事后沒記錄結(jié)果出故障時根本不知道規(guī)則改了什么。流量防護工具做得再好如果變更管理一塌糊涂最終還是會栽在人的問題上。