测试提前进行的越深入,越体会到了解系统架构的重要性,参与到技术方案评审,不仅是听,还要评,进一步学会审。这个阶段可以更关注可测性、性能考虑、可拓展性等
举几个技术方案阶段关注并改进的例子.

性能考虑

关注方向:系统调用、单个\批量,串行\并行,读tair\读db

     例子:

     qc系统资质验证的过程是,业务系统发起验证一颗资质树(多个资质)的请求,资质系统获取请求后,从多个业务方系统获取数据并和要求值进行对比,将对比验证结果返回到业务系统
以下是技术方案时对老系统的改进.
1. 单条验证 -> 提供批量验证接口,避免多次HSF调用
2. 单颗资质树资质获取 -> 资质数据读取方式从原有的懒加载改为预加载。合并多个资质树的资质,一次读取
3. 串行读取 -> 并行数据读取。资质数据涉及多个系统,将多个HSF调用从串行改为并行
4. 串行验证 -> 并行验证。批量验证时采用并行的方式验证
5. 提供服务方式:HSF -> JAR,本地调用和hsf调用的性能差别
6. 缓存读取方式:只读取所需 -> 读取所有,减少二次读取时对DB的访问
 

 

DB设计

关注方向:避免分库查询、分表查询、多表查询

    例子:

     服务评价项目的项目目标是对客服小二处理case的服务进行评价。record表(评价任务表,一个case对应买卖家共两条record记录即两个评价 问卷)、answer表(买卖家的答卷记录,一个问卷对应多条答案记录,recordId作为answer表外键),record为单表,answer分 表按recordId进行分表
问题点在answer表的分表是按照recordId进行取模分表。
这种方式下,查询一个case对应的评价记录:先根据caseId查询record表获得两个recordId,再根据recordId取模查询两个answer表的记录,再返回结果
改进方案是:在answer表增加一个caseId字段,根据caseId分表,这样查询答题记录只一个caseId查询一个answer表即获取买卖家答题记录。只查询一次和查询两次且有分表查询的对比,效率提升是显而易见的

hsf设计

关注方向:异常处理

    例子:

     服务评价系统对外提供一个重要hsf服务,业务系统case在完结时调用该hsf服务触发评价任务开启。下图是开发设计的调用流程, 主要关注红框中的调用方式。

业务case完结是业务主流程,开启评价是分支流程,分支流程应该是不能影响到主流程的,一个p1级应用最好不要去依赖一个p3级应用。所以,评价系统的 hsf服务不能抛任何异常给业务系统,hsf服务需要catch所有异常并包装一个统一的返回值给业务系统,这种设计方式下,除非系统挂了服务找不到了才 可能对业务系统产生影响