鄧學祥-爆發式增長業務的高可用架構優化之路.pdf

《鄧學祥-爆發式增長業務的高可用架構優化之路.pdf》由會員分享，可在線閱讀，更多相關《鄧學祥-爆發式增長業務的高可用架構優化之路.pdf（27頁珍藏版）》請在三個皮匠報告上搜索。

1、爆發式增長業務的高可用架構優化之路鄧學祥目錄目錄Contents0 01 1爆發式增長業務的穩定性挑戰0 02 2爆發式增長業務的穩定性應對之道0 04 4降爆炸半徑自研Service Mesh實現去中心化網關0 03 3異地多活交易單元化技術架構爆發式增長業務的穩定性挑戰0 01 1主題主題SUBJECT中間件及基礎設施龐大Infrastructure 規模大中間件復雜業務架構復雜X因素多業務子系統多下游二方/三方依賴多變更引發的故障非變更引發的故障穩定性挑戰 業務系統神龍架構盤古存儲AliOs洛神網絡調度日志服務容災監控服務分布式數據庫HSFTairMetaq容器基礎設施云資源云操作系統中

2、間件單機故障，單塊硬盤故障機房故障，機房網絡故障面向失敗設計，單點故障可能是常態，機房級故障較少，對業務系統挑戰高主備切換抖動延時，中間件bug，中間件故障單容器故障K8S調度故障，K8S升級故障基礎設施挑戰requestApi GatewayMicro Service1.1Micro Service1.2Micro Service1.3Micro Service1.4Micro Service1.5Micro Service1.6Micro Service2.1Micro Service2.2Micro Service2.3Micro Service2.4Micro Service3.1Mi

3、cro Service3.2Micro Service3.3Micro Service3.4Micro Service3.5Micro Service3.6復雜系統鏈路較長復雜系統鏈路較長，定位問題可能變得困難二方/三方系統故障，RT變長，成功率下降等上游請求量暴增下游失敗的后的上游重試上游非法請求，安全攻擊等鏈路上的上下游變更故障系統的自我保護系統的自我保護，防止被上游異常大流量打死下游的超時保護下游的超時保護，防止被下游拖死區分強弱依賴區分強弱依賴，可降級依賴防止重試風暴防止重試風暴，多級重試是叉乘關系業務架構挑戰故障類別變更類故障非變更類故障時間類變化證書到期服務到期消耗類值變化賬戶余額

4、變化庫存類變化量變引起質變自增id超int最大值，變long類型數據量級變化非生產環境變更.省略因素太多，無法窮舉其實本質也是變化X因素挑戰爆發式增長業務的穩定性應對之道0 02 2主題主題SUBJECT預案平臺風險預案關聯預案執行降級預案單元化管控平臺單元化切流資損熔斷統一數據流聚類異常發現熔斷處置決策事后單元化中間件支付渠道自動切換支付渠道下線決策支付渠道監控外部依賴管控平臺外部依賴監控自動下線支付渠道上下線水位自動巡檢qps水位播報存儲水位播報應用水位播報全鏈路追蹤故障歸因全鏈路日志逆向監控數據采集數據處理逆向校驗事中變更歸因監控大盤分業務大盤整體大盤業務監控告警業務監控風險監控質量平臺

5、質量評分測試覆蓋率代碼掃描灰度平臺灰度引流灰度發布故障演練資損熔斷演練支付渠道故障預案降級故障事前灰度diff壓測平臺壓測引流語料壓測計劃混沌工程數據庫連接/超時故障Redis連接/超時故障自動報告用反監控輿情監控機房切流單元化監控報警通知風險視圖天級大盤單機服務故障RT延遲故障三方故障注入風險故障限流管控平臺限流監控限流調整用反監控穩定性之道事前防范未然，事中快速發現，事后快速恢復灰度平臺流量染色&識別，中間件根據環境標定位環境 上線前灰度環境做引流驗證 通過環境標實現流量精細化管控，支持白名單、百分比等灰度流量控制 靈活，不需要全鏈路都有灰度環境。人工收集壓測語料，壓測case 手工執行壓

6、測準備，手工切流，手工檢查 壓測過程中收集數據，手工生成保告壓測平臺壓測自動化：常態化壓測，壓測提效VS 線上引流錄制，自動收集壓測語料 一鍵壓測，自動完成切流等壓測準備，自動檢查 自動收集server cpu等信息，自動生成壓測保告。歷史報告對比。主流：主流：EbpfEbpf錄制錄制 +服務回放服務回放(回放回放 +Mock)Mock)選擇：選擇：中間件錄制中間件錄制 (服務本身承載錄制服務本身承載錄制+Mock)+Mock)引流回放平臺線上真實流量回歸驗證，流量錄制回放 對業務代碼的侵入性盡可能少 錄制不影響線上性能 串聯一起請求的所有調用 專注于資損bug發現，避免資損。信息流、訂單流、

7、資金流三流對比?？缦到y數據比對校驗。發現隱藏的系統bug。校驗規則使用Faas來實現，可插撥擴展?？焖偕暇€新的逆向校驗規則逆向監控正逆向校驗，雙重保障穩定性NO.1法則對線上系統保持敬畏異地多活單元化技術架構自研Go中間件單元化技術方案單元化落地過程中的高級坑高可用與單元化成本的平衡取舍0 03 3主題主題SUBJECT 問題：核心業務依賴機房，無法抵抗地域級、機房級故障，無法做到真正的容災 目標：建設一種通用的機房級異地容災架構，讓業務具備異地容災（單元化），故障快速恢復的能力 方案選型：同城雙活 偽雙活的單邊架構 主庫機房出問題依然會影響全量業務，災備切換時間較長 依然受地域資源限制和重大

