千里之行

系统如何演进

工作了几年，总想写些什么，思考再三决定根据自己的工作经验，写互联网系统演进，一方面总结自己的系统架构知识，一方面也抛砖引玉，该序列的博客包含：

• 系统如何演进
• 进程技术篇
• 系统技术编
• 部署技术篇
• 总结

---

系统如何演进

• 演进驱动
• 演进历史
• 思想
• 工程方法

演进驱动

大型系统是天生如此巨大，还是在使用中不断演进？大型系统的概貌是预先设计的，还是在使用过程中不断演进的？
系统之复杂，是很少有人就规划好现在的架构，而是在使用过程中，不断地重构、设计、调整而来的，是一部跟人一样的进化史，而这历史又是如何被驱动的？
业务驱动着系统的演进，系统反过来服务着业务。业务、系统是在矛盾中不断发展：
1. 用户量
用户量不断地增多，导致系统并发访问大，流量也大，并发访问大导致系统的负荷过高，如果没有处理好这负荷，就会导致系统不可用。系统犹如人，一个人如果堆积的工作量越多，就越忙，工作量如果超出一个人的承受范围，人就会出问题，比如过劳死。系统也会因为负载过高，而瘫痪。因此高并发、大流量驱动着系统演化、升级。Google 日均PV数几十亿，日均IP访问数过亿；淘宝2014双十二活动一天交易超过300亿，活动开始第一分钟访问用户超千万；腾讯QQ的在线用户数过亿。这些系统能够承受如此巨大的访问量，是一个单机系统么？或是一个简单的分布式系统吗？我想这系统肯定是不简单的。众所周知的12306系统刚一开始（2013）很脆弱，容易瘫痪，但一年后（2014）年就很健壮，不容易瘫痪。从12306系统一年的变化，我们可以看出12306是有改进的，是在演进的。
2. 可用要求提高
随着人们对系统的使用时间变长，系统的持续服务时间也不断变长，有的系统必须7*24小时不间断服务。系统的可用性一方面取决于系统组件的质量，一方面取决于系统本身的质量。不管是组件质量、系统质量，都是在演进中提升的。
3. 数据集变大
系统需要存储的数据量增多，需要大量的存储服务器。最近流行的大数据，就是基于这种状况提出的：数据集超大，以致单台机器无法存储，无法快速处理。
海量数据要求系统必须演进，由单机系统演进成分布式系统：不仅存储方面的演进，而且计算、处理方面的也必须演进。
4. 用户分布范围变广
许多互联网系统都是为全球用户提供服务的，比如QQ、微信、GOOGLE、百度、Facebook，用户分布范围广，各地网络情况千差万别。在国内，各个运营商互通难的问题：南北问题。这些问题，驱动着系统分布式演进。这些系统在各地都有中心节点，中心节点之间相互通信，中心节点与该地区的边缘相互通信。
我想如果没有不断演进，系统是不会出现这样的架构形态。
5. 安全环境变恶劣
互联网系统是开放的，因此很容易受到黑客攻击，几乎每天都有黑客攻击互联网系统。互联网系统被攻击要么瘫痪，要么用户数据被窃取，要么数据被篡改。
最近几年经常出现这样的新闻：C系统用户数据被窃取了多少，XX系统用户开房信息被窃取。
恶劣的安全环境，驱动着系统的安全性演进。
6. 需求变化
需求变化，对系统提出新的要求，也会驱动着系统的演进。产品为快速适应市场，满足用户需求，发布频率极高。
系统面临需求的变化，必须可修改，拥抱变化、响应变化。
系统不断受这些矛盾地驱动，不断地演进。在这样的演进过程中，系统要遵循什么样的策略、理念才能演化，以致不会陷入泥坑。

演进史

系统被6个主要矛盾不断地驱动着，由小变大不断演化。那系统又是如何演化的？

原始社会

早期时候，系统开始没有太多人使用，只需要一台服务器就能满足需求，这时的系统概貌如图1.1所示。

图1.1 原始社会的早期系统
应用程序相对简单，只使用到文件，而且文件也不多，并且访问量不大，因此都部署在一台机器上。
随着数据由非结构化变为结构化，并且数据库的出现，这时系统出现了新的演进，新的系统概貌如图1.2所示。

