Edith網關——面向小紅書億級DAU的網關大規模實踐-陳華昌.pdf

《Edith網關——面向小紅書億級DAU的網關大規模實踐-陳華昌.pdf》由會員分享，可在線閱讀，更多相關《Edith網關——面向小紅書億級DAU的網關大規模實踐-陳華昌.pdf（42頁珍藏版）》請在三個皮匠報告上搜索。

1、EdithEdith網關-面向小紅書億級DAU的大規模實踐小紅書/陳華昌（空古）02.架構與設計01.背景03.核心功能實踐04.穩定性實踐05.未來展望目錄歷史總是驚人的相似1.背景混亂的過去Edith網關Edith 網關于 2021 年 9 月底 MVP 版本上線，同年 11 月上線正式版。Edith 命名來源：鋼鐵俠送給蜘蛛俠的人工智能系統名為Edith，中文譯作伊迪斯。這是繼星期五、賈維斯后的第三代人工智能。目前成果：經過一年多的舊業務治理，覆蓋全司業務路由的 99.6%，社區業務的 96%+，電商業務的 100%。新業務 100%接入 Edith 網關。選擇適合自己的2.架構與設計架

2、構與設計南北向架構Edith網關架構設計產品化設計南北向架構舊：鏈路層深、私拉亂接、規范職責不清。北向接入點以 kong 為主，定制化能力不高。南向 kong 依賴 Ingress，不能跨區服務發現。路由和 API 散落，且發布風險大。新：利用 nginx+lua 代替北向 kong，Edith 網關代替南向 kong。形成統一出口，標準管理路由和API資源?？煽鐓^服務發現，發布鏈路安全可控。舊新Edith架構-全局視角實行多租戶多集群策略，根據業務屬性進行精細化拆分。（隔離性）各區建立 pop 點，核心業務實行跨云多活部署。（高可用）Edith架構-單機視角預加載：從 Etcd 中拉取對應網

3、關集群所需要的所有元數據。并導入到字典樹中，生成對應的前綴匹配樹。插件：通過標準規范形成通用組件，并支持業務個性化定制開發。統一至插件市場，反哺所有業務。泛化調用：主要包含協議轉化、Context 處理、熔斷、降級、異常處理等能力。數據庫：Etcd 充當著配置中心的角色，MySQL 主要負責控制面數據管理。管理端：主要負責三個方面管理，數據、發布、穩定性處置。產品設計邏輯重視穩定性穩定性限流、熔斷、降級、隔離、變更管控重視易用性易用性可視化UI交互，一切皆可點點點操作。推行一鍵式操作，例如生成 API、發布、回滾等。兼顧通用和可擴展性通用和可擴展性插件市場，通用和個性化并存。OpenAPI，可

4、集成至自己的業務平臺。來源于業務，賦能于業務。3.核心功能實踐核心功能實踐元數據管理插件泛化調用實驗分流路由生命周期元數據管理-熱更新全量更新灰度更新為什么選擇 Etcd？減少過多外部依賴，選取輕量化可控的 kv 類型，貼合 K8S 生態。Etcd本身的 watch、租約特性非常符合網關的數據面需求，且基于 Raft 算法的分布式一致性，具有很好的高可用性。元數據管理-版本管理為了保障數據安全，針對 API 元數據進行了多個階段的設計，包含草稿、快照、生產版本、可回滾版本。優勢：數據安全隔離，職責單一穩定。解決數據狀態管理的復雜性，使得操作方便。元數據管理-呈現元數據管理-灰度能力百分比灰度，

5、1-100%。按照 pod 維度進行推送灰度數據，控制爆炸半徑。高風險業務強制必須灰度和間隔時間。舉例：API API 灰度發布能力灰度發布能力-通過上報和下發指定業務集群 pod 數據，實現數據面元數據的灰度能力。插件-標準化、市場化通用類型的插件由網關團隊統一提供。例如：驗簽、權限校驗、反爬風控等。支持 API 維度的個性化配置，可視化一鍵開啟和配置。開發者可定制化開發，反哺公司業務。插件給網關提供了一種靈活的機制，使得開發者能在網關上添加額外的行為。插件-WASM，更優雅的解決方案WASM-全稱WebAssembly，新型的低級字節碼，性能好、可移植性高。WASM 主要解決了跨語言和跨平

6、臺運行的問題，實現了 build once，run everywhere。Go 1.21 版本將增加對 WASI WASI 的支持。泛化調用-構建動態Thrift報文在不使用 Thrift 編譯器生成的代碼情況下，進行 rpc 調用，實現 rpc 接口的熱插拔功能。通過導入的動態 IDL 定義獲取 thrift rpc 接口的請求和響應的數據結構定義（元數據一部分），然后根據數據結構模擬發送和讀取 thrift 的二進制報文。實驗分流機房分流機房分流：業務將服務變更代碼部署至三地機房中的一處，然后在網關配置指定實驗分組分流至指定機房，進行實驗驗證。服務分流服務分流：業務將新的變更代碼部署成一個

