搜索
演讲者@TimYang微博架构与平台安全微博架构发展•新浪微博从0~50,000,000用户•技术架构经历了3个阶段第1版技术特点•微博本质是解决发表/订阅问题•第1版采用推消息模式，将发表/订阅简化成insert/select问题技术细节•典型LAMP架构•MySQL：单库单表,MyISAM•MPSS(Multi-PortSingleServer)快速成长•用户快速增长•出现发表延迟现象，尤其是明星用户架构演变•分发推送是造成发表延迟首因•模式改进•数据规模增大也带来一定延迟•规模增大：数据拆分•锁表问题：更改引擎•发表过慢：异步方式第2版投递模式优化•推模式改进，不需要推送到所有用户•存储及发表峰值压力减轻•投递延迟减小数据拆分•优先按时间维度拆分•内容和索引分开存放•内容使用key-value方式存储(NoSQL)•索引由于分页访问，拆分有挑战异步处理•发表异步化•发表速度及可靠性得到提高•使用MemcacheQ•增加statsqueue，适合大规模运维技术细节•InnoDB引进，避免锁表烦恼•PHP中libmemcached代替memcache•在高并发下稳定性极大提高高速发展•系统问题•单点故障、“雪崩”•访问速度，国内复杂网络环境•数据压力及峰值•MySQL复制延迟、慢查询•热门事件微博发表量，明星评论及粉丝如何改进•系统方面•允许任意模块失败•静态内容CDN加速•数据压力及峰值•将数据、功能、部署尽可能拆分•提前容量规划平台化需求•Web系统•有用户行为才有请求•API系统•轮询请求•峰值不明显•用户行为很难预测•系统规模持续增大•平台化需求•新的架构如何设计？•“Breaklargecomplexsystemsdownintomanyservices...google.comsearchtouches100sofservices(ads,websearch,books, news, spelling correction...)”•-JeffDean,GoogleFellow服务化•服务→接口→应用第3版平台服务•平台服务和应用服务分开，模块隔离•新微博引擎，实现feedcache分层•关系多维度索引结构，性能极大提高•计数服务改成基于偏移，更高的一致性、低延迟基础服务•DB冷热分离等多维度拆分•图片等存储去中心化•动态内容支持多IDC同时更新高性能架构•50,000,000用户使用新浪微博•昀高发表3,000条微博/秒•姚晨发表一条微博，会被3,689,713粉丝读到（11月10日数据）问题本质•解决高访问量、海量数据规模下•易于扩展、低延迟•高可用异地分布能力•每天数十亿次Web及接口请求•请求内容随时变化，结果无法cache•如何扩展？思路•去状态，可请求服务单元中任意节点•去中心化，避免单点及瓶颈•可线性扩展，如•100万用户，10台服务器•1000万用户，100台服务器•减少模块耦合实时性高性能系统具备低延迟、高实时性实时性核心是让数据离CPU昀近，避免磁盘IO“CPU 访问L1就像从书桌拿一本书，L2是从书架拿一本书，L3是从客厅桌子上拿一本书，访问主存就像骑车去社区图书馆拿一本书。”-余锋@ecug2010淘宝网核心系统专家，Erlang技术专家微博cache设计高可用•好的架构具有高可用性•业界•AmazonS3:99.9%•AmazonEC2:99.95%•Facebook:n/a•微博平台~99.95%(5小时/年)如何达到•容量规划•图表•监控及admissioncontrol...•接口及资源监控,7x24•业务回环测试,监测业务逻辑有效性•集成测试图表通过图表了解系统容量接口监控•curl/各地请求情况及响应时间•流量异常/accesslog•non-200结果/失败率/exceptions•将监控指标量化•类似mysqlsecondsbehindmaster•“Manyservicesarewrittentoalertoperationsonfailureandtodependuponhumaninterventionforrecovery,about20%ofthetimetheywillmakemistakes.•Designing for automation.”•-JamesHamilton,VPofAmazon自动化•大规模互联网系统运作需要尽可能自动化•发布及安装•服务启用、停止•故障处理•前提，去状态化，允许单点故障及重启•“SystemadministrationatGoogleusuallyhave1weekofoncallduty,andtheother5weeksarespentmakingimprovementstomaketheoncallportionmoreoptimized,automated,andtrouble-free”•-TomLimoncelli@EverythingSysadmin•LumetaCorporation总监，贝尔实验室专家微博系统运转依赖大量自动化工具工具在持续改进并增加中⋯⋯•高可用性还有异地分布的需求•在国内网络环境下，IDC灾难、机房检修维护会导致服务中断•用户就近访问可提高速度•静态内容分布采用CDN技术，成熟•动态内容分布是业界难点•核心是数据的分布式存储•理想的分布式存储产品•支持海量规模、可扩展、高性能、低延迟、高可用性•多机房分布，异地容灾•调用简单，具备丰富数据库特性分布式存储需要解决多对多的数据复制同步及数据一致性复制策略•Master/Slave•实现简单，master有单点风险•Multi-Master•合并多处写，异步，昀终一致性•需要应用避免冲突•Paxos：强一致性，延迟大•Multi-Master•Web应用多地区同步的昀佳策略•没有现成成熟的产品微博方案•通过消息广播方式将数据多地分布•类似Yahoo!MessageBroker•“WeuseYMBforreplicationfor2reasons.•1.YMBensuremsgsarenotlostbeforetheyareappliedtothedb.•2.YMBisdesignedforwide-areareplication.ThisisolatesindividualPNUTSclustersfromdealingwithupdate between regions”•PNUTS: Yahoo!’s Hosted Data Serving Platform新推送架构现状•API大部分请求都是为了获取昀新数据•重新思考RestAPI•大部分调用都是空返回•大部分时间在处理不必要的询问•无法实时投递•存在请求数限制（ratelimit）如何解决•新一代推送接口(StreamAPI)•采用推送的方式•有新数据服务器立即推送给调用方•无数据则不消耗流量•客户端实现更简单技术特点•低延迟，从发表到客户端接收1秒内完成•高并发长连接服务推送架构•为什么先持久化•KISS，KeepItSimpleandStupid•测试表明持久几乎不增加延迟开销•batchinsert•cursorread内部细节•StreamBuffer•保存用户昀近数据•保存客户端断线重连之间下行数据平台安全•由于接口开放，需要防范各种恶意行为•垃圾内容•垃圾粉丝•恶意行为内容安全•微博平台需要•为用户提供安全及良好体验的应用•为开发者营造公平的环境•接口需要清晰的权限控制及安全规则接口安全•Auth层•访问需要AppKey•需要OAuth授权•权限层•流量控制、权限•架构就是将复杂问题抽象简单并解决•下一代微博架构，期待您的参与•Joinus!@TimYang