美丽说的架构发展

与变迁

演讲者：⺩王曦

Copyright  ©2012  Meilishuo.com  

1

  故事，是这样开始的…

2

 

2009年11月，我们有了⼀一个想法

⽤用最⽜牛逼的技术，

帮助⼥女孩⼦子变漂亮

3

在一个居民楼里开始了我们的旅程

北京海淀区华清嘉园2号楼905

4

美丽说：Connect  woman  and  all  beau<ful  things

•  美丽说是中国最大的女性时尚购物社区  •  我们是帮助女孩子变漂亮的地方  •  我们的目标用户是5000万的白领和准白领女性  •  从第一天起，我们帮她们解决“怎么穿？哪里买”的问题    •  我们用最好的互联网技术重塑女性时尚行业  •  我们是时尚女  +  技术男  =  Zara  +  Apple  

•  我们带给女孩子最美的自己，我们拥抱中国时尚行业成长  

5

浏览器插件：快速验证了用户需求

•  IE浏览器插件 •  获取⽤用户正在浏览的⺴⽹网址 •  整合⼀一个聊天室的功能 •  可以现实商品的图⽚片、描述、价格等信息

•  ⼏几⼗十个试⽤用⼥女孩⼦子 •  让⼥女⽣生上班的时候也有逛街的感觉

•  ⼏几周内迅速⽕火爆 •  ⼥女孩⼦子是有需求的

6

7

终于决定做网站了

•  当时的产品被定位成⼀一个“垂直的微博” – 开源还是⾃自⼰己写代码？

•  ⼀一切决策来源于时间 点的要求

•  开源的其实还挺好⽤用的 •  最终还是决定⾃自⼰己来写J

8

9

开始于LAMP

•  10年1与到10年3月，2个月的开发时间

•  纯LAMP架构 •  Insert/select的结构维护各种关系

•  没有使⽤用Memcache等技术

•  基于正则表达式的爬⾍虫

10

PHP

MYSQL  商品 图片 用户 关系

APACHE

Linux

第一个问题出现了

•  图⽚片太多了，⼀一台服务器放不下 •  考虑硬盘损坏的问题，图⽚片⻓长期放在⼀一个机器上⾯面也不保险，需要有冗余

•  解决⽅方法其实有很多种，但是我们选择了最悲剧的⼀一种： – ⽐比如NFS – ⽐比如TFS – 但是我们选择了moose FS……

11

第一次架构演化

12

APACHE

PHP

MYSQL

MEMCACHE

SQUID

APACHE（静态文件）

mooseFS文件系统(mount)

SPHINX

mooseFS  MASTER

mooseFS SLAVE mooseFS SLAVE mooseFS SLAVE

出现问题

•  Moose fs Master 只能有⼀一台 •  Moose FS master使⽤用内存来维护⽂文件索引，⼀一个机器的内存只有8G，moose FS⾃自⼰己就⽤用了9G，系统变得很慢

•  ⽤用户访问⽂文件的时候会卡死 •  从⽽而导致moose FS master死机 •  死机后恢复内存索引要若干⼩小时 •  然后继续出问题

13

第二次架构演化

14

APACHE

PHP

MYSQL

MEMCACHE

Nginx

MEMCACHE+FASTCGI

SPHINX

mlsDB  把碎片文件存储成若干

个大的文件

SQUID

APACHE

静态文件  CSS+JS

Happy  Problem

•  ⽤用户的发⾔言每天越来越多，数据表达到上亿⾏行 •  ⼩小红⼼心是⽤用户表达的⼀一种重要⼿手段，⾼高峰时段会出现写瓶颈

•  ⽤用户快速增⻓长，⽤用户的关系数据也越来越多，SELECT/INSERT的⽅方法获取⽤用户TIMELINE效率极低，经常卡死数据库

15

解决方法

•  MYSQL中间层-数据托管服务的出现（内部代号：STORAGE)

