(转)面向鲁棒的系统设计

https://yq.aliyun.com/articles/6038?spm=5176.100239.yqblog1.60.lLZ4Gx
前言
本来打算叫做面向异常的编程的,后来觉得可能多的是系统健壮性方面,于是改名面向鲁棒的系统设计,所谓鲁棒,鲁棒是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请求的超时机制,用户可能会重复点击,此时服务器和数据库的压力会很大;
数据回写,除了直接返回之外,是否可以写文件,然后直接提供给用户需要下载的文件链接;
平时遇到的问题大多数是,系统刚刚上线,业务数据比较少,功能能够正常,但是随着业务发展,数据越来越多,导致的问题就是无法下载下来,而如果没有做上面的优化或者保护的话,这个功能使用就会出现异常;

已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐
  • —软件人才免语言低担保 赴美带薪读研!—



你可能感兴趣的:(鲁棒,系统,设计)