一、需求背景

1、 清晰掌握需求的各个场景，以业务为导向，检验技术和系统能否很好支持需求的各个场景。

2、了解需求背景，有助于从技术角度上看，需求是否存在漏洞

二、系统架构

1、画出清晰的高层框架图，主要体现出用什么组件，之间是怎么连接的，数据流向。

2、证明你的思路，用框架图进行推演，是否可以解决需求问题。

3、各个组件节点，是否存在关键点，是否有备用方案，即容错容灾。

4、 估算业务数据，并发，数据总量，系统是否可以满足。

三、关键业务流程图

1、深入描述清楚关键组件节点的核心业务逻辑。

2、本地缓存防止热点出现。 本地缓存考虑空标情况。

3、处理外部接口异常情况。

4、防止流程出现阻塞情况。

5、关键接口，或读写缓存/db是否有重试机制。

6、业务或第三方接口是否考虑可重入。

7、关键数据一致性考虑。

8、关键流程是否存在并发，是否需要加锁。极端情况也不能忽略，觉得量少不可能会有并发情况，但极端情况果可以由其他bug导致的。

9、对外接口做频限保护。

10、核心业务流程记录流水。

四、业务

1、活动和时间相关的，注意零点和跨年的边界问题。

五、数据结构  （mysql 表设计，redis 缓存数据）

1、mysql 表设计是否合理，相关字段的索引；字段类型定义；是否有扩展字段；业务的数据总量是否考虑分表，用什么维度分表。

2、mysql dao 考虑连接数多少。防止对数据库压力过大，是否要加一层redis缓存。

3、mysql 优先考虑写主，读从。但也要防止主从同步的时间差可能导致业务逻辑的问题。

4、mysql sql 效率问题，如:  是否让索引失效，是否有必要连表，连表的是否表设计有问题。

5、redis 缓存是否存在热点， 是否存在大key， 是否考虑缓存空标，空标有效时间和正常的有效时间要区别出来。有效时间是否考虑打散，防止数据同时失效出现雪崩。

6、redis 数据结构设计注意版本号或扩展字段。反过来，在迭代新增扩展字段时，要考虑数据序列化问题，即版本号等问题。

六、协议

1、协议要简洁易懂，字段命名不要出现歧义，注释清楚。一定要有初始化，且初始化的值要合理。

2、协议要有对应的文档。文档说明清晰。文档要用 source 记录调用业务来源，预估请量，相关负责人。

3、请求协议要有 source 字段定义业务来源。

4、服务的协议要注意可扩展，新增字段要在 mapExt 中添加。

5、服务的协议初始化，序列化要对应正确。

6、响应协议要有错误码和错误信息。在文档要对错误码做出释义。

七、配置监控

1、对所有第三方接口要单独监控。

2、dao 操作要做单独监控。

3、redis 缓存/进程内缓存要监控命中率。

4、对外接口做全局监控。

5、daemon 也要做全局监控。

6、对外部参数的校验可以不做告警。

7、集中建立个性化视图，写清楚紧急联系人，方便快速找到对应的负责人。

8、接口调用来源做统计监控。

9、关键业务做出错告警。

10、 监控让服务有可观察性。

八、异常处理

1、考虑兜底方案，降级方案，补偿机制。

2、重试，告警。