A2--朱少華--趣丸科技多云架構下穩定性保障.pdf

《A2--朱少華--趣丸科技多云架構下穩定性保障.pdf》由會員分享，可在線閱讀，更多相關《A2--朱少華--趣丸科技多云架構下穩定性保障.pdf（37頁珍藏版）》請在三個皮匠報告上搜索。

1、趣丸科技多云架構下穩定性保障朱少華朱少華目前主要負責趣丸業務穩定性相關工作（業務高可用和容災建設、混沌工程實踐、AIOps探索等），保障趣丸相關業務產品的穩定運行和利用混沌工程推動業務韌性建設。曾就職于西山居、人人網等公司，從事虛擬化、容器化和 Devops等平臺開發工作?，F任趣丸-技術保障部運維架構師嘉賓照片目錄CONTENTS趣丸多云架構的引入01 多云架構的挑戰與優勢02 趣丸多云架構穩定性解決方案03 總結和展望04 01趣丸多云架構的引入趣丸多云架構發展趣丸多云架構的引入階段1階段22021年2023年階段1.52024年-階段3偽多活多云多活單元化多云架構階段1接入層固定百分比流量

2、業務層實現多云部署數據層單邊讀、寫業務層數據層A云B云50%讀寫讀寫50%偽多活階段接入層問題業務層不具備流量調度和故障轉移能力數據層單云部署，整體來看是個單點多云架構階段2業務層實現多云多活，具備10S內故障轉移能力數據層實現多云容災，業務根據延遲需要就近讀、單邊寫，故障場景自動切換數據源，具備秒級或分鐘級RPO/RTO能力。業務層數據層A云B云X%(100-X)%雙向同步讀寫寫讀failover讀多云多活階段接入層02多云架構的挑戰與優勢多云網絡互聯互通業務層流量調度基礎設施異構數據層跨云容災建設多云架構的挑戰與優勢避免供應商鎖定：防止過度依賴于單一的云服務供應商提高穩定性：多云多活，保障

3、業務連續性取長補短：不同的云供應商可能在特定的領域或功能有特長03趣丸多云架構穩定性解決方案趣丸多云架構現狀業務多云多活，數據層部分多活部分業務實現單邊寫，就近讀IngressGatewayServiceAServiceBControl PlaneIngressGatewayServiceBServiceAControl Planefailoversync高防高防Cloud ACloud B趣丸云原生架構下多云穩定性保障多云互聯01 業務多活02 線上質量保障03 多云互聯雙專線+VPN實現多云網絡互聯+多級鏈路冗余VPCVPCVPCVPCVPCVPCA云B云專線1專線2冷備VPCVPCVPC

4、VPCVPCVPCA云B云專線1專線2雙專線冷備切換時間長（5分鐘）專線資源利用率低雙專線隧道（BGP-ECMP+BFD）實現10S內感知鏈路問題并收斂路由提高專線資源利用率多云互聯雙專線+VPN實現多云網絡互聯+多級鏈路冗余雙專線+VPN熱備（BGP-ECMP+BFD）在雙專線中斷時，VPN接管流量保障業務不中斷多條VPN共擔流量，保障帶寬充裕VPCVPCVPCVPCVPCVPCA云VPN隧道B云雙專線趣丸云原生架構下多云穩定性保障多云互聯01 業務多活02 線上質量保障03 業務多活/南北向流量云A云B智能 DNS：全局流量控制，實現接入層多活HTTP DNS：繞過運營商 Local DN

5、S，防止域名劫持和區域封堵兜底：APP 自主檢測切換入口多活業務多活/南北向流量云原生高防WAF云A云原生高防WAF云B云原生高防：接入簡單、延遲低、防護性能靈活選擇WAF：基于 Istio IngressGateway，接入簡單、靈活定制攻擊防御業務多活/東西向流量Istio 的多云流量管理單一網格的多主架構模式ServiceAServiceBControl PlaneServiceBControl PlaneServiceACluster:cloudACluster:cloudB每個集群一個控制面更強的可用性配置隔離多個集群一個網格 工作負載直接相互訪問Network:network1Is

6、tio Mesh業務多活/東西向流量Istio 的多云流量管理流量管理策略：本地優先Cluster:cloudA Region1Cluster:cloudB Region2優先訪問本Region，本Zone本Zone失效，優先訪問本Region其他Zone本Region失效，訪問其他Region的ZoneIstio MeshServiceBZone:zone1ServiceAZone:zone2ServiceBServiceBZone:zone312 loadBalancer:localityLbSetting:enabled:true failoverPriority:-topology.i

