盘点业务系统中经常遇到的一些不好的设计

过度信任下游

case1:

依赖数据侧导出的数据做数据同步，每天只同步一次

比如约定7点数据产出，10点同步一次

结果7点数据没产出，10点同步了个寂寞

导致今天的数据没有拿到，直接导致线上故障

好的做法是不信任依赖的数据，每小时同步一次，做一些去重逻辑，或者直接数据覆盖

然后还用前一天的数据做个兜底也是可行的

要面向失败的设计

case2:

用户闯关难度数值由其他团队产出，达到千人千面

结果出现不在预期内的case

1、出现任务难度为0 ： 0， 1， 2， 5， 10

2、出现任务难度不递增  ： 1，2，2，4，5

case3:

调用下游RPC，期望对现有的结果做重排序或者优化列表展示顺序

结果返回有重复值，或者直接把某些重要的值干掉了

逻辑共用

多个业务方共用一个底层系统

有一个业务有自定义需求，改了公用逻辑，导致线上故障

某一天，业务方1有一块定制逻辑，没有确定影响范围，直接改了公用系统的代码

导致线上故障。。。

系统设计之初，没有做好业务的抽象和隔离

逻辑分散

工程1有一段判断逻辑

工程2、3为了方便使用，直接拷贝了代码

后来蛋疼的是有一天，需求改了，工程1的逻辑变更，但是忘记更改了工程2、3的代码

正确的做法应该是抽取公共的逻辑，release出sdk

开关滥用

张三：今天我们开始放量，先放到1%

李四：好，已放到1%

灰度观察中。。。

张三：没啥问题，再放一波，10%，done

李四：好，然后去忙别的了，忘记放量开关2了

GG

转载请注明：汪明鑫的个人博客 » 一些不好的设计