•  使⽤用Redis存储⽤用户的Timeline数据 •  使⽤用Redis存储⽤用户的⼩小红⼼心表达 •  使⽤用Redis存储⽤用户和⽤用户直接的关系 •  异步的⽅方式写回数据库，保存数据完整性

16

第三次架构演化

17

NGINX

FASTCGI

数据库A

MEMCACHE

SPHINX

REDIS

STORAGE

REDIS

数据库B_1 数据库B_2

数据库B_3

稳定性和访问速度变得很重要

•  系统问题  – 单点故障问题  – 国内复杂的网络环境  – 内网带宽竟然不够了！  

•  整站依然经常崩溃  – 慢SQL查询，造成数据库卡死  – 问题代码上线后会导致整个系统崩溃  

•  出现问题后很难快速定位问题并解决  

18

解决方法

•  买了很多服务器  •  网络设备上面千万不能马虎

，一定要用IDC使用的专业设备（背板带宽很重要）  

•  使用CDN提供图片服务，主IDC只做数据源  

•  使用脚本野蛮绞杀运行时间超过5S的SQL  

•  重新思考我们的架构，如何更加稳定？  

•  希望通过SOA的方法来给服务解耦合  

19

2012年1月设计的一张架构设想图

20

第四次架构演化

21

     API

PHP前端àNode.JS 无线API

小红心 用户管理 消息读写 用户关系 私信

评论                

基础服务

Redis代理

Cache代理

并发代理

       

平台服务

数据库 Storage

图片服务  图片数据源

搜索 队列 爬虫

图片处理 九宫格服务 ANTI-­‐SPAM

前后端彻底分离

22

Node.js前端

   

 

PHP  API

•  从前在一起的时候，使用的是传统的MVC结构，前端其实就是指：JS+CSS+Smarty模板部分。J

•  后来我们把他们分开了，变成了前端+API的形式 •  新前端使用node.js，一个最大特点就是：支持事件驱动（并

发） •  前端分开以后，前端和后端可以分开上线 •  后端更focus在数据逻辑、数据流转和数据处理上面 •  前端更focus在客户端逻辑和性能上面

数据可以并发获取

23

请求一

请求二

请求三

请求四

请求五

24

九图合一

25

九宫格服务

ANTI-­‐SPAM

•  WEB2.0注射很烦⼈人，美丽说⼯工程师很⽣生⽓气  •  刷排名  •  注册用户  •  广告信息  •  黄反信息  

26

ANTI-­‐SPAM模块 NGINX日志 前端

27

多地IDC的实现

28

                               

本地机房

MYSQL  master

                               

外地机房

MYSQL  master

Redis代理

Redis代理 Redis写队列

Redis写队列

其他几点经验分享

•  监控很重要，要尽早做  – 服务的存活  – 硬盘空间  – 内网的带宽  

•  最初的方法简单可依赖就行，不要追求架构完美  

29

关于技术团队 •  创业公司技术团队的特点：

– ⼈人员年轻，缺乏经验 – ⼤大家有热情，干劲⼗十⾜足

•  着重培养有潜⼒力的⼈人，某⼀一⽅方⾯面的技术专家很重要 •  有进步要⿎鼓励、有错误要惩罚，切忌拔苗助⻓长 •  极致细节，培养责任感 •  明确时间点和优先级 •  尽量缩短项⺫⽬目的周期 •  Leader⼀一定要多读⼯工程师的代码，及时发现问题及时指正

30

⼀一些数据分享

•  2009年11月，6个⼈人的公司 •  2009年12月，浏览器插件上线 •  2010年3月8⽇日⺴⽹网站正式上线 •  2011年10月，流量和⽤用户爆发式增⻓长 •  2012年11月，美丽说整整三年

•  3亿 Request/天 •  ⾼高峰时段：5000 Request/秒 ，21点-23点 •  300万⼩小红⼼心/天 •  200万⽤用户分享/天

31

32

Q  &  A

33

谢谢⼤大家