伸缩性和可用性反模式

gilbertzhyin 2010-11-16

这篇文章讲了伸缩性和可用性方面的反模式,也按照自己的理解翻译了一下,欢迎各位探讨。

1单点失败(SinglePointofFailure)

大部分的人都坚持在单一的设备上部署我们的应用,因为这样部署的费用会比较低,但是我们要清楚任何的硬件设备都会有失败的风险的,这种单点失败会严重的影响用户体验甚至是拖垮你的应用,因此除非你的应用能容忍失败带来的损失,否则得话应该尽量的避免单点风险,比如做冗余,热备等。

2同步调用

同步调用在任何软件系统中都是不可避免的,但是我们软件工程师必须明白同步调用给软件系统带来的问题。如果我们将应用程序串接起来,那么系统的可用性就会低于任何一个单一组件的可用性。比如组件A同步调用了组件B,组件A的可用性为99.9%,组件B的可用性为99.9%,那么组件A同步调用组件B的可用性就是99.9%*99.9%=99.8%。同步调用使得系统的可用性受到了所有串接组件可用性的影响,因此我们在系统设计的时候应该清楚哪些地方应该同步调用,在不需要同步调用的时候尽量的进行异步的调用(而我这里所说的异步是一种基于应用的异步,是一种设计上的异步,因为J2EE目前的底层系统出了JMS是异步API以外,其它的API都是同步调用的,所以我们也就不能依赖于底层J2EE平台给我们提供异步性,我们必须从应用和设计的角度引入异步性)

3不具备回滚能力

虽然对应用的每个版本进行回滚能力测试是非常耗时和昂贵的,但是我们应该清楚任何的业务操作都有可能失败,那么我们必须为这种失败作好准备,需要对系统的用户负责,这就要求系统一定要具有回滚的能力,当失败的时候能进行及时的回滚。(说到回滚大家可能第一时间想到的是事务的回滚,其实这里的回滚应该是一种更宽泛意义的回滚,比如我们记录每一次的失败的业务操作,这样在出现错误的时候就不是依靠于事务这种技术的手段,而是通过系统本身的回滚能力来进行回滚失败业务操作)。

4不记录日志

日志记录对于一个成熟稳定的系统是非常重要的,如果我们不进行日志记录,那么我就很难统计系统的行为。

5产品质量依赖于测试

测试固然重要,但是软件系统的质量应该从设计支持就融入进来,而不是靠以后测试出问题,然后再修复。测试验证系统的行为和预期的一致,并且要保证在引入新的功能特性以后不会影响到系统的其它部门。因此希望在测试中发现性能,伸缩性和可怕用户体验的问题,然后再修复它是一种没有效果并且浪费时间和精力的不佳实践。因此我们需要在设计之初就关注系统的伸缩性和可用性,而不是依赖于测试。

6无切分的数据库

随着系统规模的慢慢变大,我们就需要打破单一数据的限制,需要对其进行切分。

7无切分的应用

系统在规模小的时候,也许感觉不出无切分的应用带来的问题,但是在目前互联网高速发展的时代,谁能保证一个小应用在一夜或者是几夜以后还是小应用呢?说不定哪天,我们就发现应用在突如其来的访问量打击的支离破碎。因此我们就需要让我们的系统和我们一样具有生命力,要想让系统具有应付大负载的能力,这就要求我们的应用具有很好的伸缩性,这也就要求应用需要被良好的切分,只有进行了切分,我们才能对单一的部门进行伸缩,如果应用是一块死板的话,我们是没有办法进行伸缩的。就好比火车一样,如果火车设计之初就把他们设计为一体的,那么我们还怎么对火车的车厢进行裁剪?因此一个没有切分的应用是一个没有伸缩性和没有可用性的应用。

8将伸缩性依赖于第三方厂商

如果我们的应用系统的伸缩性依赖于第三方的厂商,比如依赖于数据库集群,那么我们就为系统的伸缩性埋下了一个定时炸-弹。因为只有我们自己最清楚我们自己的应用,我们应该从应用和设计的角度出发去伸缩我们的应用,而不是依赖于第三方厂商的特性。

9没有卓越文化

如果我们没有一种对待错误的优秀的文化,那么我很难保证同一个失败不发生第二次。因此我们需要一种确保同样的失败不发生第二次,这需要通过我们认真的对待每一次系统的失败,从中找出问题,而不是每次修修补补,能解决问题就行,如果这样,我们会发现,最终系统会变得遍体鳞伤,体无完肤。

原文:http://www.jdon.com/jivejdon/thread/37794

相关推荐

HappinessCat / 0评论 2020-02-12