7、新服務，然后在網關上配置指定實驗分組分流至新服務，進行實驗驗證。路由生命周期需求：每年每個月都有不一樣的運營活動，不同時間階段需要執行不同的運營策略。方案：通過時間維度拆分路由不同時間的策略，分為前、中、后期。形成通用功能后，大幅度減少產研上線時間。有可能會發生的，一定會發生。4.穩定性實踐穩定性實踐服務動態降級-小紅書特色多重限流熔斷保護和超時控制監控和報警容災演練服務動態降級-背景故障期用戶體驗-小紅書崩了熱搜千人千面-延續個性化推薦穩定性 MTTR 指標-15分鐘服務動態降級-設計異常情況下，探測到下游服務滿足降級配置時，進行降級調用。降級服務的特征：出入參盡量和主服務一致邏輯足夠簡單，

8、直連數據源（Redis/RedKV）。常備狀態下，具備接收線上所有流量的能力。盡量千人千面服務動態降級-降級觸發固定以錯誤比例錯誤比例為策略，等同熔斷判斷邏輯。除基本錯誤類型外，支持返回體、code 的自定義錯誤類型。固定頻率從線上鏡像流量去對降級服務進行健康檢查。服務動態降級-降級調用在窗口時間內，請求數大于靜默數量，請求錯誤比例超過閾值后，后續請求將執行降級調用。探活規則：若接下來的一個請求成功完成（沒有錯誤）則結束降級，否則將再次進行降級。服務動態降級-落地情況核心場景超過 70%+擁有服務端降級能力，50%左右擁有端側降級能力。2023 年內，因為降級能力兜住的RCA故障至少 10+次

9、。一些拓展玩法部分業務研發，通過 code 碼自定義設定，將下游服務的限流，轉化為網關側的數據降級。限流-設計與實現設計原則設計原則：優先保護自己，其次保護下游業務?？煽糠€定，盡量不依賴多余組件。EdithEdith的實現的實現：通過 Etcd 的租約和 watch 能力，實現了三種限流模式。支持機房維度設定（流量不均衡）限流值。支持各種維度的自定義限流返回體。限流-執行邏輯先經過集群限流判斷，再判斷 API 限流或路由規則限流。后兩者是并列關系，目前只會存在一個。先觸達哪種限流值的限制，就返回該限流方式配置的返回數據。限流-落地案例案例一：小紅書 PC 端上線之初遭遇惡意流量攻擊，增加集群限

10、流后，下游服務不再被打掛。幾輪過后，攻擊者徹底放棄。待解決問題：目前限流時已經讀取了 Body，在大 Body 流量洪峰時，容易引發 cpu/內存上漲，引發節點不穩定。熔斷保護和超時控制熔斷功能在網關體系中的作用非常重要，保護系統免受下游服務的故障或異常的影響，提高系統的可靠性和穩定性。超時控制，合理的設置超時時間，可以有效地防止網關實例連接數被打滿，增加業務鏈路的穩定性。監控和告警監控維度指標項pod維度cpu使用率、內存使用率、網絡帶寬、goroutine數、文件句柄、磁盤IO業務維度QPS、成功率、Error by（code/API/Service）、RT by（API/Service/

11、Plugin/Cluster）穩定性維度熔斷指標、限流指標、降級指標、pod重啟EtcdDB Size、Key Count、FDS、gRPC QPS告警措施告警措施：除業務維度指標告警推送給相關業務負責人外，其余推送給網關相關值班人員。按照業務集群等級 or 接口等級 設定告警級別，允許自定義接收人和接收群。對接內部 HA 系統，超過 HA 閾值，則自動創建故障處理群。容災演練演練范圍：演練范圍：多活場景的跨機房切流演練多活場景的跨機房切流演練，流量 上海:杭州:南京=4:3:3，驗收標準 每個機房都需要能承接總流量的50%。核心場景的降級能力核心場景的降級能力，通過故障注入的手段，驗收標準

12、核心場景能夠正常啟用降級能力，正常展示降級數據。熔斷能力驗收熔斷能力驗收，Edith某集群 or 下游服務不可用，上層是否具有預期的熔斷能力。千里之行，始于足下。5.未來展望未來展望Serverless探索開源Serverless探索-彈性擴縮容彈性策略：基礎策略-依賴 cpu/內存指標定時策略-固定時間潮汐自定義策略-依賴指標采集網關目前策略偏計算型，依賴 cpu 指標。只在少部分核心場景集群使用Serverless探索-規劃大致的一些方向：部署無感化部署無感化，業務只需要打包好程序，定位好業務屬性和等級，剩余底層機器和部署zone會自動化進行處理。事件驅動事件驅動：將網關的處理邏輯改為事件驅動模式，例如使用AWS Lambda或Azure Functions等無服務器計算服務，將請求轉換為事件，然后通過事件觸發器將事件發送到相應的函數中進行處理。自動伸縮自動伸縮：進一步強化網關彈性能力，能夠根據小紅書業務特性進行智能地彈性決策。開源From 小紅書今年 10 月 24 號程序員節，小紅書開始正式官宣，籌備和鼓勵開源。From Edith2024 年正式準備開源工作，回饋技術社區，與更多技術人員交流。團隊成員陳華昌（空古）齊敦偉（巨斧）朱浩然（快斗）徐鐵豹（凱皇）羅 超（福貴）