演讲者TimYang专题培训.pptxVIP

演讲者@TimYang微博架构与平台安全

微博架构发展

新浪微博从0~50,000,000顾客技术架构经历了3个阶段

第1版

技术特点微博本质是处理刊登/订阅问题第1版采用推消息模式，将刊登/订阅简化成insert/select问题

技术细节经典LAMP架构MySQL：单库单表,MyISAMMPSS(Multi-PortSingleServer)

迅速成长顾客迅速增长出现刊登延迟现象，尤其是明星顾客

架构演变分发推送是造成刊登延迟首因模式改善数据规模增大也带来一定延迟规模增大：数据拆分锁表问题：更改引擎刊登过慢：异步方式

第2版

投递模式优化推模式改善，不需要推送到全部顾客存储及刊登峰值压力减轻投递延迟减小

数据拆分优先按时间维度拆分内容和索引分开存储内容使用key-value方式存储(NoSQL)索引因为分页访问，拆分有挑战

异步处理刊登异步化刊登速度及可靠性得到提升使用MemcacheQ增长statsqueue，适合大规模运维

技术细节InnoDB引进，防止锁表烦恼PHP中libmemcached替代memcache在高并发下稳定性极大提升

高速发展系统问题单点故障、“雪崩”访问速度，国内复杂网络环境数据压力及峰值MySQL复制延迟、慢查询热门事件微博刊登量，明星评论及粉丝

怎样改善系统方面允许任意模块失败静态内容CDN加速数据压力及峰值将数据、功能、布署尽量拆分提前容量规划

平台化需求Web系统有顾客行为才有祈求API系统轮询祈求峰值不明显顾客行为极难预测

系统规模连续增大平台化需求新旳架构怎样设计？

“Breaklargecomplexsystemsdownintomanyservices...searchtouches100sofservices(ads,websearch,books,news,spellingcorrection...)”-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是从客厅桌子上拿一本书，访问主存就像骑车去小区图书馆拿一本书。”-余锋@ecug2023淘宝网关键系统教授，Erlang技术教授

微博cache设计

高可用好旳架构具有高可用性业界AmazonS3:99.9%AmazonEC2:99.95%Facebook:n/a微博平台~99.95%(5小时/年)

怎样到达容量规划图表监控及admissioncontrol...接口及资源监控,7x24业务回环测试,监测业务逻辑有效性集成测试

图表经过图表了解系统容量

接口监控curl/各地祈求情况及响应时间流量异常/accesslognon-200成果/失败率/exceptions将监控指标量化类似mysqlsecondsbehindmaster

“Manyservicesarewrittentoalertoperationsonfailureandtodependuponhumaninterventionforrecovery,about20%ofthetimetheywillmakemistakes.Designingforautomation.”-JamesHamilton,VPofAmazon

自动化大规模互联网系统运作需要尽量自动化公布及安装服务启用、停止故障处理前提，去状态化，允许单点故障及重启

“S