百度文件系统BFS - 万亿量级实时数据库Tera - 集群调度系统Galaxy • 个人主页&Blog - https://github.com/bluebore - http://bluebore.cn 提纲 • 百度文件系统简介 • 分布式系统设计实践 • 总结与致谢 百度的集群环境 • 单个集群通常几千台机器 • 百度文件系统(BFS)、集群调度系统（Galaxy）、分布式协 调服务（Nexus）是核心服务 master BFS master Nexus lock service 分布式软件栈中的BFS The Baidu Stack 网络通信框架Sofa-pbrpc 分布式文件系统 BFS 集群调度系统 Galaxy 分布式协调服务 Nexus 分布式数据库 Tera 分布式计算框架 Shuttle Apps(Spider/Index/Search) 数据中心操作系统(DCOS) • 文件系统 - The Baidu File System - 持久化存储 百度文件系统架构 设计一个分布式系统要考虑的 • 数据与计算的分片 • 分区故障容忍 • 数据一致性 • 系统扩展性 • 延迟与吞吐 • 成本与资源利用率 • … 数据与计算的分片 • 哈希分片 - 简单、均衡 - 扩容复杂、易用性差 - 一致性哈希、虚拟节点 • 按范围、数据量分 - 使用简单 - 需要管理元数据

固定HASH算 法 固定数目 数据分片 桶->存储节点 对照表 Cellar起源—Tair架构 服务层 请求 mdb 响应 ldb fdb rdb 引擎层 迁移 复制 • 中心化集群问题 • 可用性问题 • 性能问题 • 运维问题 Cellar起源—Tair问题 Cellar起源 架构升级 性能优化 可用性优 化 可运维性 Cellar 开源 Tair • Cellar起源 Cellar—中心节点架构演进 • 性能问题 客户端集中获取路由表 • 隔离性问题 中心节点暴露给客户端 单独的路由表获取模块 Cellar—中心节点架构演进 • 可扩展性： 路由查询能力 可线性扩展 • 隔离性： 客户端与中心节点 完全隔离 Cellar—中心节点架构演进 一致性 • 主备脑裂 • observer与config • Zookeeper选主 • 元数据Zookeeper存储 分片1&2 log Cellar—异地容灾 • 多机房建设 网络延迟大 专线稳定性差 • 异地容灾需求 跨集群数据同步 Cellar—异地容灾 集群节点同步 消息队列同步 复制延迟 低 高 系统复杂度 低 高 运维成本 低 高 实现难度 高 低 扩展性 低 高 • 低延迟 • 低复杂度（运维成本） Cellar—异地容灾 • Cellar起源 • 中心节点架构演进

AND/IOS/H5/Open 静态站 网贷服务 借款流程 Cache集群 安全加密 网贷服务 CDN 支付结算 订单 DB从 批 处 理 系 统 活动 DB主 DB从 版本管理 产品 ... 同步 …... 网站、基础服务 移动后台 业务和团队规模迅速扩张 粗粒度服务化，基础设施完善 CDN/页面缓存/静态站/缓存集群 移动后台旁路 流程double，冗余开始出现 -------Joe Armstrong 关键点 分而治之，缩小竞争面 加速资源交换，更快响应 共享资源串行操作 数据一致性(脏读,丢失更新等) 业务纵向拆分，化整为零 资源拆分，横向扩展 cache，index，partition parallel non-blocking sync、lock，cas 额度、库存、积分、优惠券… CAP 数据竞争� [sql方案示例] 智能DNS，DNS负载均衡 限流(limit,lua)，openresty，4层/7层LB 弹性扩容，限流(token)，熔断，防刷 降级，熔断，弹性扩容 多IDC，区域容灾，多ISP 集群，高可用，分片 本地缓存，防刷，流控 终端 域名 机房 LB / NG.. 网关 Cache 服务 抓大不能放小[细节决定成败] 线程阻塞>300 中间件内存管理、线程状态，连接状况

