系统健壮性的思考

一、概述
最近系统有两个故障都跟系统健壮有很大的关系。为此，我们不得不进行思考，如何提高系统的健壮性。系统在经过功能测试后，对于正常的业务数据处理往往没有任何的问题，但是对于一些异常的数据、异常的业务处理就会出现系统集群不可用等灾难性的问题。

异常的数据一般是因为系统的数据修正引起，往往在存储方面就不符合业务一致性约束。对于一些有年代的系统，数据修正又不可少，在我就职的部门中，每天都在进行着数据修正。如果有位开发因为数据修正，导致整个集群挂掉了，这是很悲剧的。有人说，一切都是数据修正的错，如果没有数据修正，系统能很好的运行，但是现实的问题是，每天必须得数据修正。
另一个是异常的业务，其实也是一个修正，我们认为业务部门没有按照要求来使用我们的系统，业务方乱来，或者是开发又一个不经意的业务修正。

他们说，你这个系统这么不健壮，但是现实的问题是，我们经常是被业务牵着走，那有时间关心系统的健壮性，能实现功能就万事大吉了。先不管时间问题，系统还是应该考虑健壮性的，我们在设计系统的时候就需要考虑一些常见的不可忽视的问题。
二、一些基本的措施
我认为，提高健壮性需要从几个方面入手：业务压力、架构设计、程序编码、监控反馈。

业务压力，我们需要团队来评估好业务的压力，未来一定的时间内，有多少的流量。如上次做了一个发票系统，业务给出的评估是每天1w不到的发票量，不到10w的api调用。那么我可以认为目前财务系统的架构完全能胜任，不用加任何机器，甚至不用特别的优化，当然所有的页面请求都必须走上索引。
架构设计，这个范围很大，一般我们对于不是特别实时的业务采取用时间换取性能、以空间换性能等方案。如：把一些数据先存在数据库中，待半夜压力小的时候，再处理；对于一些有峰值的业务，我们一般采用异步消息的方案,让MQ来做缓冲；对于查询多，读多写少，我们一般采取CQRS的方案，针对读取可能还用到了搜索引擎的技术；为了协调多个系统变更，我们往往不使用分布式事务，经常采取的是补偿机制等等。
程序编码，代码才是最终剩下的看得见的。程序员最起码需要能写好代码，也要写出健壮性的代码。对于字符串的空值判断；及时回收对象；对于大数据量处理要真分页；不要写死循环来做sleep；不写出可能出现的死循环；不要吃掉异常；知道有异常后要有补救措施等。编写代码的时候，注意的点还是非常多的，此时需要借助一些静态工具，如：sonar、findbugs、PMD等。
监控反馈，当程序出现异常后，要及时报警，要有补救措施。报警可以发送给人，也可以发送给系统自动处理，如：服务降级、自动重启等。人为处理的时候，一定要想清楚了，是否会引起连环效应。

三、重点突出
我认为，一般突出的问题有：空指针异常、数据修正危机。

有对象的地方就有空指针，有对象的地方就有字符串。在写代码的时候，都要做空对象的验证。没有谁能保证你用的对象不为空。这句话很极端，但就是让开发知道空指针随时存在，需好好处理。
数据修正危机，大部分情况是，平时基本查询更新都是有几条数据，但是突然变成了几十万条数据的查询与更新。对于查询，一会就出现服务器内存暴涨，一段时间后，服务一般是处于要死不死的状态。对于更新，基本是超时，数据库压力变大，此时就危险了。引起数据暴涨的情况有很多，大部分是数据修正引起。此时我们一般在数据映射的底层做好限制，当查询、更新超过一定数目就抛出异常，此举可以保护应用或者数据库。

四、后言
以上谈了一些系统健壮性问题，可能远远不足。我也吃一堑长一智，遇到了故障及时解决，再总结教训即可。以上是一些思考，欢迎指出不足。