[WeiDesign]微博计数器的设计 velocity

06 Dec 2012

非常感谢@NinGoo 的邀请, 昨天在 #Velocity中国大会# 上做了一个分享: 微架构设计之微博计数器服务, 主要讲的内容还是微博计数器的设计思路, 但是侧重点方面和之前的Blog略有区别.

Blog侧重更细节的一些优化和考量,因为大家可以有更多的时间 和我来做资源计算的算术题. 技术交流的时候相对来说稍微宏观一些, 随着产品的发展, 架构一路遇到了哪些挑战, 都是如何思考,如何解决的…

会议当时的Keynote下载(相关的视频@Velocity中国大会 应该正在制作,稍后也会放出来):

Velocity分享_微架构设计之微博计数器服务_杜传赢_20121205.pdf

关于服务优化这一块, 我在会场表达的主要意见是:

• 虽然我讲了很多优化的小技巧和思路, 但是并非鼓励大家去盲目优化. 除非他真的有必要. 我非常赞同”最好的优化就是不优化”, “优化是万恶之源”的观点.
• 听过我讲的同学应该能够体会到, 我们一路走来都是尽可能地在延迟优化:
  • 产品上线初期, 甚至不在Feed页中提供计数功能(有更加重要的功能待开发)
  • 前期直接通过mysql搭建, 甚至使用更好的硬件(FusionIO)去支撑
  • 虽然想到了value block和key prefix的压缩思路,但是线上还是没有实现(目前的优化已经基本够用)

Marx描述共产主义的场景时说”共产主义社会中,物质极大丰富”, 这其实是一个极端悲剧的场景.

• 因为能量只能按照一个方向转化,”物质极大丰富”的时候就意味着”能量被极大地消耗”.
• 我们追求的应该是能量的充裕,因为能量可以转化为物质, 反过来却不行.

熵与能量守恒这篇文章应该讲得更加清楚.

类比到系统优化上, 也是一样的道理.

• 我们追求的是能量的充裕(系统架构可优化的空间和能力).
  • 当我们有需求(产品需求, 访问量, 数据量倍增…)的时候, 可以将部分能量转化为物质 (某一项优化的实话, 某一个模块的开发上线…)来满足需求.
  • 如果在没有充分需求的情况下, 就做了过多的优化, 那其实是对时间和能量的浪费, 而这些时间和能量本可以用到更加合适和 更加紧迫的地方.

“让系统保持无限的优化想象空间, 但先只实施当前最紧迫最必要的优化!”