前言
- 本来打算叫做面向异常的编程的，后来觉得可能多的是系统健壮性方面，于是改名面向鲁棒的系统设计，所谓鲁棒，鲁棒是Robust的音译，也就是健壮和强壮的意思。它是在异常和危险情况下系统生存的关键。
- 平时在做业务系统的时候，尤其是最近一年多接触的超复杂系统，发现处理线上问题所占的时间越来越多，总结发现，其实这些问题大都是之前欠下的债，至于为啥欠债，大多数情况下迫于项目或者日常的时间压力，很多设计从简，业务流程考虑主流程和分支流程，异常流程关注的少，不管三七二十一，功能先上线再说，如此便导致了恶性循环。
- 由此，我们可以有的应对方案是啥呢，后面的项目，肯定也会是时间压力大的，那只能提升我们自身处理异常的能力了，也就是说在系统设计或者方案考虑的时候，就规避掉，提升应对经验，这样在同样的时间里面，就能够游刃有余，编写出更高质量的代码，进入良性循环阶段。
解决方案探索
- 大多数的新手程序员，由于编码经验的缺失，导致在代码的保护方面做的不好，随着后续编码经验的积累以及采坑次数的增加，慢慢的会更多关注在健壮性方面；
- 分享部分典型的案例，抽象一下，学习别人失败的教训，举一反三，来规避问题；
抽象的解决方案描述
-
远程资源的调用，务必考虑失败或者超时的逻辑； -
业务逻辑的测试，多多模拟异常的边界情况； -
数据获取类的接口，需要评估目前的数据量，后续的增长情况，以及极端情况下的量大小； -
列表类的接口或者数据展示，需要考虑数据的极限情况，最大是多少，并做好保护； -
批量的数据，务必需要考虑异常情况，部分失败了怎么办;
典型案例
-
本地缓存，加载失败，之后应用系统启动
- java local cache在高并发系统中，使用的较多，把热点的数据或者元数据存储在JVM的heap区，从而实现低延迟，但是这里就涉及到缓存数据的加载了；
- 常用的数据加载方案，一种是应用启动的时候，全部加载所有的数据，之后有增量变更的时候，再增量更新；另外一种是启动的时候不加载，在数据第一次访问的时候加载这个数据；
- 这两种方式各有优劣，但是假如选择了第一种，就需要在逻辑里面考虑，假如缓存数据加载失败了，怎么办，是应用系统直接启动失败，还是代码逻辑里面冗余懒加载的机制，如果不考虑，又一个坑留下了；
-
分布式缓存和数据库中的数据一致性考虑
- 目前互联网级的系统，缓存基本上是架构上不可或缺的，引入缓存，必然就会面临数据一致性问题，举个例子，加入同一份数据，在DB和缓存中都有，这时候用户在页面操作，变更数据，需要变更缓存和DB，需要同时生效，如果update 的sql执行成功，之后缓存变更的时候超时了导致变更失败，这时候，整体应该返回用户失败，然后DB的数据回滚掉。
- 如果是没有经验的开发，可能就DB更新，然后缓存更新，没有针对缓存更新失败或者超时做逻辑处理，本地值系统功能逻辑缺失导致；
-
业务操作和数据库持久化以及消息发送的一致性考虑
- 业务系统，在考虑异步解耦的时候，会引入消息系统，这时候面临了一个问题，就是业务操作和消息系统的一致性问题；
- 业务操作和消息的发送，要能够满足事务的特性，例如借助二阶段提交来实现，然后消息系统来进行重试，从而实现最终一致性的要求；
-
批量更新数据库的顺序问题导致的死锁
- 假如这里有个方法，是List数据的更新，在并发情况下，如果更新的SQL不做排序，会导致死锁问题，这时候需要按照唯一主键，例如id来做排序，从而保证锁占用的时候的顺序性；
- 至于为啥会有死锁问题，假如两个调用，含有相同的数据，例如都含有A和B，因为批量update占锁的时候，是行级占用，第一个线程是A-B顺序，第二个线程是B-A顺序，第一个线程占了A，第二个线程占了B，然后，然后就死锁了；
-
页面点击操作，可能涉及到非常复杂的业务逻辑，是否考虑异步化，引入排队机制
- 举个例子，点击一个确认按钮，背后很多业务逻辑，这时候需要用户等待的时间比较长；
- 如果存在少量数据和大量数据共同存在，切大数据量是常态的情况下，可以考虑异步化操作；
- 用户点击之后，存储任务在进行中的状态，然后后台多线程处理，处理完了之后，回写状态，页面刷新后看到最新的结果，如果不需要用户刷新就能看到结果，可以在页面做长连接或者ajax轮训；
-
更新数据，例如更新十条，第六条出错了，是回滚还是继续处理
- 批量操作，正常流程没有问题，一下子全部成功，但是假如其中的一条出现错误；
- 两种方案，一种是所有的数据都回滚，然后提示用户修改数据，重新提交，另外一种就是成功的提交，失败的记录下来，让用户重试失败的数据，但是失败的逻辑一定要有；
-
页面数据加载多个区块的数据，且部分区块获取数据的接口高延迟
- 同步加载的时候，整个页面加载的速度会慢很多，所以在做数据加载设计的时候，就要区分掉；
- 区块可以修改为异步ajax来进行加载数据；
-
数据导出功能，如果是非常少的数据导出，则直接导出即可，但是数据量大，就会面临各种问题
- 数据读取的时候，如果多于特定的量，是否可以分页或者多线程加载；
- 导出数据的上限限制，如果没有上限，可能出现几百万的数据，用户点击导致，由于http请求的超时机制，用户可能会重复点击，此时服务器和数据库的压力会很大；
- 数据回写，除了直接返回之外，是否可以写文件，然后直接提供给用户需要下载的文件链接；
- 平时遇到的问题大多数是，系统刚刚上线，业务数据比较少，功能能够正常，但是随着业务发展，数据越来越多，导致的问题就是无法下载下来，而如果没有做上面的优化或者保护的话，这个功能使用就会出现异常；
