微博架构与平台安全.pptVIP

如何解决 新一代推送接口(Stream API) 采用推送的方式 有新数据服务器立即推送给调用方 无数据则不消耗流量 客户端实现更简单 技术特点 低延迟，从发表到客户端接收1秒内完成 高并发长连接服务 推送架构 为什么先持久化 KISS，Keep It Simple and Stupid 测试表明持久几乎不增加延迟开销 batch insert cursor read 内部细节 Stream Buffer 保存用户最近数据 保存客户端断线重连之间下行数据 平台安全 由于接口开放，需要防范各种恶意行为 垃圾内容 垃圾粉丝 恶意行为 内容安全 微博平台需要 为用户提供安全及良好体验的应用 为开发者营造公平的环境 接口需要清晰的权限控制及安全规则 接口安全 Auth层 访问需要 AppKey 需要 OAuth 授权 权限层 流量控制、权限 架构就是将复杂问题抽象简单并解决 下一代微博架构，期待您的参与 1 week MPSS 大系统普遍原则 一台服务器多个小的服务，而不是一台服务器一个大服务 最高层次，虚拟化 MPSS 大系统普遍原则 一台服务器多个小的服务，而不是一台服务器一个大服务 最高层次，虚拟化 锁表：同时评论，加关注增多 解决方法： 1. 合并所有表(不是最佳) 2. 二次索引， 异步原因：发表需要入库，索引，统计，后台，计数等，周期较长 todo: 改进思路，增加伪代码 “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 版 平台服务 平台服务和应用服务分开，模块隔离 新微博引擎，实现 feed cache 分层 关系多维度索引结构，性能极大提高 计数服务改成基于偏移，更高的一致性、低延迟 基础服务 DB 冷热分离等多维度拆分 图片等存储去中心化 动态内容支持多 IDC 同时更新 高性能架构 50,000,000 用户使用新浪微博 最高发表 3,000 条微博 / 秒 姚晨发表一条微博，会被 3,689,713 粉丝读到（11 月 10 日 数据） 问题本质 解决高访问量、海量数据规模下 易于扩展、低延迟 高可用 异地分布能力 每天数十亿次Web及接口请求 请求内容随时变化，结果无法 cache 如何扩展？ 思路 去状态，可请求服务单元中任意节点 去中心化，避免单点及瓶颈 可线性扩展，如 100 万用户，10 台服务器 1000 万用户，100 台服务器 减少模块耦合 实时性 高性能系统具备低延迟、高实时性 实时性核心是让数据离 CPU 最近，避免磁盘 IO “CPU 访问 L1 就像从书桌拿一本书，L2 是从书架拿一本书，L3 是从客厅桌子上拿一本书，访问主存就像骑车去社区图书馆拿一本书。” - 余锋 @ ecug 2010 淘宝网核心系统专家，Erlang技术专家 微博 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 wee