新浪微博架构与平台安全.ppt

微博架构与平台安全 微博架构发展 新浪微博从 0 ~ 50,000,000 用户 技术架构经历了 3 个阶段 第 1 版 技术特点 微博本质是解决发表/订阅问题 第 1 版采用推消息模式，将发表/订阅简化成 insert / select 问题 技术细节 典型 LAMP 架构 MySQL：单库单表, MyISAM MPSS (Multi-Port Single Server) 快速成长 用户快速增长 出现发表延迟现象，尤其是明星用户 架构演变 分发推送是造成发表延迟首因 模式改进 数据规模增大也带来一定延迟 规模增大：数据拆分 锁表问题：更改引擎 发表过慢：异步方式 第 2 版 投递模式优化 推模式改进，不需要推送到所有用户 存储及发表峰值压力减轻 投递延迟减小 数据拆分 优先按时间维度拆分 内容和索引分开存放 内容使用 key-value 方式存储 (NoSQL) 索引由于分页访问，拆分有挑战 异步处理 发表异步化 发表速度及可靠性得到提高 使用 MemcacheQ 增加 stats queue，适合大规模运维 技术细节 InnoDB 引进，避免锁表烦恼 PHP 中 libmemcached 代替 memcache 在高并发下稳定性极大提高 高速发展 系统问题 单点故障、“雪崩” 访问速度，国内复杂网络环境 数据压力及峰值 MySQL 复制延迟、慢查询 热门事件微博发表量，明星评论及粉丝 如何改进 系统方面 允许任意模块失败 静态内容 CDN 加速 数据压力及峰值 将数据、功能、部署尽可能拆分 提前容量规划 平台化需求 Web 系统 有用户行为才有请求 API 系统 轮询请求 峰值不明显 用户行为很难预测 系统规模持续增大 平台化需求 新的架构如何设计？ “Break large complex systems down into many services... search touches 100s of services (ads, web search, books, news, spelling correction...)” - Jeff Dean, Google Fellow 服务化 服务→接口→应用 第 3 版 平台服务 基础服务 高性能架构 问题本质 每天数十亿次Web及接口请求 请求内容随时变化，结果无法 cache 如何扩展？ 思路 去状态，可请求服务单元中任意节点 去中心化，避免单点及瓶颈 可线性扩展，如 100 万用户，10 台服务器 1000 万用户，100 台服务器 减少模块耦合 实时性 微博 cache 设计 高可用 好的架构具有高可用性 业界 Amazon S3: 99.9% Amazon EC2: 99.95% Facebook: n/a 微博平台 ~ 99.95% (5 小时 / 年) 如何达到 容量规划 图表 监控及 admission control... 接口及资源监控, 7x24 业务回环测试, 监测业务逻辑有效性 集成测试 图表 接口监控 curl / 各地请求情况及响应时间 流量异常 / access log non-200 结果 / 失败率 / exceptions 将监控指标量化 类似 mysql seconds behind master “Many services are written to alert operations on failure and to depend upon human intervention for recovery, about 20% of the time they will make mistakes. Designing for automation.” - James Hamilton, VP of Amazon 自动化 “System administration at Google usually have 1 week of on call duty, and the other 5 weeks are spent making improvements to make the on call portion more optimized, automated, and trouble-free” - Tom Limoncelli @ Everything Sysadmin Lumeta Corporation总监，贝尔实验室专家 高可用性还有异地分布的需求 在国内网络环境下，IDC 灾难、机房检修维护会导致服务中断 用户就近访问可提高速度 静态内容分布采用 CDN 技术，成熟 动态内容分布是业界难点 核心是数据的分布式存储 理想的分布式存储产品 支持海量规模、可扩展、高性