架构师训练营第四周作业

用户头像
lwy
关注
发布于: 2020 年 07 月 01 日

微博:

早期的时候业务简单:发布微博,浏览微博,用户关注,用户的登陆注册等操作。

采用的是php,数据库是单机的mysql,单表单库,apache还有linux。

微博本质是解决发表/订阅问题,第一版采用的是推消息模式,将发表/订阅简化为insert/select问题,insert就是给博主发表了一条微博,然后把这条微博给他的粉丝新增一条记录,这条记录包含粉丝id,这条微博的id,select就是粉丝在刷微博的时候,查询出这些记录。



随着用户快速增加,出现了发表延迟现象,尤其是明星用户。

推模式改进,不需要推送到所有的粉丝,只推送到活跃的粉丝,不活跃的粉丝只需要在他刷微博的时候再推送就可以,这样可以使得存储和发表的峰值压力减小,同时投递延迟也减小;再一个通过异步操作,用到的是消息队列MemcacheQ,这样发表速度和可靠性得到提高,增加了stats queue,适合大规模的运维。



数据规模增大也带来了延迟,比如insert和select操作响应延时会增加,可以通过数据拆分来解决,首先通过时间纬度拆分,其次内容和索引分开存放,热门微博缓存在nosql里,可以减小数据库的压力;把数据库引擎换成了innoDB,避免锁表,根据业务进行mysql的分库分表,读写分离等。



随着业务高速发展,

出现了系统问题:

1.单点故障,‘雪崩’问题

2.访问速度,国内复杂网络环境带来的访问延迟问题

出现了数据压力及峰值:

1.mysql复制延迟、慢查询

2.计数问题:热门事件微博发表量、明星微博的评论数、粉丝数等

改进措施:

系统方面:

1.静态资源通过CDN加速

2.允许任意模块失败

数据压力及峰值:

1.将数据、功能、部署尽可能拆分

2.做好提前容量规划



平台化需求:

将其服务化:服务-接口-应用,应用通过api暴露出来:

平台服务:

1.平台服务和应用服务分开,实现模块隔离

2.新微博引擎,实现feed cache分层

3.关系多维度索引结构,性能极大提高

4.计数服务改成基于偏移,实现更高的一致性、低延迟

基础服务:

1.DB冷热分离

2.图片等存储去中心化

3.动态内容支持多IDC同时更新,减少异地读延迟



解决高可用:

1.通过图表可视化,了解系统容量

2.接口监控:

2.1curl/各地请求情况及响应时间

2.2流量异常

2.3non-200接口/失败率/exception

2.4将监控指标量化

3.自动化

3.1系统运作自动化,自动化工具

4.异地分布需求

4.1静态内容分布采用CDN技术

4.2分布式存储,通过消息广播方式将数据多地分布



接口安全:

1.Auth层:

1.1访问需要AppKey

1.2需要OAuth授权

2.权限层

2.1流量控制、权限控制



发布于: 2020 年 07 月 01 日 阅读数: 177
用户头像

lwy

关注

还未添加个人签名 2019.02.26 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第四周作业