美丽说的架构发展与变迁 [复制链接]查看:6215回复:0

1#
ppt下载见附件。

美丽说的架构发展与变迁
演讲者:王曦

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

浏览器插件:快速验证了用户需求
• IE浏览器插件
• 获取用户正在浏览的网址
• 整合一个聊天室的功能
• 可以现实商品的图片、描述、价格等信息
• 几十个试用女孩子
• 让女生上班的时候也有逛街的感觉
• 几周内迅速⽕火爆
• 女孩子是有需求的

终于决定做网站了
• 当时的产品被定位成一个“垂直的微博”
– 开源还是自己写代码?
• 一切决策来源于时间点的要求
• 开源的其实还挺好⽤用的
• 最终还是决定自己来写

开始于LAMP
• 10年1与到10年3月,2个月的开发时间
• 纯LAMP架构
• Insert/select的结构维护各种关系
• 没有使用Memcache等技术
• 基于正则表达式的爬虫

第一个问题出现了
• 图片太多了,一台服务器放不下
• 考虑硬盘损坏的问题,图片长期放在一个机器上面也不保险,需要有冗余
• 解决方法其实有很多种,但是我们选择了最悲剧的一种:
– 比如NFS
– 比如TFS
– 但是我们选择了moose FS……

出现问题
• Moose fs Master 只能有一台
• Moose FS master使用内存来维护文件索引,一个机器的内存只有8G,moose FS自己就用了9G,系统变得很慢
• 用户访问文件的时候会卡死
• 从而导致moose FS master死机
• 死机后恢复内存索引要若干小时
• 然后继续出问题

Happy Problem
• 用户的发言每天越来越多,数据表达到上亿行
• 小红心是用户表达的一种重要手段,高峰时段会出现写瓶颈
• 用户快速增长,用户的关系数据也越来越多,SELECT/INSERT的方法获取用户TIMELINE效率极低,经常卡死数据库

解决方法
• MYSQL中间层-数据托管服务的出现(内部代号:STORAGE)
• 使用Redis存储用户的Timeline数据
• 使用Redis存储用户的小红心表达
• 使用Redis存储用户和用户直接的关系
• 异步的方式写回数据库,保存数据完整性

稳定性和访问速度变得很重要
• 系统问题
– 单点故障问题
– 国内复杂的网络环境
– 内网带宽竟然不够了!
• 整站依然经常崩溃
– 慢SQL查询,造成数据库卡死
– 问题代码上线后会导致整个系统崩溃
• 出现问题后很难快速定位问题并解决

解决方法
• 买了很多服务器
• 网络设备上面千万不能马虎,一定要用IDC使用的专业设备(背板带宽很重要)
• 使用CDN提供图片服务,主IDC只做数据源
• 使用脚本野蛮绞杀运行时间超过5S的SQL
• 重新思考我们的架构,如何更加稳定?
• 希望通过SOA的方法来给服务解耦合

前后端彻底分离
• 从前在一起的时候,使用的是传统的MVC结构,前端其实就是指:JS+CSS+Smarty模板部分。
• 后来我们把他们分开了,变成了前端+API的形式
• 新前端使用node.js,一个最大特点就是:支持事件驱动(并发)
• 前端分开以后,前端和后端可以分开上线
• 后端更focus在数据逻辑、数据流转和数据处理上面
• 前端更focus在客户端逻辑和性能上面

其他几点经验分享
• 监控很重要,要尽早做
– 服务的存活
– 硬盘空间
– 内网的带宽
• 最初的方法简单可依赖就行,不要追求架构完美

关于技术团队
• 创业公司技术团队的特点:
– 人员年轻,缺乏经验
– 大家有热情,干劲十足
• 着重培养有潜力的人,某一方面的技术专家很重要
• 有进步要鼓励、有错误要惩罚,切忌拔苗助长
• 极致细节,培养责任感
• 明确时间点和优先级
• 尽量缩短项目的周期
• Leader一定要多读工程师的代码,及时发现问题及时指正

一些数据分享
• 2009年11月,6个人的公司
• 2009年12月,浏览器插件上线
• 2010年3月8日网站正式上线
• 2011年10月,流量和用户爆发式增长
• 2012年11月,美丽说整整三年
• 3亿 Request/天
• 高峰时段:5000 Request/秒 ,21点-23点
• 300万小红心/天
• 200万用户分享/天


附件 (2012-10-27 11:09:47)

分享 转发