『九个月实现破亿用户的可扩展架构』学习笔记

昨晚把美拍架构负责人洪小军在Qcon上的『九个月实现破亿用户的可扩展架构』分享看了一遍(其实那场QCon我也在现场,但是当时小军这个会场实在太多人了,而且当时北京还没开空调又热又闷,所以我就挑了个凉快的会场去听了哈哈),感觉有不少值得学习的地方,在这里记录一下,强烈建议大家把视频从头到尾看一遍,不要只看ppt。尤其是身在创业公司且公司业务发展速度比较快的同学。

总的一个中心思想是在不同阶段选择最适合自己的方案。这句话说起来简单,但是背后的各种辛酸泪以及血的教训只有亲历者才能理解了。下面我们从各个角度分别来看一下。

对了,忘了说一个前提了,美拍从上线到发展到一亿用户只经历了短短几个月的时间,在这业界应该是没有几个先例的,这也是前面为什么说一定要仔细看看。另外说个八卦,据说美图的第一个后端开发(也是唯一的一个)在刚上线时连续三天没回家...

首先先从架构上来说,看下美拍经历的几个阶段:

  1. 极简化设计(快速发布上线)
  2. 保持简单行设计(产品快速迭代)
  3. 可扩展和高可用保证(用户量到一定量级)
  4. 高可扩展和高可用保证

然后我们来看下美拍一路走来遇到的问题:

  1. MySQL慢查询
  2. MySQL写入瓶颈
  3. redis超时
  4. memcached命中率奇低
  5. 服务相互依赖
  6. 监控报警不稳定
  7. CDN服务各种故障
  8. 添加字段成本高
  9. 量级上来后,MySQL继续慢

然后,我们按服务维度把每一个服务拆开,看下每一个服务在美拍架构上的迭代过程。

一、MySQL

MySQL是最重要的一个服务,在美拍架构里经历了多次迭代。在第一版直接就是一个实例,为了保持代码的简单,业务逻辑能在数据库里做的都放到数据库做了,比如Feed功能,直接用MySQL的join查询。

但是后来就出现了一些慢查询的情况,这时候做了主从,做读写分离,多个从库用来做查询。再到后来出现写入也慢的情况,这时候也没有做架构上的优化,而是升级硬件,因为现在正是业务高速发展阶段,需要极简化设计,这个阶段更多精力要放在业务开发上(估计当时也木有招到合适的人:))。

过了一段时间又开始出现写入慢的情况,这时候才开始做分表。但是等到了重心放在扩展性和可用性上时,又遇到了新的问题,一个很大的问题还是写入慢,另外一个就是随着数据量的增大,添加字段成本特别的高。针对这两个问题做了下面两个方案:

  1. 异步写入,做到前端永远可写,后面复杂的事情放到队列里面去异步的做
  2. 索引和数据分离,把需要索引的字段单独拆出来一个表,其他数据用kv存储,value就是所有属性和值的pb二进制数据,解决家字段困难的问题

这个时候针对MySQL的架构优化才告了一段落 :)

二、缓存

缓存主要用到了memcache和redis(redis应该主要是用在队列和计数服务)。在量比较小的时候就是简单粗暴的用,但是很快就遇到了redis超时的问题,这时候对redis扩容,使用多slave架构。然后是rdb dump时影响用户请求的问题,解决方法一是在凌晨访问量低的时候才去dump,二是用不对外服务的机器来做dump。

然后memcached遇到了命中率很低的问题,一个大问题就是容量瓶颈,这没啥好说的,扩容(小军有提到,要随时做好扩容的准备)。另外一个就是slab calcification的问题(又叫slab钙化问题,这个是memcached的内存分配机制导致的,简单来说就是memcached会内存分成N个slab,当新添加一个内存对象时会根据这个对象的大小来选择不同的slab,如果没有合适的就会创建一个slab,那如果这时候剩余内存不足以分配一个slab呢?这时候就出现了钙化问题了),美拍当时的解决办法是核心业务隔离部署,避开这个问题。

到可用性保证阶段,缓存的可用性就更加的非常的重要了,缓存挂了可能就整个系统都挂了,很难收场,所以就要保证缓存的可用性。这时候做了主从的优化,master也承担读查询,以保证缓存热度,slave穿透到master,master穿透到slave,防止单点故障。

