郑然_《百度搜索系统的PaaS架构设计和实践》PDF版

Eden 百度搜索引擎的 PaaS架构设计和 实践 百度搜索架构师 郑然 ArchSummit全球架构师峰会深圳站 2016 郑然 ? 百度网页搜索架构部 – 搜索架构师 ? 七年搜索引擎架构工作经验 – 流式索引构建系统 , 离线计算平台架构 – 服务化组件开发平台 SOFA – 在线服务 PaaS平台建设 – 服务治理 & 高可用架构 & DevOps 自我介绍 目录 CONTENTS 百度搜索引擎的挑战 Eden的前世今生 软件包的标准化 Eden架构设计和实践 经验教训 百度搜索引擎的挑战 机器数量多 , 服务数量大 挑战 服务变更多 ,变更数据 大 每天几十万次变更 ,每周 10P量级 的文件更新 , 千余人并行 开发几十个模块 检索流量大 ,稳定性要 高 每秒 数万 次请求 ,满足 99.995%的 可用性 数万台服务器 , 数十万 个服务 ,分布在多个 IDC 百度搜索引 擎的挑战 Eden的前世今生 index0 index0 merger index1 index1 index2 index2 shard0 shard1 shard2 海量服务分布 吞吐和延迟最优 从搜索引擎 的基础架构 说起 2009年以前 2010 ~ 2013 2014 ~ 2016 刀耕火种时代 蒸汽机车时代 集成电路时代 粗暴 简单 半 自动化 精密 高效 服务治理的 三个阶段 特点 单机单服务 服务名等价于机器名 ?#23435;?#19978;千台 机器 , 流程相对简单 资源管理以整机为单位 刀耕 火种 时代 2 1 34 5 索引量增长 , 相关性算法越 发复杂 , 资源消耗增加 业务驱使 单机单服务 , 机型差异 大 , 资源使用不均衡 , 呈现?#29616;?#30340;木桶效应 资源优化 ? 单个索引 shard瘦身 , 优化索引分布 单机多服务 开发了 DOP系统 , 大幅 度节省了资源 , 提升了 ?#23435;?#25928;率 服务治理问题 ? 没有把服务治理系统 作为一个有机整体 缺陷 蒸汽 机车 时代 服务存活率 99.5%1 弹性的服务扩容和缩容2 几十个模块 , 上千路数据 , 每天几十万次变更3 以 Eden为核心构建 DevOps生态4 集成电路 时代 软件包的标准化 部署系统 的核心 标准化是自动?#23435;?#30340;基础 部署系统的核心?#21069;?#30340;标准化 本质上希望自给自足 容器的发展更说明包的重要性 OCI定义了容器的标准 Eden 标准化包 架构设计和实践 架构蓝图 Eden的变更世界观 ?#25910;?#21644;高可用 基础设施 ?#25910;?#26816;测监控系统 日志服务 Eden测试支持 运行的服务 测试平台 准入测试 Eden Job Engine 服务升级 服务伸缩数据更新 实例迁移 api-server InstanceMgr NamingService matrix matrix matrix 日志收集 日志?#27835;?机器维修 网页搜索 度秘?#35745;?#25628;索 机 器 维 修 仲 裁 IDC1 agent IDC2 agent IDC3 agent command WebUI zo o k e e p e r 架构蓝图 增量 模型 不可变 模型 增?#26377;?#26381;务 , 删除老服务 基于 patch的增量变更 部署效率高 , 变更过程复杂 消除环境漂移 , 部署效?#23454;?Eden的变 更世界观 darcs 理论 记录实例的目标状态和当前状态状态 对比 文件 下载 文件下载后执行前置和后置命令 执行 命令 改变 状态事务 Eden的变 更世界观 IO要限速 , 不影响服务 数据有多路 , 按照优先来 并 发要控制 , 保护数据 源 夜间 流量低 , 限制可 放宽 效率 ! 效率 ! 效率 ! Eden的变 更世界观 Eden的变 更世界观 分布式锁 实例 实例 实例 保持有效实例数 实例 1 实例 2 实例 3 实例 4 实例 5 实例 6 实例 7 实例 8 实例 9 STEP 1 STEP 2 STEP 3 1. 文件传输 2. 执行前置命令 3. 切换新文件 4. 执行后置命令 效?#23454;?#19979; 分级过程只能串 行 , 不可避免的 存在等待 传输和生效分离 文件预分发实现了变更效率质的飞跃 常规部署 Eden的变 更世界观 传输和生效分离 实?#27835;?#20214;预分发 Eden的变 更世界观 分级 回滚 关键 技术 分级 支持 回滚 支持 变更的原则 分级和可回滚是 任?#25105;?#20010;变更操 作的基本原则 关键机制 实例级变更的能 力和备份的能力 分级粒度 数据备份 元数据的版本化 管理和文件的版 本化管理 没有分级和回滚的变更就是一枚炸弹 ! 实例级的数据 , 连接 , 资源配额 的变更 ?#25910;?高可用 ?#25910;?? 硬件 ? 主板 , CPU, 内存 , 风扇 , 网卡 , Raid卡 ? 磁盘 (挂载点缺失 , 扇区损坏 , SMART, 设备文件?#25910;?) ? 软件 ? 文件系统 (文件损坏 , inode满 , 磁盘满 ) ? ssh登录失败 ? agent假死 ? 全靠人的时代 : 服务存活率 96%, 机器?#25910;下?4% HOW? 迁移实例 ?? 无冗余资源 , 副本数多 ? 有冗余资源 , 副本数少 ? ?#25910;?#26426;器多 , 全部送修 ? ? 死机 ? 送修 ? 带伤 ? 分批送修 . 优先级呢 ? ? 机器修?#31895;?#21518; ? ? 重启 or 重装 ? 进程存活 版本一致 agent保活 原地维修 迁移服务 服务维修 ?#25910;?#33258;愈能力 ?#25910;?高可用 优 先 级 漏斗分类 副本状态 ?#25910;现?#35013; 机器维修 机器健康率 98.5% 服务存活率 99.5% 我们做到了 Parallel 服务的中枢 ? 2014年的一次误操作 , ?#24067;?#21024;除了 一个服务单元的摘要服务 ? 2015年的一?#26410;?#35823;配置 , 一天内缓 慢删除了 2000个服务 , 第二天才发 现 ? Eden不可用 , 搜索服务不可变更 , 影响时效性结果 , 阻碍近千人的开 发团队上线 高可用机制 ? 多维度全局安全阈值 ? app粒度的权限控制机制 ? agent不可用 , 不影响正在运行的 服务 ? 版本化服务描述文件的变更 , 做到 变更可追溯 ?#25910;?高可用 经验教训 经验教训 经验 ? ?#25910;?#26816;测和维修切记太敏感 ? 任何变更都要分级 ? ?#25910;?#19981;可怕 , 关键是自愈能力 ? 放牛式思维 教训 ? 可视化是自动化的前提 ? 自助化 +平台级的约束能力 ? 接口幂?#28982;?? safe mode机制保底 服 务 治 理 匠 心 精 神 深 耕 运 维 精 益 求 精