设计要点二：接入层设计 www.163yun.com 设计要点三：无状态化 www.163yun.com 设计要点四：服务拆分与服务发现 www.163yun.com 设计要点亓：数据库横向扩展 www.163yun.com 设计要点六：缓存的设计 APP缓存 CDN 接入层 静态资源 动态资源静态化 应用本地缓存 分布式缓存 www.163yun.com 设计要点十一：全链路监控 www.163yun.com 设计要点十二：全链路压测 www.163yun.com 微服务平台总览 容器平台 (多集群基础设施) Pod & Deployment 网络 Calico, OVS 存储 Ceph 滚动更新 弹性伸缩 日志中心 基础设施监控 开 发 集 群 测 试 集 群 com 开发集群 测试集群 CICD (开发流程管理) 流水线管理 代码 检出 代码 编译 镜像 构建 集成 测试 部署 测试平台 (集成，场景测试) 单接口 用例 场景 用例 执行 集 定时 执行 接口 Mock 覆盖 率 生产镜像 仓库 测试镜像 仓库 历史 管理 批量 导入 接口 监控 生产集群 镜像

和存储 有状态分布式系统的高可用问题 一致性 可用性 分区容错性 Paxos Raft 2PC Gossip Ø 处理请求需要特定节点 Ø 必须要考虑数据备份和同步 的问题 Ø 容量扩展和高可用需要不同 解决方案 Ø 服务节点不能随便迁移 CAP Is Not Simply 2 out of 3 Ø 没有分区时，可用性和一致 性要兼得 Ø 经常要考虑的是可用性和一 致性各有一部分 State u 创建1个新的Pod Ø Controller观察特定领域的 系统状态 Ø 协调Desired State跟 Realized State之间的差 距，维持最终一致性 Ø 定期处理集群中的事件 Ø 系统必须是幂等的 控制器的设计理念 控制逻辑应该只依赖于当前状态 假设任何错误的可能，并做容错处理 尽量避免复杂状态机，逻辑不要依赖无法监控的内部状 态 每个模块都可以在必要时优雅地降级服务 验而且幂等，没有缓存情况下系统仍可服务 Ø 错误回复缓存，过期时间不能太长，而且有清晰的 修复建议 Ø 数据库更新与缓存失效的策略 最佳实践分享 有关配置文件 Ø 集群使用统一的配置来源 Ø 定义正常的默认配置，满足读取不到配置的正 常运行 Ø 支持可扩展的配置命令格式 Ø 尽量支持更改配置不需要重启服务 Ø 注意配置项之间的关联性 欢迎与我交流 王昕个人微信 欢迎与我交流 王昕个人微信

RabbitMQ, RocketMQ • 模块间解耦 • IDC数据同步 • 异步RPC • ICE - 负载均衡，AMI，AMD，多线程 极光推送后台系统架构 02 并行化 • 横向扩展处理能力 • 数据分片存储 • 多节点+分片+多副本架构 • 数据读写动态路由 • 请求并行处理 • 模块级别并行 • 代码级别并行 极光推送后台系统架构 03 MQ Segment ，服务降级 • 监控及告警 • 多维度监控，告警系统 极光推送后台系统架构 08 K8S部署业务 • 原有系统的运维工作繁杂，资源利用率低 • 弹性扩容 • 配置统一管理 • 内外集群隔离 • Pod包含多个容器 - 辅助容器，业务容器 • 业务模块代码架构调整 • 监控体系调整 极光推送后台系统架构 09 结束语 • 高性能/低成本、高可用、高运维 • 只用验证过的开源组件

