《百度百科云原生DevOps实践-董淑照.pdf》由会员分享,可在线阅读,更多相关《百度百科云原生DevOps实践-董淑照.pdf(36页珍藏版)》请在三个皮匠报告上搜索。
1、百度百科云原生DevOps实践百度资深研发工程师/董淑照自我介绍董淑照董淑照2013年加入百度,百度资深研发工程师。原百度百科技术负责人,主要负责业务系统的架构设计开发,曾参与秒懂百科、百度健康医典等业务的孵化。现负责公司技术治理工作。主要内容 背景 业务架构的云原生实践 云原生能力进阶 总结和思考架构现状和演进思路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相对稳定,模块变更频繁 模块有独立交付部署的需求 适用于