昨天我们分享了【海量服务之道】中【大系统小做】的基本理论，今天我们将结合QQ相册系统设计实战,让大家由浅入深的感受这一理论如何指导互联网后台系统的建设。
- QQ相册亿级存储系统设计（简介）
现今QQ相册存储系统已经达到百P级别存储，千亿图片数量，每天上下行图片数亿级别，设备数量达到万级别，是一个庞大的海量存储系统。如此大规模的系统，它应该是如何构建的，关键思想有哪些？
首先任何一套系统都是从无到有，从小规模小功能到大规模复杂功能，不断演进的过程。反之也是，任何一套大系统，它都应该是由一些小系统组合而成的，层次分明。也既是海量服务之道非常重要的思想之一—大系统小做。
什么是大系统小做？当设计功能复杂较大系统的时候，应当遵循分而治之，化繁为简，化大为小，高内聚低耦合的原则，用多个独立的模块来实现整体系统的功能。
那么，相册系统是如何体现这样的思想的？
首先假设一个相册的最小规模组成：拉相册列表（ListAlbum）+拉图片列表（ListPhoto）+下载图片（图片url）+上传图片
以上系统使用数据库和文件系统存储，最基本的读写。
假如这套系统都揉合在一起，部署单机器（可平行扩展），功能也在此叠加会怎样？
首先随着量级别的递增，会暴露很多问题。一是资源出现分歧，大量的图片上下行导致磁盘io成为最大瓶颈，其它资源（cpu，内存，带宽）都极大浪费；二是负载均衡无法控制，用户的活跃度不同；三是容错，任何一个地方出问题会影响整套系统。
其次相册功能会不断增加，包括图像需要多种尺寸、高清原图、敏感图片、回收站等。每种功能增加带来的消耗不一样，可能是逻辑复杂，可能是运算复杂，或者机器消耗等，比如图像处理，需要消耗大量的cpu，如果与现有功能耦合，那么cpu的大量消耗会影响图片的其它功能。功能的增加没有分类而是混在一起，会导致无法扩展和运维。
可以说如果系统没有合理设计，那么整套系统会牵一发而动全身，在不断庞大中失控。这就要求系统设计时遵循大系统小做，分而治之的思想。
大系统小做应该怎么做？最简单的说法就是面向对象的思想，不断分层分解，形成各种子零件。比如宜家家具，有各种材质不同形状的零件，你需要一张桌子，可以选择木板+钢腿，也可以选择钢板+木腿等等，看具体的需求而定。
那么相册系统应该如何体现？相册是一个大访问量，大数据量存储，功能复杂的系统，可以用分层次，和逐层分解的方法。
模型：高读高写大存储，高读低写小存储等。
系统的模型要定位清楚，决定了软件选型，设备选型，层次分解，模块分类等。比如游戏类和存储类就完全不一样。相册属于高读高写存储类型，需要支撑高吞吐量访问和大规模存储，那么就需要高吞吐软件，不同类型的存储设备等。
层次：接入，逻辑，缓存，数据，外围等。
不同层次解决不同的问题，比如接入，只负责请求接入，调度，很轻量级但承载的量非常大，这一层可以让前端与后端解耦，后端可以无限扩展；逻辑层则更多做具体的功能，比如登录校验，图像做处理等，这类往往在逻辑或运算上比较重。
功能：事务管理，图像压缩，读写分离，冷热分离，调度，信令，数据存储，运营等
功能要细分，模块独立，不同消耗，只需要提供相应的接口，相互之间组合。比如事务管理图像压缩不能混在一起，图像压缩会非常占用cpu，大量cpu运算使得事务管理无法进行，导致响应慢。
设备：cpu强，内存大，磁盘大等
不同的设备满足不同的需求，没有一种万能的机型，需要根据实际情况而定。如图像处理类机器，需要高cpu，小磁盘；数据存储类需要低cpu，大磁盘等。
程序：运算类型，逻辑类型，内存类型，数据类型，进程，线程，异步等
软件的内部设计也需要根据具体类型去定，比如相册图像压缩，消耗cpu且是同步的，就需要开多进程或者多线程处理；数据存储的，需要消耗io，io阻塞需要多线程处理；逻辑类型的，可以用异步方法，提高吞吐量等。
如下图：
使用大系统小做，分而治之的思想，整个系统可以做到层次分明，清晰有序，职责分明，每一个模块都很简单极致，发挥最大的效能，可扩展可维护可控制。互联网系统千变万化，以前往往以为复杂的东西才是高级的，做得越复杂越体现技术价值，反而往往使得系统风险系数高，不可发展，如今体会到简单的东西才是最强大的，简单到一加一等于二不会出错，更多这样的一加一组合起来可以实现更强大更稳定更灵活的复杂运算，这样的系统才可持续发展。