图1.2 原始社会的后期系统
应用程序、数据库、文件等部署在一台机器上，而且应用程序单一是这个时代的系统特点。

奴隶社会

系统进入奴隶社会，用户规模增长到一定规模，系统数据也增大到一定规模，并且用户访问量也增大到一定规模，以致超越单机系统的负载、存储。这时驱动着系统进行应用和数据剥离的演进，这时的系统概貌如图1.3所示。

图1.3 奴隶社会的初中期系统
在奴隶社会的中后期，由于访问的增加，数据量的增加，磁盘I/O的延迟，导致响应用户的时间变长，体验变差，并且应用服务器已经采用了本地有限的缓存还是无法解决该矛盾的时候，系统再次进行演化、升级。这时的系统概貌如图1.4所示。

图1.4 奴隶社会后期的系统
在奴隶社会，系统已经开始变复杂了，但是这个的系统特点还暂时满足这个时代的需求。不过这个时代的系统，演进也有可能对数据库服务器进行拆封。

封建社会

进入封建社会，用户的并发访问增加，导致单机应用服务器无法承受高并发的冲击，因此驱动着系统对应用服务器进行横向扩展(scale out)，这时的系统演进概貌如图1.5所示。

图1.5 封建社会初中期的系统
在封建社会中后期，随着业务不断发展，用户规模越来越大，并且分布在不同的区域，系统响应速度也相应地变慢，在不同区域的用户响应速度也不同。针对不同区域的用户响应速度不同，系统演进策略：在用户的网络提供商机房部署CDN服务器。针对所有用户响应速度变慢的问题，系统演进策略：在系统的中心机房部署反向代理服务器。
CDN 和反向代理服务器的原理也是缓存，一般使用服务器的本地存储。这时的系统概貌如图1.6所示。

图1.6 封建社会中后期的系统

资本主义社会

资本主义社会，用户的规模不断增加，而且业务也不断地发展，系统的升级、演进也变得越来越难了，每个业务服务器有可能进一步演进成一个小系统。这种情况驱动着系统必须：分治，将大业务系统进行领域建模分析，然后分割业务系统为独立的业务子系统，使得不同的业务系统解耦。
业务系统的分割成不同的子系统，子系统之间由原来的紧耦合，变成了系统间通信，而系统间的通信要求通信方式能够将系统解耦，并且能够对系统访问进行队列化处理。
这种情况驱动着系统必须加入消息队列服务。消息队列服务器采用发布——订阅模式，请求队列化，并且将系统解耦，这个时代的系统如图1.7 所示。

        图1.7资本主义时代的系统

现代文明

现代文明，业务繁多，用户访问规模海量，数据规模海量，这时文件服务器演变为分布式文件系统，数据库服务器演变为分布式数据库，单独的缓存系统也演变为分布式缓存系统。
系统架构师对用户查询进行深入的分析：绝大部分场景的查询都是K-V查询，因此导致NO-SQL系统的加入。
数据库搜索对关键词搜索的低效，驱动了系统加入了搜索引擎。子系统之间再进一步解耦、异步化。这时的系统概貌如图1.8所示。

图1.8 现代文明的系统
像GOOGLE、百度、Facebook、腾讯、alibaba的系统，就比图1.8的系统还复杂，并且为了服务全球各地的用户，会采用多中心节点部署模式，每个中心节点都部署类图1.8的系统，各个中心节点之间通过网络进行通信。

总结

这里的原始社会、奴隶社会、封建社会、资本主义社会、现代文明，对应的是系统版本：1.x、2.x、3.x、4.x、5.x，甚至是6.x、7.x 系统。
任何一个系统，都必须经历过一个演进过程，尤其是小公司的系统。 我们不能一开始就着手设计5.x 系统，但也要为1.x到5.x、6.x、7.x 演进做初步的考虑。
那我们如何设计1.x系统呢？以及后继演进，我们如何设计呢？
答案就是遵循合适的思想理念、采用合适的工程方法。
欢迎关注后继的博客。

参考：

    大型网站技术架构 核心原理与案例分析    恰如其分的软件架构 风险驱动的设计方法