nice服务端架构演进

程㭎 2014-11-23

基本数据

• 5亿 reqs/day • 6000w photos total • 55w photos/day • 6% growth/week

All of this happens in 12 months

2013.9:

All of this happens in 12 months

2014.10

第⼀一次演进

时间：2013.11下旬 问题：流量增⻓长，单机器瓶颈出现 解决⽅方案： 1. 从托管服务器到云(qingcloud) 2. 从⾃自⼰己抗图⽚片访问到图⽚片云存储+CDN(qiniu)

第⼀一次演进（13.11）

• ⼏几⼗十万PV/天 • ⼏几千张照⽚片/天 • VM功能尽量合设 • 配置最⾼高的VM:4核16G

第⼆二次演进

时间：2014.3 问题：主库机器压⼒力过⼤大 解决： 1. 机器按照功能拆分，主库拆出来 2. 做基本容灾备份

第⼆二次演进（14.3）

• 上千万PV/天 • 上万张照⽚片/天 • 主库拆到单独机器 • 引⼊入了LB/Redis/Beanstalk • 使⽤用了Mysql Proxy

第三次演进

时间：2014.7 问题： 1. 单instance到达可分配资源的上限（8核32G） 2. 单机房的也很快要到达资源上限 解决： 1. 双机房 2. 容灾和备份

第四次演进

时间：2014.9 问题： 1. Mysql index⼤大⼩小超过32G，导致slow query暴增 2. 双机房互联不稳定，导致经常出现数据不⼀一致 3. 天天加班处理线上问题，不能回家陪⽼老婆 解决： 1. 从qingcloud迁移到托管服务器 2. 从双机房回归到单机房

第四次演进（14.9）

Best practices

• 天下武功，唯快不破

That’s all.