百度百科云原生DevOps實踐-董淑照.pdf

《百度百科云原生DevOps實踐-董淑照.pdf》由會員分享，可在線閱讀，更多相關《百度百科云原生DevOps實踐-董淑照.pdf（36頁珍藏版）》請在三個皮匠報告上搜索。

1、百度百科云原生DevOps實踐百度資深研發工程師/董淑照自我介紹董淑照董淑照2013年加入百度，百度資深研發工程師。原百度百科技術負責人，主要負責業務系統的架構設計開發，曾參與秒懂百科、百度健康醫典等業務的孵化?，F負責公司技術治理工作。主要內容 背景 業務架構的云原生實踐 云原生能力進階 總結和思考架構現狀和演進思路1.背景百度百科業務概況26002600萬萬+詞條750750萬萬+生產者億級別億級別 日PV萬級別萬級別 峰值QPS技術架構概況業務層服務業務層服務內部PaaS平臺幾十個單體服務，PHP/ODP框架近200個代碼庫基礎服務基礎服務內部PaaS平臺幾十個微服務第三方服務第三方服務百

2、度云內部業務中臺存儲服務存儲服務DB、Cache、ES接入層接入層BFE、CDN存在的問題 業務架構：模式成熟，但與現行業界標準不接軌 資源效率：利用率和彈性能力有提升空間 研發流程：總體順暢，效率仍需打磨海外版百科的探索 采用微服務架構、K8s在公有云上搭建的服務架構演進目標效率效率&現代化現代化 實現平滑遷移，業務代碼層面不做任何變動 實現效率提升，研發流程效率要優于現狀 承載業務將來進一步向微服務化演進的能力架構演進原則 主流技術棧：主流技術棧：全面擁抱云原生，將精力集中在業務系統設計上 避免造輪子：避免造輪子：盡可能采用云原生機制，通過設計模式實現 穩妥推進：穩妥推進：控制項目周期，保

3、障業務穩定，降低風險 提升效能：提升效能：資源效能、流程效能應當優于當前架構演進路線運用設計模式填平傳統應用與云原生的Gap2.業務層的云原生實踐路線選擇：單容器方案 單容器方案：單容器方案：基于ODP架構先進行云原生轉型，再進行微服務化改造 微服務方案：微服務方案：先實現微服務化改造，再完成云原生轉型 決定因素：決定因素：長線技術規劃，ODP/PHP保持現有質量效率并逐步降低規模單容器方案微服務方案單容器方案：面臨的問題 鏡像構建：鏡像構建：上百個代碼庫，如何并行發布 鏡像尺寸：鏡像尺寸：GB級別，變更效率如何保證 配置文件：配置文件：配置管理，配置派生 變更流程：變更流程：平臺工具，分級發

4、布一個ODP容器包含的內容核心問題：鏡像和部署方案類別類別方案方案說明說明并行并行上線上線構建構建速度速度變更變更速度速度冷部署冷部署(每次變更重建Pod)大鏡像方案所有內容打包到一個鏡像中慢慢分模塊鏡像方案每個ODP模塊一個鏡像快慢熱部署熱部署(代碼變更不重建Pod)PV掛載方案將PHP代碼放到PV卷內，上線時更新PV卷文件快快Sidecar方案ConfigMap記錄模塊版本，Sidecar監聽版本變更快快Sidecar模式：實現代碼熱部署 ODPODP服務的本質：服務的本質：Runtime+Code PHPPHP語言的特性：語言的特性：天然可熱更新module-config示例：name:

5、baidu/xxx/app-demoversion:1.0.200.1token:xxx模塊變更InitContainer模式：實現快速部署 新新PodPod創建：創建：如何保證部署速度？appbaseappbase基準鏡像，包含所有代碼庫最新版本包初始化時復制到本地充分利用Docker緩存 installerinstaller初始化時部署代碼庫優先使用本地版本包模塊變更分級發布和多地域部署 使用Namespace區分Preview、Staging、Prod等環境 使用不同地域的集群實現多地域部署 通過不同集群+Namespace的組合，實現分級發布Step 1.預覽機Step 2.小流量St

