Design Review
原创Design Review
原创
用户6884826
修改于 2021-07-08 14:39:24
修改于 2021-07-08 14:39:24
Design Review
详解
翻译为设计评审，也就是对需求设计进行审核，防止出现异常问题，例如下面的这些
可用性
- 外部依赖有哪些？如果这些外部依赖崩溃了我们有什么处理措施？
- 我们SLA是什么？主要是指可用性目标几个9? 50/90/99分位数的响应时间是多少? QPS是多少?
- 我们的超时、重试、过载保护、服务降级机制是什么？如何避免雪崩
- 我们的调用方有哪些？分别有什么服务配额？是否需要对关键的服务调用方单独部署？
运维
- 我们都有配置了哪些监控？如果出现问题，我们需要查看哪些信息？这些信息是否都有记录？
- 报警的处理流程是什么？
- 系统上线流程和步骤是什么，出了问题后是否可以回滚，以及怎么回滚？
安全
- XSS，CSRF，SQL注入这些是否需要处理？
- 3防怎么搞：防抓，防DDOS，防恶意访问
- 是否有请安全团队review
- 是否有风控的需求？
- 信息存储时是否设计到密码，信用卡，身份证等敏感信息，这些信息是怎么存储和访问的？
- 系统是否符合公司的安全规范(SSO, 接口认证)？关键业务操作是否可审计(可回溯谁在什么时间干了什么操作)
扩展性
- 分层，分模块怎么拆分比较合理？拆分出来的模块可以搞成服务单独部署吗？
- 应用层可以水平扩展吗？有用session吗？可以去掉session吗？
- 如果系统的负载提升到以前的3到10倍，当前系统是否依然可用
- 存储层面如果需要扩展存储怎么做？
- 系统中有哪些上下依赖的节点/系统/服务？这些依赖是否会导致无法并行开发？能否去掉这些依赖？
- 是否有数据访问API? 数据API的设计对性能的考虑是什么？数据API对异常数据(超大数据集、空数据集、错误数据、schema异常…)的处理是什么?
存储
- 数据计划怎么存储？会有可能的性能瓶颈吗？需要考虑一些缓存方案吗？
- 有什么复杂SQL可能会导致慢查询吗？
- 数据库的操作什么地方用了事务？什么情况会导致锁竞争？我们的锁策略是什么？一致性和可用性如何平衡？未来如果分库分表会有什么影响？
- 缓存失效会有什么影响？缓存大量失效会有什么影响？冷启动有问题吗？有热点数据吗？多个缓存节点需要权衡可用性和一致性吗？
- 存储时，是否需要分库，分表，选择的理由是什么？
技术选型
- 开发语言是什么，框架是什么为什么用他们？
- 缓存用什么（tair/medis/redis/memached），web server用什么？(nginx+php fpm, apach php扩展，jetty，tomcat，jboss)，消息队列用什么(rebbitmq/beanstalk/kafka/mafka)？为什么用它们？
- DB是否可以用、以及用哪种no sql(hbase, tair)来优化？
- 业界或者其他团队是否有处理过类似问题？他们是怎么处理的？是否可以copy或者借鉴？
服务调用和服务治理
- 请求同步处理还是异步队列处理比较好？
- 服务接口的URI设计合理吗？可以向下兼容吗？
- 服务间的调用协议是什么？有公司标准的调用协议可以用吗？
- 客户端和服务端的调用协议是什么？有公司标准的调用协议可以用吗？
- 有什么服务治理相关的要考虑的吗？
- 能否接入otco或者sg做服务治理？
业务监控
- 正常的业务逻辑外，可能会有哪些奇葩或者恶意的操作？我们应该怎么处理？
- 除了系统上的监控外，需要什么业务维度的监控吗？
- log是怎么记的？如果要debug能有什么开关迅速打开吗？log怎么rotate？log会影响性能吗？
复用
- 项目中有用什么新技术吗？为什么要用新技术？未来其他人接手容易吗？
- 项目中有什么复杂计算的地方吗？这些计算可以用什么算法优化吗？
- 这个项目可以抽象出来什么可以复用的东西吗？
- 项目中的什么可以不用自己做，调用现成服务吗？
推荐方法
根据需求我们需要给出实现方案，如Db 表设计，消息队列设计，代码组织，模块划分，单元测试等等，这是我目前了解到的，我开发的时候还没有做到这么细，也是自己后面努力的方向。
设计好方案以后需要思考是否可以满足我们这次开发的业务需求：
- 功能是否完善
- QPS是否合格，当然这个是在我们项目对性能有要求的前提下
- 线上出了问题是否方面定位和分析
- 使用是否好用
给出设计方案以后，我们可以思考一下，然后隔一天自己Review一下，如果自己觉得没有什么大的问题的时候，请团队内的同事或者产品经理帮忙Review一下自己的设计和分析，在和同事交流和分析的时候，我们往往会get到我们没有注意到的细节和问题，这也就是Design Review 的重要性了，根据我们讨论和分析得到的问题，给出解决方法和方案，然后再Review一下，如果没有问题，我们接下来就可以进入开发阶段了。
在Design Review的过程中帮我们暴露了我们没有考虑到的问题，提前解决总比我们开发到一半才发现自己的设计有问题，需要重新设计要好的多。同时，不要害怕被指出问题，提早暴露问题总比线上出了问题好的多，还有要有开放和空杯的心态，和同事一起分析和解决问题是成长最快的。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
评论
登录后参与评论
推荐阅读