三、运维

在初期只是简单的监控告警,有时候出问题了可能收不到告警或者看不到是啥地方出问题,后来逐渐完善监控告警,且监控告警是用配置比较高的服务器,保证监控告警的可用性。然后假如更多监控维度和更多日志,方便定位问题。对依赖的第三方服务和资源做开关,出问题时可以通过服务的开关保证核心路径可用

四、第三方服务

主要提到的是CDN服务。其中一个很大的问题就是DNS被攻击、被劫持,除了和运营商保持沟通外,还做了多服务商配合的策略,比如同样的数据在多个云服务那里做冗余,客户端在访问时如果出现问题就切换到其他的访问地址,并且在客户端做了服务端可用性探测。这也是个非常有价值的经验。

五、技术栈

整个看下来会发现美拍的架构做的非常的稳,小军也有提到,在项目初期高速发展阶段做架构时要克服对完美架构的欲望、克服对新技术的欲望,先让系统跑起来。

但是在整个迭代过程中,美拍也一直在引入新技术,比如在团队不太熟悉时先在部分业务上使用MongoDB,在注重可扩展和可用性阶段,引入java做业务逻辑,引入c做底层基础服务。


通过这个分享可以学习到一个系统从0到亿的架构迭代过程,但是更多的还是在于实践,估计美拍走过的坑也远不止小军分享里提到的这些,每一个点都可能出现N多的问题,每个点都可以展开很多话题来讲。希望能看到更多类似的有价值的分享!

原文发布于微信公众号 - 马哥Linux运维(magedu-Linux)

原文发表时间:2015-07-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏北京马哥教育

游族网络运维总监:如何运维千台以上游戏云服务器

? 作者:李志勇 来源: http://www.csdn.net/article/2016-03-21/2826611 偶然在网上看到游族网络运维总监李志勇先...

75780
来自专栏Rainbond开源「容器云平台」

微服务的误读与误解

16450
来自专栏程序你好

微服务(Microservices)集成原则

在微服务的诸多优势中,最重要的动机是业务单位的规模和自主权。然而,我们仍然需要创建一个对最终用户有意义的集成体验。在为微服务之间的交互开发策略时,记住这两个目标...

15430
来自专栏智能计算时代

工业物联网体系架构

整体架构 ? IoT设备组件 ? 硬件抽象层 为了确保便携性,IoT设备需要包括一个软件层,可以访问MCU的硬件功能,如闪存,GPIO,串行接口等。 提供高级A...

62580
来自专栏北京马哥教育

面向容器技术资源调度关键技术对比

摘要:本文以资源分配理念:拍卖、预算、抢占出发,引出Borg、Omega、Mesos、Kubernetes架构、数据、API的特点比较。然后梳理资源共享各种不同...

44370
来自专栏腾讯大数据的专栏

HBase在腾讯大数据的应用实践

前言随着腾讯产品与技术的发展,几乎任何一个与用户相关的在线业务的数据量都在亿级别,每日系统调用次数从亿到百亿,对海量数据的高效插入和快速读取变得越来越重要。而传...

37660
来自专栏哲学驱动设计

《架构师》反思:系统可靠性

最近系统学习了一个系统可靠性及其相关知识,今天在这总结一下。 首先,什么是系统的可靠性呢?系统的可靠性是指在规定的时间内及规定的环境下完成规定功能的能力,也...

41050
来自专栏风中追风

如果进入CPU的世界,时间会是怎样的?

不知道大家有没有感觉每天写代码的时间过得很快啊,有时候一天过去了一个功能还没完成,但是时间就这么没了!

35490
来自专栏互扯程序

IaaS,PaaS和SaaS,QPS,RT和TPS,PV,UV和IP到底是什么意思?

今天我们来讲讲什么是云服务,云计算的三种服务模式有哪三种,我们经常评估服务的性能指标都有哪些,分别是什么意思,平时“那些人”说的QPS是什么,TP是什么,日活又...

27930
来自专栏SEO

Google新动作:处理重复内容

356100

扫码关注云+社区

领取腾讯云代金券