在使用Twitter几年的时间里面，经常思考微博如何更好的实现，恰好最近几个月也参与了相关工作，大部分都是工程实践，总结实践会促生更具实际价值的理论。因此在QCon Beijing 21010年在参考了不少网友的意见后选择了《构建可扩展微博架构》的题目。
由于在决定选题时知道来自Twitter总部有30万followers的@nk也会讲一个类似的题目，心中当时有点忐忑，最大的顾虑就是我要讲的他全部覆盖了，而且讲得更深入，我就没必要班门弄斧了。后来考虑到以下几个原因还是可以继续
Twitter架构是单IDC设计，从它递增的tweet id就可以看出，后来当面向@nk提问也得到了证实。中美网络环境差异，单IDC和多IDC有很多设计上的不同大部分参会人员未必能对英文演讲有深入理解及感悟，中文的演讲可以讲一些细节解释更透彻。Twitter对故障的容忍度大，国内公司对后端故障通常更敏感，国内公司会更追求尽设计尽量简单，服务需要稳定。国外开发团队更倾向追求在工作中应用技术创新。因此会导致架构设计理念的不少差异。演讲的slide如下，登录slideshare之后可以下载。
Build scalable microblog qcon beijing 2010View more presentations from Tim Y.
这里再补充在qcon演讲未来得及考虑成熟的一个方面，用户规模影响设计，具体是指用户数每上一个数量级，许多设计需要重新考虑。
10万用户级别
单服务器，前端、后端、cache、db在一起。百万级
db和cache单独部署服务器，db或按业务进行拆分(sharding) cache或使用一致性hash扩展。 前端后端还是在一起，但是根据业务拆分，每个业务可分配不同数量的服务器千万级
开始重视架构设计，有专门技术架构师 需跨机房部署，前端在远程增加反向代理加速，数据库在异地机房使用slave数据库副本 后端拆分出来，系统内部需要远程调用，内部需远程调用协议。亿级
架构更细分，或增加数据架构师，cache架构师，分布式架构师 数据库sharding碰到烦恼，开始考虑分布式数据服务 数据访问需要根据业务特点细分。 开发、运维、测量、调优具备有自己的专有工具。 所有服务需要地理多机房分布，具备IDC容灾设计。 服务可降级上面的数字仅供理解“用户规模影响设计”，数字本身并无具体指导价值。
另外在slide中也提到了，目前新浪微博团队急需人才，对上面相关技术领域感兴趣的架构师及各层次开发人员(熟悉PHP，Java, C或数据架构任意一种)可随时跟我联系，工作地点为北京，联系方式见博客首页。