大系统演进缩影.pdfVIP

千⾥之⾏，始于⾜下 ⼤系统演进之道 作者：若⽔ Email ：watermind@126.com QQ ： 2065136162 时间：2014 年秋季
 系统演进之道 1 ⼤系统演进缩影 系统是在进化的 系统不是⽣来就庞⼤⽆⽐的，⽽是随着访问、数据的增多不断地演进。因此系 统，是随着需求的驱动，在不断地演进。 早期由于⽤户访问量少、数据量少且简单，因此系统也⽐较简单。图⼀代表着 这个时候的典型系统架构。 应⽤服务器 ⽂件 应⽤ 图⼀系统架构 随着⽤户数据由⾮结构化到结构化的发展，于是出现了关系型的数据库。结构 化数据是指可以⽤⼆维表结构来逻辑表达实现的数据，即⾏数据。⾏数据，⼀般存储 在数据库⾥。反之不⽅便⽤数据库⼆维逻辑表来表现的数据，则称为⾮结构化数据。 显然，数据库存储的数据，就是结构化数据。⽽⾳频⽂件、视频⽂件、图⽚这些就归 类为⾮结构化数据。图⼆代表着这个时期的典型系统架构。 应⽤服务器 ⽂件 应⽤ 数据库 图⼆系统架构 系统演进之道 2 不过这种数据与应⽤耦合的系统，存在扩展的隐患。单节点系统的存储空间、 CPU、内存是有限的。随着应⽤的增多、数据的增长，必然会⾯临挑战。 解决这些挑战的，有两种⽅式：scale up (纵向扩展) 和 scale out(横向扩展) 。如果采 ⽤scale up 的⽅式，则靠增加内存、CPU、存储空间。单节点毕竟这样扩展是有限的， ⽽且成本会偏贵。因此单节点往往是通过提⾼单机性能、充分利⽤单机CPU、存储空 间来满⾜业务需求，是在系统设计⽅⾯下功夫。在充分提⾼单节点的性能、CPU利⽤ 率、存储空间利⽤率的情况下，如果还不能满⾜需求，则要进⾏scale out 。 但是如果在系统动⼒特性提升上挑战较⼤，则可以先选择scale out 。其实⼀个系统 不仅要满⾜⽤户的功能需求，还要满⾜⽤户其他的⾮功能需求。⾮功能需求包含：性 能、安全、可靠、数据安全、可⽤等特性。 未来潜在的挑战、需求，必然驱动系统进⾏扩展。但是系统如何进⾏扩展呢？数据 和存储要分离，还是继续耦合⼀块。这⾥涉及了⼀个理念问题，或是⼀个系统架构问 题。 系统架构从应⽤和数据关系来看，有两种特性：share nothing 和 share disk(share data) 。share nothing 是指各个处理单元都有⾃⼰私有的CPU/内存/硬盘等，不存在共 享资源，类似于MPP （⼤规模并⾏处理）模式，各处理单元之间通过协议通信，并⾏ 处理和扩展能⼒更好。典型代表DB2 DPF和hadoop ，各节点相互独⽴，各⾃处理⾃⼰ 的数据，处理后的结果可能向上层汇总或在节点间流转。我们常说的 Sharding 其实就 是Share Nothing架构，它是把数据从物理存储上被⽔平分割，并分配给多台服务器 （或多个实例），每台服务器可以独⽴⼯作，具备共同的schema ，⽐如MySQL Proxy 和Google的各种架构，只需增加服务器数就可以增加处理能⼒