演讲者 TimYang微博架构与平台安全微博架构与平台安全微博架构发展新浪微博从 0 50,000,000 用户技术架构经历了 3 个阶段第 1 版技术特点微博本质是解决发表/订阅问题第 1 版采用推消息模式，将发表/订阅简化成 insert / select 问题技术细节典型 LAMP 架构MySQL：单库单表, MyISAMMPSS (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. google.com 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 lognon-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 SysadminLumeta Corporation总监，贝尔实验室专家微博系统运转依赖大量自动化工具工具在持续改进并增加中 高可用性还有异地分布的需求在国内网络环境下，IDC 灾难、机房检修维护会导致服务中断用户就近访问可提高速度静态内容分布采用 CDN 技术，成熟动态内容分布是业界难点核心是数据的分布式存储理想的分布式存储产品支持海量规模、可扩展、高性能、低延迟、高可用性多机房分布，异地容灾调用简单，具备丰富数据库特性分布式存储需要解决多对多的数据复制同步及数据一致性复制策略Master / Slave实现简单，master 有单点风险Multi-Master合并多处写，异步，最终一致性需要应用避免冲突Paxos：强一致性，延迟大Multi-MasterWeb 应用多地区同步的最佳策略没有现成成熟的产品微博方案通过消息广播方式将数据多地分布类似 Yahoo! Message Broker“We use YMB for replication for 2 reasons.1. YMB ensure msgs are not lost before they are applied to the db.2. YMB is designed for wide-area replication. This isolates individual PNUTS clusters from dealing with update between regions”PNUTS: Yahoo!s Hosted Data Serving Platform新推送架构现状API 大部分请求都是为了获取最新数据重新思考 Rest API大部分调用都是空返回大部分时间在处理不必要的询问无法实时投递存在请求数限制（rate limit）如何解决新一代推送接口(Stream API)采用推送的方式有新数据服务器立即推送给调用方无数据则不消耗流量客户端实现更简单技术特点低延迟，从发表到客户端接收1秒内完成高并发长连接服务推送架构为什么先持久化KISS，Keep It Simple and Stupid测试表明持久几乎不增加延迟开销batch insertcursor read内部细节Stream Buffer保存用户最近数据保存客户端断线重连之间下行数据平台安全由于接口开放，需要防范各种恶意行为垃圾内容垃圾粉丝恶意行为内容安全微博平台需要为用户提供安全及良好体验的应用为开发者营造公平的环境接口需要清晰的权限控制及安全规则接口安全Auth层访问需要 AppKey需要 OAuth 授权权限层流量控制、权限架构就是将复杂问题抽象简单并解决下一代微博架构，期待您的参与Join us! TimYang