软件可靠性的一些关注点

本文算是对最近遇到的软件可靠性问题的一个小结,从非功能层面考虑。市面上好像还没有一本关于软件可靠性方面的权威书籍,所以不知写的是否准确详尽。

1. 冗余

    系统中的任何部分都需要有冗余,即不存在单点故障,网络链路、服务器主机,再到软件层面的各功能模块,都应具有冗余,保证在系统中出现一个故障点后,可以马上切换到另一处完成任务。现在互联网的数据量大,并发高,一般都会采用负载均衡集群的策略,要做好系统监控检查,笨点的就是ping,另外可通过应用层面去检查。还有就是双机热备的策略,好像一些商用软件这样会比较省license费用。系统再大一点,或许还要考虑异地容灾。

    这些应该都是在系统设计、组网层面的,具体到软件模块,可能也就跟数据库有点关系,不过只要存储系统用个raid之类的,也不用在应用层关心太多。

2. 独立的备份与恢复系统

    这算是前面一条的补充吧,备份恢复是在应用层面对业务数据的保护,各数据库产品都有自己的一套备份恢复方案,网上资料也一大把。应用程序需要备份吗?大概保留一个安装程序就差不多了吧,版本别搞错了。

3. 无处不在校验

   代码中的函数参数校验不用多说,健壮的代码必须具有的特性。更加要注重模块间、平台间接口的参数校验,以及校验失败时的异常处理。

   对于分布式系统,少不了数据的一致性校验,怎么校验就要看系统的实际情况,这与系统的数据同步机制有关系,当然至少还是要保证数据在校验规格上是能通过的。用数据库同步会比较简单,但是会消耗性能,更好的方案是内存中的会话同步。

4. 独立的系统监控、告警与恢复

   好像现在是个软件都有提供一个独立的监控系统。监控的内容应该要有个checklist,系统部件的状态那是必须监控的,比如哪个服务器宕机了,那就让它重启下,哪个进程挂了,也得去拉它一把。系统资源参数也是应该监控的,如CPU、内存、IO,还应该有跟系统性能关系紧密的监控项,比如吞吐率、响应时间等。当然,还要监控与业务强相关的内容。监控项的checklist不太可能一蹴而就,以后慢慢加吧。

5. 日志系统

   日志的作用是对系统的操作有一个记录,方便找出系统问题所在,要警惕异常情况下的超大日志。

6. 系统流量控制

   避免出现过大的访问压力,把系统压垮了,底线就是系统不挂。笨点的办法,系统压力超过一个阈值就直接拒绝服务,用户你就下次再试吧,举个例子,各游戏平台的房间人数上限。当然,已在进行中的会话是不能中断的。其他更好的办法,暂时还不是很了解,大概也还是要跟系统实际架构结合吧。

7. 升级、扩容

   尽量让用户感觉不到系统在升级、扩容,当然客户端升级那是没办法了,这也是C/S架构系统的一个劣势。

 

posted @ 2012-04-11 00:27  苏堤白堤杨公堤  阅读(372)  评论(0编辑  收藏  举报