架构师训练营第四周作业

微博：

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

采用的是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流量控制、权限控制