2010年《杨卫华谈微博架构》视频摘抄

这个视频对我来说信息量很大。

2010年11月16日的视频。

视频地址：http://video.sina.com.cn/p/tech/i/v/2010-11-16/232961185323.html

 

1.新浪微博的基层架构也发展了3个大的版本。

2.第一版就LAMP架构，优点是可以非常快的实现我们的系统。仅用一周时间。抢占市场，快速开发、反馈。

3.MPSS，就是多个端口可以布置在同一服务器上，加入有三个模块，则三个模块部署在每个服务器上都有，防止单点故障。

4.微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息存成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。

5.我们把用户分成有效和无效 之后，我们把他们做一下区分，比如说当天登陆过的人我们分成有效用户的话，只需要发送给当天登陆过的粉丝，这样压力马上就减轻了，另外投递的延迟也减小了。

6.key-value是最容易扩展的一种数据。索引数据的拆分具有挑战，比如说一个用户发表了一千条微博，这一千条微博我们接口前端要分页访问，比如说用 户需要访问第五页，那我们需要迅速定位到这个记录。假如说我们把这个索引拆分成一个月一张表，我们记录上很难判断第五页在哪张表里，我们需要加载所有的索 引表。如果这个地方不能拆分，那我们系统上就会有一个非常大的瓶颈。最后我们想了一个方法，就是索引上做了一个二次索引，把每个月记录的偏移记下来 ，就是 一个月这个用户发表了多少条，ID是哪里，就是按照这些数据迅速把记录找出来。

7.发表是一个非常繁重的操作，它要入库、统计索引、进入后台，如果我们要把所有的索引都做完用户需要前端等待很长的时间，如果有一个环节失败的话，用户得到 的提示是发表失败，但是入库已经成功，这样会带来数据不一致问题。所以我们做了一个异步操作，就是发表成功我们就提示成功，然后在后台的消息队列慢慢做完 。

8.第二版我们做了这些改进之后，访问量增加，有很多新的问题出现。比如说系统问题，单点故障导致的雪崩 ，第二个是访问速度问题因为国内网络环境复杂，会有用户反映说在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值，MySql复制延迟 、慢查询，另外就是热门事件 ， 比如说世界杯。

9.我们考虑如何改进，首先系统方面允许任意模块失败 。另外静态内容，第一步我们用CDN来加速 ，另外数据的压力以及峰值，我们需要将数据、功能、部署尽可能的拆分 ，然后提前进行容量规划。

10.开放平台的需求是有差异的，Web系统它有用户行为才有请求，但是API系统特别是客户端的应用，只要用户一开机就会有请求，直到他关闭电脑这种请求一直会不间断的过来，另外用户行为很难预测。

11.Google首席科学家讲过一句话，就是一个大的复杂的系统，应该要分解成很多小的服务 。比如说我们在Google.com执行一个搜索查询的话，实际上这个操作会调动内部一百多个服务。

12.我们第三版的考虑就是先有服务才有接口最后才有应用 ，我们才能把这个系统做大。基础服务里面有分布式的存储，我们做了一些去中心化、自动化的操作。在基础服务之上有平台服务，我们把微博常用的应用做成各种小的服务。然后我们还有应用服务，这个是专门考虑平台各种应用的需求。最上面我们有API，API就是新浪微博各种第三方应用都在上面跑。

13.平台服务和应用服务是分开的，这样实现了模块隔离 ，另外我们把微博的引擎进行了改进，实现了一个分层关系。用户的关注关系，我们改成一个多惟度的索引结构，性能极大的提高。

14.基础服务DB冷热分离多维度拆分 ，在微博里面我们是按照时间拆分的，但是一个大型的系统里面有很多业务需要有不同的考虑。比如说私信这个就不能按照时间来拆分。动态内容支持多IDC同时更新，这个是在国内比较新颖的。

15.我们的模块设计上要去状态，我们任意一个单元可以支持任意节点。另外是去中心化，避免单点及瓶颈。另外是可线性扩展。最后一个是减少模块 。

16.我们看淘宝核心系统专家余锋说过的一句话“CPU访问L1就像从书桌拿一本书，L2是从书架拿一本书，L3是从客厅桌子上拿一本书，访问主存就像骑车去社区图书馆拿一书”。

17.给大家一个很重要的经验分享，就是说监控的指标尽量量化。比如说他延迟30秒是小问题，如果是延迟10分钟我们就要立即采取措施了，就是所有可以量化的指标都要量化。

18.尽可能的将一些运作自动化 。比如说发布安装、服务、启用、停止。

19.一款理想的分布式存储产品它有哪些需求呢？首先它要支持海量规模、可扩展、高性能、低延迟、高可用。第二个是需要多机房分布，能够满足国内负责的网络环境，还要具备异地容灾能力。第三个就是要调用简单，具备丰富数据库特性。因此分布式存储需要解决一个多对多的数据复制。

20.复制策略，Multi-Master方案 ，它需要应用避免冲突，就是我们不能多处改变。这个对于微博来说不会特别难，我们的用户通常只会再一个地方发表微博，用户不会同时在广州又在北京发表或者是修改自己的资料，这样的话我们应用上就已经避免了这种情况。

21.我们前端应用将数据写到数据库，再通过一个消息代理，相当于通过我们自己开发的一个技术，将数据广播到多个机房。

22.高并发的长连服务器。

23.垃圾信息我们的实时拦截可以做到50%的防止，离线分析大概可以做到40%的防止。

24.离线分析：有一个日志处理器，我们会根据一些行为进行判断是否是广告和垃圾信息。

25.架构很多地方是相通的。我们需要做一个软件系统需要解决的本质问题是什么 ？

学到了很多。