8、自然災害影響，比如地震、電力限制 異地冷備 純冷備，資源嚴重浪費 日常不跑流量，不敢切流 即使切流，沒有任何預熱也很難扛住 異地多活，單元封閉 數據單元內閉合，讀寫均走當前單元，需保證分區數據的一致性 并非所有服務都做單元化改造，只需核心鏈路服務做高可用單元化改造 主要挑戰 距離導致的網絡時延是物理限制，不可能突破 多次跨地域的調用會嚴重影響服務RT，導致用戶體驗嚴重下降 網絡時延對數據一致性是巨大挑戰，要寫業務多活更是難上加難單元化架構背景單元化 單元封閉 核心鏈路內最多只有一次糾偏 統一單元化管控 單元化切流壓測，實現壓測提效異地多活，單元封閉單元劃分模式：Unit：即所有讀寫流量在單元內

9、完成，有異常不會影響其他單元。隨時切流 Copy：讀流量走單元服務，寫流量走中心服務。單元切流無異常，中心服務出問題，整體都會出問題單元化緯度：買家緯度單元化異地多活單元化架構中間件單元化方案自研Go中間件實現單元化路由方案。服務具備單元化糾偏路由能力。數據層中間件TDDL具備單元化禁寫能力。統一單元化管控規則系統龐大鏈路復雜：(解決：內圈向外推動)上下游鏈路較為復雜，架構由核心內部服務向外擴充推動單元化 只有必須的服務才進行單元化改造，平衡改造成本強中心化服務，例如庫存服務，如何做到單元封閉：(解決：按單元做業務劃撥)例如按單元劃撥庫存，某單元無庫存后，從其他單元再劃撥單元化后，壓測鏈路是否

10、影響：(解決：流量染色，支持單元化切流壓測)業務無感，業務代碼基本無改造，中間件層面支持，升級SDKSequence沖突：(解決：單元Group Sequence，各單元使用自己的Sequence號段)單元化后，Sequnce號段浪費，按單元化比例分配sequence號段單元化遇到的問題單元商品id單元庫存單元A1001200單元B1001300中心單元C1001500單元A扣庫存單元商品id單元庫存單元A1001200單元B1001300中心單元C1001500中心單元C扣庫存單元商品id單元庫存單元A1001200單元B1001300中心單元C1001500單元B扣庫存雙向同步雙向同步AL

11、TER TABLE tb1ALTER TABLE tb1 MODIFY COLUMN column1 int unsigned NULL;MODIFY COLUMN column1 int unsigned NULL;-原表column1是tinyint類型，變更為int類型-非單元化之前執行過類似變更，沒有問題，單元化之后，執行此變更，引起鎖表，連接數爆漲，業務不可用的故障單元化遇到的高級坑單元化數據庫執行無鎖變更有丟數據風險所以對于單元化數據庫，使用的是原生mysql變更而原生Mysql字段類型變更會鎖表無鎖變更簡述步驟：無鎖變更簡述步驟：1.創建臨時表：CREATE TABLE A LI

12、KE A。并變更結構 ALTER TABLE A XXXX。2.全量拷貝數據：INSERT IGNORE INTO A (SELECT%s FROM A FORCE INDEX(%s)WHERE xxx。3.增量數據Binlog同步：UPDATE/INSERT/DELETE A。4.切換新舊表：RENAME TABLE A to A。高可用與單元化成本取舍 基于成本考慮，平時兩單元 兩單元都扛流量，沒有資源浪費，并且相比冷備隨時可切 大促態擴到多單元，多機房扛量，一鍵部署大促擴單元降爆炸半徑自研Service Mesh實現去中心化網關Service Mesh基礎設施建設Service Mesh

13、業務落地方案0 04 4主題主題SUBJECT解題解題云原生架構升級云原生架構升級易為瓶頸易為瓶頸&成本成本&效率效率業務增速業務增速風險風險落地落地On ServiceMeshOn SDKVS底層引擎多語言、多框架，對跨語言/跨框架訴求強透明升級，無侵入業務，讓業務開發回歸業務，為業務提效采用Mecha的Service Mesh落地去中心化穩 定性隔 離降 本提 效QPSQPS飛速增長飛速增長接口量接口量迅速增長迅速增長高德特點高德特點Service Mesh降爆炸半徑 可以通過類似Envoy的數據面來管理 未來自研Leap Mesh(異構語言VM-Filter),由邊緣工具-Gateway-Ingress南北流量&邊緣節點 可通過部署類似Dapr的 Sidecar進行通訊（MultiMulti RuntimeRuntime 工具集合工具集合）東西流量多語言訪問中間件方案：多語言訪問中間件方案：內聚在業務中的中間件訪問，可下沉到Sidecar中Service Mesh架構 可監控 可回滾 可灰度Service Mesh業務落地 新技術應用遵從穩定性三板斧：可灰度、可監控、可回滾 支持按用戶白名單，百分比控制灰度 從非核心應用開始切換，逐步成熟之后再應用到核心應用。