7、stio.io/network -topology.kubernetes.io/region -topology.kubernetes.io/zone3業務多活/東西向流量容器區域分布不均導致負載不均保持k8s集群節點數區域分布均衡spec:topologySpreadConstraints:-maxSkew:1 topologyKey:zone whenUnsatisfiable:DoNotSchedule labelSelector:app=account配置調度傾斜，保持 Pod 分布均衡localityLbSetting 設置到 Region 層級 loadBalancer:local

8、ityLbSetting:enabled:true failoverPriority:-topology.istio.io/network -topology.kubernetes.io/regionZone：zone1ServiceAZone：zone2Zone：zone1ServiceBZone:zone2業務多活/東西向流量故障轉移ServiceAServiceBConnect failedhttp 5xx故障轉移策略在應用層面降低故障的影響故障轉移策略越接近應用優先級越高svc namespacecluster trafficPolicy:connectionPool:tcp:conn

9、ectTimeout:200ms outlierDetection:baseEjectionTime:60s consecutiveGatewayErrors:10 consecutiveLocalOriginFailures:10 interval:10s maxEjectionPercent:60 splitExternalLocalOriginErrors:true業務多活/應用質量交付&運行質量保障應用等級開發保護異常告警一級應用禁止在沒有熔斷的情況下依賴一級以下的服務具備就緒和存活探測接口優雅退出K8S PriorityClasses：p1K8S PDB 配置SLI（不少于4個）二級

10、應用禁止在沒有熔斷的情況下依賴二級以下的服務具備就緒和存活探測接口優雅退出K8s priorityclasses：p2K8s PDB 配置SLI（不少于2個）三級應用具備就緒和存活探測接口優雅退出K8s priorityclasses：p3K8s PDB 配置SLI（不少于2個）四級應用具備就緒和存活探測接口優雅退出K8s priorityclasses：p4K8s PDB 配置SLI（不少于1個）熔斷：避免級聯故障探針和優雅退出：彈性縮擴容前提PriorityClasses：保障高等級服務被優先調度PDB：保障應用 Pod 副本數保持在一個健康的范圍內應用SLI：應用健康的黃金指標，快速發現

11、問題業務多活/彈性伸縮多層級、多維度的彈性策略充分利用云資源彈性優勢，保障穩定性的同時降本業務高峰期SLO達標，容器集群平均CPU利用率達到30%K8S 節點 CA(Cluster Autoscaler)按照資源利用率擴容業務高峰期提前擴容Pod HPA(Horizontal Pod Autoscaler)按照資源利用率擴容業務高峰期提前擴容梯度縮擴容緩解 xDS 下發壓力趣丸云原生架構下多云穩定性保障多云互聯01 業務多活02 線上質量保障03 線上質量保障/可觀測以應用為中心的可觀測能力基礎設施云化后，SRE的重心更聚焦于應用，通過應用將人、資源、告警、指標、調用鏈、日志等信息進行關聯，構

12、建業務拓撲圖，形成一個以應用為中心的可觀測平臺。平臺在能力視角解構，在業務視角重構線上質量保障/告警治理提高告警有效性，快速發現故障提高有效性制定告警接入標準，防止告警泛濫告警壓縮和無閾值告警，通過 AI 減少無效告警提高覆蓋率制定可觀測標準，對資源和應用進行告警默認覆蓋線上質量保障/定位和恢復精確定位，快速恢復定位鏈式根因定位，通過 AI 對應用告警進行歸因分析恢復恢復預案，制定故障場景恢復預案，加速恢復效率自愈，抽離恢復預案操作，與告警規則結合實現自愈，提高恢復效率04總結和展望總結和展望故障不可避免，可以通過高可用、容災建設，最大化的提升系統的可用性。但是：極端的可用性必然帶來巨大的投入。先評估現狀，再推進。根據架構分層的維度，結合故障層面，評估各層在RTO和RPO方面的高可用現狀，建立容災能力評估模型。根據投入產出比制定高可用建設工作計劃?？偨Y和展望容災能力評估模型。模型從架構分層的維度，結合故障層面，評估各層次在RTO和RPO方面的能力?？偨Y和展望向多云階段二繼續演進，同時為階段三進行技術調研和積累。單元化：業務數據水平拆分，單元間相互隔離，故障僅影響本單元內用戶，并可快速恢復邊緣接入：延遲更低、可用性更高的接入方案感謝聆聽關注QECon公眾號