构建更健壮的系统

一头强壮的大象，敌不过成群的狼。

一个欣欣向荣的大草原，既需要羊，也需要狼，正是不同的生物种群构成了稳定的生态圈。

我们的系统，既是强壮的大象，也是成群的狼。

我们的系统群，也要做稳定的生态圈。

生态圈：关于依赖与蝴蝶效应

现代的大规模应用程序，往往需要多个系统的支持，系统之间不可能完全没有依赖，就像一个生态圈，我们需要去考虑各种系统之间相互影响。

我们都知道，草原上草、羊、狼都是生生相息的食物链，草没有了，羊就没有了，狼最后也没有了。草没有了，最后的结果变成狼没有了完全是有可能的。我们可以看到，依赖是可以传递的，影响也是可以传播的。

如果一斤草养活二头羊，二头羊养活三只狼，那么这种层级放大的影响，就变成了蝴蝶效应。

不要觉得惊讶，这种情况完全有可能发生。一份的数据，被多个系统依赖，每个系统又被更多的系统依赖，这种树状的结构，在数据异常的情况下，打击是致命性的。

我们能做一些事情稍微改善一下情况：

1．简化依赖，不要增加无谓的依赖，不要把弱依赖变成强依赖

比如，同步系统是强依赖，异步系统是弱依赖。很显然，可以通过异步方式交互的系统，不要因为数据库方便就改成同步系统，那样产生故障的可能性就被扩大了。

2．虽然依赖是传递的，但是影响的传递必须切断

比如，前端应用 强依赖于数据库，数据库 弱依赖于 数据同步系统，数据同步系统 弱依赖于 运营支撑系统。

A.        运营支撑系统发送数据让数据同步系统去做同步。

B.        数据同步系统把数据同步给了数据库

C.        数据库做更新

风险在于，Ａ如果出现问题（比如被攻击），突然产生海量的数据需要同步。

我们可以分别在Ａ、Ｂ或者Ｃ作控制。

如果是Ａ中做控制，那么运营支撑系统严格限制数据同步数量。

如果是Ｂ中做控制，那么数据同步系统拒绝同步。

如果是Ｃ中做控制，那么数据库拒绝更新。

这个例子中很明显，在A中控制更合理。

从资源的角度来想，可以分为共享资源和独占资源。

共享资源，被多个使用者共享，从这个角度去看，每个使用者独占了它自己的资源，共享了共享资源。如果共享资源已经不堪负荷，我们通常希望已经在使用共享资源的继续使用，而仅仅只是拒绝新的使用者。

而所有的系统可以相对的分为关键系统和非关键系统，显然关键系统就是共享资源，因为关键系统总是被更多的非关键系统依赖，非关键系统就是使用者。再用类似的角度去想，Client和Server。Server是稀缺的，为多个Client服务。

如果Server已经处于高负载的情况，为了保证大部分Client的利益，只有拒绝少量Client，甚至主动丢弃一部分Client，来保证整体运作。

回过头来看我们的系统

1)         运营支撑系统是数据同步系统的客户端

2)         数据同步系统是数据库的客户端

3)         前端应用是数据库的客户端

基于这些分析，运营支撑系统上的超负载压力，甚至不应该蔓延到数据同步系统。

但是我们还可以从另一个角度来视审我们的策略。

象与狼：关于风险控制的策略

一头象也许不怕一头狼，但是一头象面对数量不断增加的狼群，总有一天会被拖死。

就像上一个例子里面，我们已经限制了运营支撑系统向数据同步系统同步行为。但我们还需要从效率、可用性的角度去考虑。

一般关键性系统的数量都是较稀缺的，对非关键性系统而言，又是不可或缺的。往往关键性系统的压力已经到了接近极限的时候，它不可能也无力为非关键性系统提供容错性的服务。即使在正常的情况下，任何在关键性系统上提供的容错性服务，都会消耗它的性能，而且这种消耗随着非关键性系统的数量呈不确定上升。

就像之前的运营支撑系统，一旦有海量的数据，大大超过数据同步系统的负载时，如果运营支撑系统自己控制这些数据的容错，比如延时发送，那么虽然一样会造成运营支撑数据的滞后，但至少数据同步系统仍然是正常运作的，不会因此把故障蔓延到其它系统。更重要的是，如果运营支撑系统的数量很大，那么所有运营支撑系统能够容错的总量，放在数据同步系统上必未可以支持得住。

对于一个关键性系统，也许它可以提供一些cluster或者distributed cluster的服务。但基本上，我们应该忽略这些。就cluster而言，任意一个结点可用，以及保证任意时刻所有结点的数据一致性，意味着完全的数据复制，这在一个大集群里面代表了无休止的数据复制，通常是不可接受的。对于distributed cluster而言，系统本身提供的数据自动平衡，同样意味着系统内部对资源的消耗。在负载很高的时候，在负载不高的时候，策略不尽相同。即使假定一个前提，自动平衡的策略已经可以达到完全智能化的标准，在负载高的情况下，在集群很大的情况下，互相之间的通讯，互相之间的心跳，都对系统的负载提出新的挑战。

memcached的伟大，我认为不仅仅在于它前瞻性地适应了内存越来越便宜的潮流，与时俱进，更在于它的简单。不做server之间的通讯，不做server之间的数据复制，这使得server完全只专注于I/O。GFS的伟大，绝不仅仅因为它适应了磁盘越来越便宜的潮流，同样地与时俱进，更在于它的专注简单：master只负责location，chunkserver只负责I/O。它们都同样把目光放在client，所有的分布式逻辑全部由client维护。也就是说，client维护所有的自动平衡逻辑。

不论一头象有多强壮，狼群数量的增大总有一天会打破实力的平恒。从系统的角度讲，给server更少的负担，它可以专注地提供更好的服务。而client强化控制，也意味着随着client的数量增长，系统的容错能力依然是增长的，至少这不会成为系统的瓶颈。事实上，往往现实情况中，server成本往往大于client的成本，通过client的增长来获得健壮性，远远比通过server的增长来获得健壮性要可靠的多。

评论

1 楼 wolfw 2008-12-11  

道理很深刻，描述的很清楚，不过有图就更好了，哈哈