6、ep 3.單地域Step 4.全流量使用Helm進行應用管理 使用“模板+配置”的方式，解決不同環境、不同部署間差異性CI/CD流水線和環境修改代碼調試代碼評審構建自動化測試人工測試分級發布“無環境，不效能”人手N個環境，即用即申請，實現“環境自由”借助Helm，環境的標準化和自動化變得異常簡單dev環境autotest環境test環境preview/staging/prod環境沉淀：“Runtime+模塊”應用模型 特點特點 服務由基礎環境(Runtime)+若干模塊(代碼庫)構成 Runtime相對穩定，模塊變更頻繁 模塊有獨立交付部署的需求 適用于適用于 PHP NodeJS Pytho

7、n Java 充分享受現代化基礎設施底座的便利3.云原生能力進階技術標準化和架構統一化MatrixMatrixKubernetesKubernetes打包格式打包格式平臺包格式Docker鏡像部署配置部署配置平臺配置YAML文件(K8s資源描述)服務發現服務發現BNSK8s Service服務單元結構服務單元結構單層Matrix ContainerPodContainer兩級監控監控自研Argus/Logstream+SIACProm+Promethus資源來源資源來源內部云資源混合云資源使用原生Service實現服務互訪 特點特點 K8s原生機制 秒級感知下游Pod變化 示例示例 Nginx

8、 upstream example-app server example-app.baike-prod;ODP Conf Name:example-app DefaultPort:80 .Server Hostname:example-app.baike-prod基于Promethus+Grafana的監控基于HPA的彈性伸縮 設置設置CPUCPU、內存等目標值，根據度量指標自動調節、內存等目標值，根據度量指標自動調節PodPod數數 示例：spec:maxReplicas:75 minReplicas:15 scaleTargetRef:apiVersion:argoproj.io/v1al

9、pha1 kind:Rollout name:odp-runtime-pcview targetCPUUtilizationPercentage:60HPA根據CPU負載自動擴容運用設計模式實現定時任務 鏡像較大：1GB 創建Pod時間較長：1分鐘左右 如何實現分鐘級定時任務調度？如何實現分鐘級定時任務調度？設置定時任務運行Pod生產者-消費者模式Cronjob負責分發任務、監聽任務執行任務實際運行在常駐Pod中當然，以上都是權宜之計 單體(Monilithic)應用已不太適合當前的主流工具和研發模式 新的基建土壤上一定會生長出新的架構形態業務架構的微服務化演進 總體路線總體路線 順應市場趨勢

10、，后端業務層轉向Go語言為主的技術路線 PHP保持當前質量效率并逐漸降低規模 前端NodeJS微服務化，基于SSR或CSR，獨立自主發展 實施方式實施方式 確立若干個標桿服務，制定團隊內標準規范 全方位完善代碼規范、基礎庫、容器、互調用、流水線、單元測試、部署編排、開發環境、日志、監控等讓業務生在云上、長在云上4.總結和思考云原生帶來的收益 成本和效率成本和效率 能力提升能力提升 彈性伸縮：彈性伸縮：動態擴縮容，應對流量突變 云原生監控：云原生監控：監控延遲降低至1分鐘，系統可觀測性提升前后對比資源成本 68%環境構建時長 85%平均上線時長 35%橫向擴容時長 83%實例下線時長 92%云原

11、生技術棧的能力學習要求對一般開發人員的要求對一般開發人員的要求對架構對架構、運維人員的要求、運維人員的要求Docker熟悉日常使用，會寫Dockerfile了解Docker原理，熟悉Dockerfile優化Kubernetes理解概念和原理，會基本操作熟練進行日常操作、一般問題排查Helm依葫蘆畫瓢，會做簡單的配置修改會從零開始寫Helm Chart設計模式參考12要素原則進行應用設計開發能夠將技術框架、業務結構和K8s結合DevOps/根據業務實際設計合理高效的流水線對開發者的建議 使用標準化云原生技術帶來的好處使用標準化云原生技術帶來的好處 業界的事實標準：Write once,run anywhere 與完善的生態、豐富的資源無縫對接，帶來效率提升 完整的API，便于開發和集成 降低資源成本，提升資源彈性 適用場景適用場景 創新業務、中小型業務、DevOps型業務 有混合云部署需求或To B私有化部署需求的業務 對資源彈性有較高要求的服務，對變更效率、資源成本敏感的服務 你主導開發的下一個應用你主導開發的下一個應用