【转】构建可扩展的微博架构(qcon beijing 2010演讲) by Tim Yang

在使用Twitter几年的时间里面，常常思考微博如何更好的实现，刚好最近几个月也参与了相关工做，大部分都是工程实践，总结实践会促生更具实际价值的理论。所以在QCon Beijing 2010此次演讲参考了很多网友的意见后选择了《构建可扩展微博架构》的题目。  
因为在决定选题时知道来自Twitter总部有30万followers的@nk也会讲一个相似的题目，心中当时有点忐忑，最大的顾虑就是要讲的领域更他重叠，若是他讲得更深刻，我就不必班门弄斧了。后来考虑到如下几个缘由仍是决定继续

• Twitter架构是单IDC设计，从它递增的tweet id就能够看出，后来当面向@nk提问也获得了证明。

• 中美网络环境差别，单IDC和多IDC有不少设计上的不一样

• 大部分参会人员未必能对英文演讲有深刻理解及感悟，中文的演讲能够讲一些细节解释更透彻。

• Twitter对故障的容忍度大，国内公司对服务故障一般更敏感。所以国内架构师会考虑设计方案尽可能简单可靠，服务须要更稳定。国外开发团队更倾向追求在工做中应用技术创新，所以会致使架构设计理念的很多差别。

演讲的slide以下，登陆slideshare以后能够下载。

Build scalable microblog qcon beijing 2010

View more presentations from Tim Y.

这里再补充在qcon演讲将来得及考虑成熟的一个方面，用户规模影响设计，具体是指用户数每上一个数量级，许多设计须要从新考虑。

10万用户级别

• 单服务器，前端、后端、cache、db在一块儿。

百万级

• db和cache单独部署服务器，db或按业务进行拆分(sharding)

• cache或使用一致性hash扩展。

• 前端后端仍是在一块儿，可是根据业务拆分，每一个业务可分配不一样数量的服务器

千万级

• 开始重视架构设计，有专门技术架构师

• 需跨机房部署，前端在远程增长反向代理加速，数据库在异地机房使用slave数据库副本

• 后端拆分出来，系统内部须要远程调用，内部需远程调用协议。

亿级

• 架构更细分，或增长数据架构师，cache架构师，分布式架构师

• 数据库sharding碰到烦恼，开始考虑分布式数据服务

• 数据访问须要根据业务特色细分。

• 开发、运维、测量、调优具有有本身的专有工具。

• 全部服务须要地理多机房分布，具有IDC容灾设计。

• 服务可降级

上面的数字仅供理解“用户规模影响设计”，数字自己并没有具体指导价值。