抢票系统架构设计测试设计于投产应急设计

本文链接：https://blog.csdn.net/lfssst/article/details/123967903

架构设计3

1.测试用例覆盖率

自动化的测试平台测试的覆盖率85%才可能走之后的流程

开发和测试并行，开发完成后自测要达到一定的程度，通过后测试才可以通过提测

主系分

主测分

发布评审：数据准备，发布计划，依赖的系统，与发布环境发布后验收的功能 pd验收，生产环境

测试的覆盖率和测试的通过率都是研发质量的评判的指标

2.上线三板斧

2.1可监控

可监控：上线的功能是可监控的，如果出现故障，请求消失需要立即监控到，时间拖的很长就会出大的问题，也是保护开发人员

2.1可灰度

可灰度：希望功能可以逐步开放，对小部分用户先开放

2.3可应急

可应急：对于出现的故障可以快速的发现和止血，可以快速的把业务恢复到正常

3.监控设计

3.1 业务监控

3.2

3.3

3.4

4.灰度设计

用户量大，看中用户的体验，上线的功能稳定性不能出问题

4.1 功能灰度

工具：zk，阿波罗，维护动态配置

命中灰度器的可以执行新的逻辑，规则取决于配置

防止推送策略出问题，先推送一个集群中的部分应用，

阿波罗

灰度发布

可以发现一些兼容性的问题

设置逻辑机房，互相不产生调用

流量灰度，慢慢灰过来，循序渐进的，适用于核心的应用，如果出现问题，可以吧流量迅速的切到另一个LDC2

功能灰度是必须的，其他的灰度看情况

5.应急设计

极端的情况任何一步的测试都没有发现，最好的情况是只影响自己不可用，但是也用可被其他情况调用，或者oom，线程池打满的情况，遇到这种情况，

1.直接回滚到上一个版本，但是不是最佳选择，或者说很难接受，影响到的用户太多，业务流损，用户投诉，

2.将出现问题的功能降级，熔断使他不影响其他的功能，避免二次故障

3.设置一个开关，出现问题直接返回一个默认的结果，不让这种情况因为调用而影响到其他的业务

应急预案要在发布计划和概要设计中有显示，但是回滚大概率会被打回

    /**
     * 点击删除导出记录
     * @param map
     * @param response
     */
    @PostMapping("delExportHistoryById")
    public void delExportHistoryById(@RequestBody Map<String, Object> map,HttpServletResponse response){
        ResponseModel responseModel = new ResponseModel(ErrorCodeEnum.SUCCESS);
        boolean flag = exportHistoryService.delExportHistory(map.get("historyId").toString(),response);
//        if(flag){
//            responseModel.setResMsg("下载成功");
//        }else{
//            responseModel.setResMsg("下载失败");
//        }
//        return responseModel;
    }

@Override
public boolean delExportHistory(String historyId, HttpServletResponse response) {
    ExportHistory exportHistory = new ExportHistory();
    exportHistory.setStatus("O");
    boolean b = this.updateById(exportHistory);
    return b;
}

服务：

1.对外暴露的借口，总量成功率，错误分布

2.调用第三方的借口，关系到业务知否可以执行

结果非预期：

1.入参出参的个数

2.非预期的错误

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Zk4nNyUE-1649135423814)(/Users/zhaokaijie/Library/Application Support/typora-user-images/image-20220328213147821.png)]

有数据的埋点