组件选型
• 为什么选 A 不选 B 呢？
• A 不是开源的，出了问题怎么办？
• B 虽然是开源的，但是是 Erlang 写的，公司没人能看懂怎么办？
• C 我看待解决的 Issues 还有很多，有没有去了解过？
• 这个组件在性能方面你是否了解过？
• 开源的免费版本不支持集群怎么办？
• 如果彻底要自己写这个组件有没有可能性
组件特别是存储组件选型挺重要的，可以有那么几周的时间搭一个高可用的集群，使用接近于真实的数据对组件进行压测。眼见为实耳听为虚，自己通过压测对比一下自己得出的数据和公开的数据是否有差异，如果有的话说不定还能发现自己使用上的一些问题。尽
量还是选用使用的人多的开源组件吧，出了问题至少 Patch 不会来的太慢。
性能
• 我们需求的 TPS、QPS 和 RT 是多少？
• 整体设计上会做到的 TPS、QPS 和 RT 是多少？
• 随着数据量的增大系统性能会不会出现明显问题？
• 系统哪个环节会是最大的瓶颈？
• 是否打算做压力测试，压力测试方案是怎么样的？
• 怎么提高前端用户的访问流畅性？
对于重要的项目，建议做一下整体压测，没有经过压测得出来的估计的结论往
往可能是错的，我们总以为最终会死在最后的存储上，但是很可能早早就死在
了程序的低级错误上，比如在一些存储组件的 Client 使用上，如果没把控好最
佳实践（把应该作为单例使用 Clinet 每次都去创建一次，默认的线程数小的可
怜应该重新配置但是保留了默认值），死的非常难看。
可伸缩性
每一个环节是否都是可以横向扩展的？
• 扩容需要怎么做手动还是自动？
• 数据库不能横向扩展怎么办？
• 纵向扩展有多少效果？
• 横向扩展是否是线性的？
• 扩展后是否可以提高响应速度？
灵活性
• 是否有了解过产品层面以后会怎么发展？
• 模块 A 是否能拆分出去独立为其它业务服务？
• 模块 B 是否可以替换为另一种第三方数据源？
• 如果流程有变，需要多大的工作量来适应？
• 业务是否可以做到可配？
可扩展性
• 为什么 A 和 B 都有差不多的逻辑？
• 是否考虑到了 A 业务的实现以后还有 B 的可能性？
• 如果现在有两种策略以后扩展到了八种策略怎么做？
• 以后是否可以把这个业务的 H5 前端适配到 PC？
可靠性
• 是否架构中有单点？
• 故障转移是怎么实现的？
• 集群内部故障转移需要多久？
• MQ 或存储出现问题的时候系统会怎么样？
• MQ 或存储出现问题又恢复了系统是否会自己恢复？
• 是否考虑过异地故障转移的方案？
• 是否考虑过多活的方案？
• 是否有数据丢失的可能性？
• 数据丢失后是否可以恢复？
• 系统彻底挂了对其它业务的影响是什么？
• 系统彻底挂了是否可以有线下的方式走业务？
安全性
• 是否彻底避免 SQL 注入和 XSS？
• 是否做了风控策略？
• 是否有防刷保护机制？
• 数据库拖库了会怎么样？
• 是否有数据泄露的可能性？
• 数据的权限怎么控制的？
• 功能的权限是怎么控制的？
• 是否做了日志审计？
• 受到了 DDOS 攻击怎么办？
• 数据传输是否加密验签？
兼容性
• 老的系统打算怎么办？
• 怎么进行新老系统替换？
• 新老系统能否来回切换？
• 别的系统怎么连接你这套新服务？
• 上下游依赖是否梳理过，影响范围多大？
• 上下游改造的难度怎么样？
• 上下游改造有排期吗？
• 上下游改造的计划和通知时间确定了吗？
• 使用了新的数据源数据怎么迁移？
• 使用了新的技术老项目开发能否适应？
弹性处理
• 这个数据重复消费会怎么样？
• 这个接口重复调用会怎么样？
• 是否考虑了服务降级？哪些业务支持降级？
• 是否考虑了服务熔断？熔断后怎么处理？
• 是否考虑了服务限流？限流后客户端表现怎么样？
• 队列爆仓会怎么样？
• 是否考虑了隔离性？
事务性
• 这段业务由谁保证事务性？
• 数据库事务回滚后会怎么样？
• 服务调用了失败怎么办？
• 队列补偿怎么做的？
• 服务调用补偿怎么做的？
• 数据补偿实现最终一致需要多久？
• 在数据不完整的时候用户会感知到吗？
可测试性
• 测试环境和线上的差异多大？
• 是否支持部署多套隔离的测试环境？
• 是否打算做单元测试，覆盖率目标是多少？
• 测试黑盒白盒工作量的比例是怎么样的？
• 是否支持接口层面的自动化测试？
• 是否有可能做 UI 自动化测试？
• 压测怎么造数据？
• 是否可以在线上做压测？
• 线上压测怎么隔离测试数据？
• 是否有测试白名单功能？
可运维性
• 每一个组件对服务器哪方面的压力会最大？
• 重新搭建整套系统最快需要多少时间？
• 系统是否可以完全基于源代码构建？
• 系统是否有初始化或预热的环节？
• 系统里哪些环节需要人工参与？
• 数据是否需要定期归档处理？
• 会不会有突发的数据量业务量增大？
• 随着时间的推移如果压力保持不变的话系统需要怎么来巡检和维护？
• 怎么在容器里进行部署？
监控
• 业务层面哪些指标需要监控和报警？
• 应用层面系统内部是否有暴露了一些指标作监控和报警？
• 系统层面使用的中间件和存储是否有监控报警？
• 是否所有环节都接入了全链路跟踪？
• 出现报警的时候应该由谁来处理？
• 每一个模块是否有固定的主要和次要负责人？
• 有没有可能系统出了问题无法通过监控指标体现？
• 哪些指标需要上大屏由监控进行 7*24 监控？
设计文档的一些要求
1.交代背景和需求全貌
使用脑图在技术角度给出一下自己理解的项目需求的分布。PRD
中的产品功能脑图可以和这里技术角度的脑图有差异，在说清楚需求的同时侧
重技术层面，体现在：
可以不按照需求的功能点进行归类而是按照实际项目归类，把需求列在实际的项目
下面
• 可以区分需求是自己干的还是调用外部的接口，可以在图上以不同的形态提现
• 可以画出功能之间的依赖关系，以虚线实线进一步区分依赖的程度
• 可以在图上体现需求的优先级以及需求目前的进展和负责人，这样基本一个图就可
以看清楚这个项目需要消耗多少资源需要多久可以结束
2.系统架构图
架构图需要传递清楚
下面的信息：
• 项目由哪些模块、服务、缓存、存储构成，可以以不同的图案和颜色代表不同类型
• 模块之间的依赖关系（当然，也可以从数据的流向角度来画）
• 核心流程的步骤，沿着图上的 1、2、3 基本就可以大概了解核心流程的实现
• 可以用大的框把组件进行分组来描述组件的部署方式（比如相同机器上承载的组件
在一个框内）
• 可以以边框的虚实来分类项目内的组件或三方组件，可以以箭头的虚实来标记主要
流程次要流程等等
对于复杂的项目，要画一个图说清楚很难，可以画一个大的架构图，然后针对每一个模块或流程再细化画不同层次的图。
交互时序
时序图的表达非常重要，可以表现需求脑图、架构图和 API 脑图无法表现出来
的几个方面，清晰展现了某个事情：
• 关键的利益关系方。这个事情由哪几个方面构成，可以是用户、甲方、乙方这么来
分，也可以是用户、APP 客户端、服务端这么来分
• 每一方在做什么，依赖的又是什么，整个顺序是怎么样的
• 技术层面这是同步接口、还是回调、还是非技术的线下流程
• 还可以在图上表现出可选逻辑，条件判断逻辑，循环逻辑等等
对于这种时序图，采用传统的工具来画费时费力，推荐下面两个工具
https://www.websequencediagrams.com/和http://plantuml.com/sequence-diagram
数据库 ER
ER 图就是实体联系图。形式上我们可以在图上表现几个点：
• 实体：哪些表
• 实体上的属性：体现实体之间关系以及实体业务功能的重要字段
• 联系：实体和实体之间的关系，比如一对多，多对一还是多对多之类
• ER 图可以以极小的空间展现很多信息，这样我们可以在图上对业务进行分组，看到全貌
• ER 图展现的是表和表之间的关系，一眼可以看出最重要核心的表是哪些
