蝴蝶效应与架构设计

 蝴蝶效应是这样定义的：对于一切复杂系统，在一定的“阈值条件”下，其长时期大范围的未来行为，对初始条件数值的微小变动或偏差极为敏感，即初值稍有变动或偏差，将导致未来前景的巨大差异，这往往是难以预测的或者说带有一定的随机性．

       说的通俗一点，可以理解成千里之堤毁于蚁穴，一招错，满盘皆输等。

       蝴蝶效应也给了人们很多启示，我记得有这样一个例子，一个国家森林，早些年，森林时有火灾发生，后来森林的维护人员通过观察发现，当森林的树叶达到一定的厚度，就容易发生火灾，根据蝴蝶效应就是一片树叶可能引起一个国家森林的火灾。知道这个原因之后，森林的工作人员决定做一种尝试，就是在森林的树叶积累到一定厚度之前，就将树叶搜集起来，烧掉。这样做之后，森林发生火灾的概率比之前小了很多。

       有了前面对蝴蝶效应一个基本的了解，下面我想谈谈，蝴蝶效应给我们的架构设计能带来哪些启示呢？

       在蝴蝶效应里面有个阈值条件，那么其实在我们的计算机世界里面，到处都有阈值条件，比方说大家熟悉的cpu资源、内存资源、硬盘资源等等。

       比方说，现在有一个服务，经过各种优化，各种努力，只能为100W的用户提供服务，如果再加，机器就扛不住，导致服务质量下降。我们一般的思路就是，加机器来服务更多的人，但是到后面可能会发现，前端server机加起来很容易，可是数据库，一个库已经达到几百G,数据库压力很大，这个时候就傻眼了，当然聪明的你可能会想到各种办法来解决这些问题，但是我敢预言，这些办法的成本一定都不小。

       如果说用户是那只小蝴蝶，海啸就是你的整个体统瘫痪 的话，那我们能做些什么呢？就像森林管理员那样，拯救国家森林，我们该如果如何拯救我们的系统呢？ 

       我们可以效仿森林管理员，不让树叶达到发生火灾的厚度，我们同样可以当用户增长时，让我们的系统能抗住，不崩溃？比如说在早期，我们预估系统能承受100W用户，2webserver +2台DB,再 多用户的话就会达到瓶颈。我们可以这样，保持2webserver +2台DB为一个单元组，当超过100W用户的时候，我们就再建一个单元组，当然这个单元组可以慢慢成长成2台webserver +2台DB，起初的时候可以是1webserver +1台DB，等到了一定规模，就增加至2webserver +2台DB，以此类推……

       这样一来，我们的系统就被分成了若干个单元组，我们保证了每个单元组不会达到阈值条件，那么整个系统也不会达到阈值条件。这种架构设计非常适合，一个产品从无到有，从小到大的成长过程；同时由于各个单元组的相互独立，一个单元组出了问题，也不会影响其他的单元组；而且你还可以根据服务对象要求的不同，提供不同级别的服务，比方说vip提供更优质的服务，就将其放在更好的单元组里面。

       当解决一个问题的同时，一定会带来新的问题，这句话就像，任何计算机的问题，都可以通过多加一层来解决一样，需要我们牢记。当我们继续深入的时候，会发现，其实我们会面临，如何划分单元组的问题，到底怎么样的粒度比较合适？我想这个没有标准答案，根据你的业务特点，应该有所分别。