技术评审思考点

2022/4/22 23:45:38

本文主要是介绍技术评审思考点,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

一、组件选型360评估

评估维度


件A

组件B

是否开源(软件采购成本)

开源

不开源,支付5w/年

免费版本是否支持集群HA无单点要求

支持

支持

可维护性(方案是否成熟)

高,业界成熟解决方案,开箱即用

低,不稳定

=》复杂度

=》社区活跃度

github 5星

github  4星

=》待解决issue问题个数

近半年10个

10个

=》人力成本投入

3人

1人

=》语言支持

Java,C++

 

硬件成本(服务器成本)

需要10台组件

需要20台机器

性能

高 QPS TPS

中 QPS TPS

是否存在安全漏洞



   


























 

1.1 安全性

  • 是否彻底避免SQL注入和XSS?
  • 是否做了事前风控策略?防止资金损失
  • 是否有防刷保护机制?防爬虫机制
  • 数据库拖库了会怎么样?有无定期备份,有无多地备份(主从备份)
  • 是否有数据泄露的可能性?数据被研发偷走即使加密
  • 数据的权限怎么控制的?RBAC,ABAC
  • 功能的权限是怎么控制的?
  • 是否做了日志审计?
  • 受到了DDOS攻击怎么办?
  • 数据传输是否加密验签?Https证书签名

1.2 性能(单机最大指标)

  • 我们需求的TPS、QPS和RT(响应时间)是多少?
  • 整体设计上会做到的TPS、QPS和RT是多少?
  • 5年后存储预估:随着数据量的增大系统性能会不会出现明显问题?
  • 压力测试:系统哪个环节会是最大的瓶颈?
  • 是否打算做压力测试,压力测试方案是怎么样的?
  • 异常情况:怎么提高前端用户的访问流畅性?

 

1.3 可伸缩性(增加机器即可)

  • 每一个环节是否都是可以横向扩展的? 服务层、数据层(DB、缓存、消息队列、Hadoop集群)
  • 扩容需要怎么做手动还是自动?
  • 数据库不能横向扩展怎么办?奔跑中的汽车更换轮胎,不停服迁移
  • 纵向扩展有多少效果? 业务流量比
  • 横向扩展是否是线性的?读写比
  • 扩展后是否可以提高响应速度?平均相应时间

 

1.4 可扩展性

  • 产品未来计划:是否有了解过产品层面以后会怎么发展?
  • 公用服务:模块A是否能拆分出去独立为其它业务服务?流量大,多业务领域复用
  • 可替代:模块B是否可以替换为另一种第三方数据源? 依赖接口抽象防腐层
  • 流程强耦合:如果流程有变,需要多大的工作量来适应?
  • 是否可配置化:业务是否可以做到可配?
  • 复用性:为什么A和B都有差不多的逻辑?
  • 复用性:是否考虑到了A业务的实现以后还有B的可能性?
  • 扩展性:如果现在有两种策略以后扩展到了八种策略怎么做?
  • 以后是否可以把这个业务的H5前端适配到PC?

1.6 可靠性

  • 是否架构中有单点?
  • 故障转移是怎么实现的?
  • 集群内部故障转移需要多久?
  • MQ或存储出现问题的时候系统会怎么样?
  • MQ或存储出现问题又恢复了系统是否会自动恢复?
  • 是否考虑过异地故障转移的方案?
  • 是否考虑过多活的方案?
  • 是否有数据丢失的可能性?
  • 数据丢失后是否可以恢复?
  • 系统彻底挂了对其它业务的影响是什么?
  • 系统彻底挂了是否可以有线下的方式走业务?

 

1.8 兼容性

  • 老的系统打算怎么办?
  • 怎么进行新老系统替换?
  • 新老系统能否来回切换?
  • 别的系统怎么连接你这套新服务?
  • 上下游依赖是否梳理过,影响范围多大?
  • 上下游改造的难度怎么样?
  • 上下游改造有排期吗?
  • 上下游改造的计划和通知时间确定了吗?
  • 使用了新的数据源数据怎么迁移?
  • 使用了新的技术老项目开发能否适应?

 

1.9 弹性处理

  • 这个数据重复消费会怎么样?
  • 这个接口重复调用会怎么样?
  • 是否考虑了服务降级?哪些业务支持降级?
  • 是否考虑了服务熔断?熔断后怎么处理?
  • 是否考虑了服务限流?限流后客户端表现怎么样?
  • 队列爆仓会怎么样?
  • 是否考虑了隔离性?

 

2.0 事务性

  • 这段业务由谁保证事务性?
  • 数据库事务回滚后会怎么样?A->B, B回滚,A怎么办?
  • 服务调用了失败怎么办?超时
  • 队列补偿怎么做的?
  • 服务调用补偿怎么做的?
  • 数据补偿实现最终一致需要多久?
  • 在数据不完整的时候用户会感知到吗?

 

2.1 可测试性

  • 测试环境和线上的差异多大?
  • 是否支持部署多套隔离的测试环境?
  • 是否打算做单元测试,覆盖率目标是多少?
  • 测试黑盒白盒工作量的比例是怎么样的?
  • 是否支持接口层面的自动化测试?
  • 是否有可能做UI自动化测试?
  • 压测怎么造数据?
  • 是否可以在线上做压测?
  • 线上压测怎么隔离测试数据?
  • 是否有测试白名单功能?

 

2.2 可运维性

  • 每一个组件对服务器哪方面的压力会最大?
  • 重新搭建整套系统最快需要多少时间?
  • 系统是否可以完全基于源代码构建?
  • 系统是否有初始化或预热的环节?
  • 系统里哪些环节需要人工参与?
  • 数据是否需要定期归档处理?
  • 会不会有突发的数据量业务量增大?
  • 随着时间的推移如果压力保持不变的话系统需要怎么来巡检和维护?
  • 怎么在容器里进行部署?

 

2.3 监控

  • 业务层面哪些指标需要监控和报警?
  • 应用层面系统内部是否有暴露了一些指标作监控和报警?
  • 系统层面使用的中间件和存储是否有监控报警?
  • 是否所有环节都接入了全链路跟踪?
  • 出现报警的时候应该由谁来处理?
  • 每一个模块是否有固定的主要和次要负责人?
  • 有没有可能系统出了问题无法通过监控指标体现?
  • 哪些指标需要上大屏由监控进行7*24监控?


这篇关于技术评审思考点的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程