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相对稳定，模块变更频繁 模块有独立交付部署的需求 适用于适用于 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私有化部署需求的业务 对资源弹性有较高要求的服务，对变更效率、资源成本敏感的服务 你主导开发的下一个应用你主导开发的下一个应用