• DB读写压⼒力力⼤大 • 舱位状态变化频繁 • 热点航线问题 • 计算量量巨⼤大 报价引擎 索引 搜索引擎核⼼心 • 规则库 => 索引库 • 规则库写⼊入量量⼤大，集群峰值达20K TPS • 要求同步延迟很低，不不超过60s • 保持顺序⼀一致性，如果先删后插变成 先插后删，数据会不不⼀一致 • 数据最终⼀一致 • 系统⾼高可⽤用 报价引擎 空间换时间 • 缩短对象驻留留内存时间，减少gc次数，优化单机吞吐 • 数据交换采⽤用protobuf + gzip处理理 • jit、预热 回顾 • ⽔水平分层，纵向分渠道，良好的扩展性 • 实时计算 + 阶梯式缓存，成本与报价新鲜度的权衡 • 闭环系统 • 索引库数据同步 • 本地缓存的设计，更更新策略略 • 缩减对象内存 • ⼀一致性哈希负载均衡 ⼼心得

IOThreads 收到复制响应 Pending Callbacks ResponseThreads 发送响应 Journal Cache Journal Files 线程模型 集群 · 架构 没有最好的架构，只有最合适的架构 取 · 舍 学会 ⽅得始终 取 舍 从实用角度出发，如何取舍？ Consistency ⼀一致性 Availability 可⽤用性 ⼤大促限流 Complexity 复杂度 Apache ZooKeeper “程序员都喜欢ZooKeeper，但用户正相反” 可维护性问题 多机房部署时可⽤用性问题 数据容量量有限，集群规模有限 选举恢复速度慢，不不可⽤用时间较⻓长 John Ousterhout Diego Ongaro “In search of an understandable consensus 牺牲可⽤用性换取⼀一致性 性能⼀一般 集群规模不不能太⼤大 Raft总结 读请求分流 顺序⼀一致 已提交位置之前的⽇日志具有不不变性。 对于提交的⽇日志，相同位置上Follower的⽇日志和Leader上是⼀一样的。 强⼀一致 如果两个节点上的⽇日志完全相同，并且这些⽇日志都已经被状态机执 ⾏行行，那么这两个节点的状态是相同的。 集群节点数越多性能越好吗？ NO 引⼊入Observers

部署模型(跨机房) IDC-A IDC-B 接入域-A 执行结点 作业实现 ZK saturn-zk-* saturn.vip.com 控制台集群 (Tomcat) ZK Observe r ob-saturn-zk-* 2台 3台 x台 调度器集群 接入域-B 执行结点 作业实现 功能地图 01 02 03 多种作业类型与 作业模式 资源动态平衡 框架与业务隔离 三大功能特性 Executor 作业实现 Saturn Core JVM System Class Loader Job Class Loader Call 类加载 作业运行基本原理 更多。。。 超时控制 多ZK集群支持 监控体系 手动触发 批量处理 强行终止 Dashboard … 为什么需要容器化 资源利用 提高物理资源的 利用率 系统弹性 资源弹性伸缩 运维效率 上线周期、峰值 应对 作业隔离

应⽤用实施升级
 * 聚焦性能做 case
 * 补⻬齐设施能⼒力力
 * 积累业务升级改造经验
 2. 架构级升级
 * 规模化后，架构级别收益会显现 业务架构升级case 的选择策略略 1. 集群/流量量⼤大/核⼼心有认知
 * ⽅方便便看升级改造效果 2. 瓶颈 match 升级
 (如 CPU 压不不满、IO较多、⾼高Load)
 * 可以确定获得⼤大⽐比例例收益 3. 业务逻辑简单优先
 已统⼀一接⼊入 ⽬目标与规划 • 实现分布式回压(backpressure) • 保证整体系统稳定不不过载且充分利利⽤用资源 • 2018双11有试点实验，后续重点
 •通过回压把应⽤用集群压⼒力力反馈到基础设施 • 更更精准有效的应⽤用弹性调度 •实现全异步/流式为核⼼心的服务框架 • 考虑引⼊入 Kotlin 协程 •符合现在过程式的编程习惯（⾮非 FP ⻛风格）