技术架构评审

架构评审的价值与核心目标

1. 集众人之力，提前发现问题：通过集体分析，找出方案中的潜在问题，避免上线后出现不可逾越的重大技术难题。

2. 对项目健康发展至关重要：提前提出质疑，确保项目顺利推进。

1. 设计把关：确保方案合格，避免缺陷和遗漏，至少做到不犯错。

2. 保证架构设计合理性和一致性：符合整体原则。

3. 维持系统架构的全局认知：避免黑盒效应。

4. 发掘创新亮点，推广最佳实践：通过评审发现亮点并推广。

架构评审的关键要素

1. 技术选型

• 为什么选用A组件，而不选用B、C组件？

• A组件是开源的，其开源协议是什么？

• 基于什么语言开发的？出现问题时我们是否有能力自行维护？

• 性能方面是否进行过压力测试？

2. 高性能

• 产品对应的TPS（每秒事务数）、QPS（每秒查询数）和RT（响应时间）是多少？

• 设计上能够达到的TPS、QPS和RT是多少？

• 随着数据量的增大，系统性能是否会明显下降？

• 随着业务量和数据量的上升，如何进一步提升系统性能？

• 系统的性能瓶颈在哪里？

• 是否具备抗突发性能压力的能力？大概能满足多少TPS和QPS？

• 如何实现高性能？

3. 高可用

• 是否存在单点组件？非单点组件如何实现故障转移？

• 是否考虑过多活方案？

• 是否存在数据丢失的可能性？如何恢复数据？

• 系统宕机时，对业务会造成哪些影响？是否有其他补救方案？

4. 可扩展性

• A和B的业务策略相似，后续是否会衍生出C的业务策略？

• 随着业务发展，哪些环节可以扩展？如何扩展？

• 架构设计上需考虑业务的可扩展性。

5. 可伸缩性

• 每个环节的服务是否无状态？是否可以快速横向扩展？

• 扩容是手动还是自动？扩展后是否能提高响应速度？

• 这些问题都需要思考清楚，并有对应的解决方案。

6. 弹性处理

• 消息重复消费、接口重复调用的服务是否保证幂等？

• 是否考虑了服务降级？哪些业务支持降级？是自动降级还是手工降级？

• 是否考虑了服务的超时熔断、异常熔断、限流熔断？

• 触发熔断后对客户的影响是什么？

• 服务是否做了隔离？单一服务故障是否会影响全局？

7. 兼容性

• 上下游依赖是否梳理过？影响范围有多大？

• 如何进行新老系统的替换？新老系统能否来回切换？

• 数据存储是否兼容老的数据处理？

• 如果对上下游系统有影响，是否通知到上下游业务方？

• 上下游依赖方进行升级的方案成本如何最小化？

8. 安全性

• 是否彻底避免了SQL注入和XSS攻击？

• 是否存在数据泄露的可能性？

• 是否做了风控策略？

• 接口服务是否有防刷保护机制？

• 数据和功能权限是否做了控制？

• 小二后台系统是否做了日志审计？

• 数据传输是否加密验签？

• 应用代码中是否有明文的AK/SK、密码？

9. 可测性

• 测试环境和线上的差异有多大？

• 是否可以在线上做压测？线上压测如何隔离测试数据？

• 是否有测试白名单功能？

• 是否支持部署多套隔离的测试环境？

• 测试黑盒白盒工作量的比例是多少？

• 新的方案是否方便测试，这也是需要考量的因素之一。

10. 可运维性

• 系统是否有初始化或预热的环节？

• 数据是否呈指数级别递增？

• 业务数据是否需要定期归档处理？

• 随着时间推移，如果压力保持不变，系统如何巡检和维护？

• 业务运维方面的设计也需要充分考虑。

11. 监控与报警

• 对外部依赖的接口是否添加了监控与报警？

• 应用层面系统内部是否暴露了一些指标用于监控和报警？

• 系统层面使用的中间件和存储是否有监控报警？

项目阶段与架构设计的平衡