Design Review 架构规范

Design Review 是 TTM 过程中至关重要的一环，优秀的 Design review 不但能让技术方案的考虑更加周全，更多意义是避免潜在的线上 Bug 以及不必要的反复。

下面是我经常思考的一些问题，虽然不是每个项目都会涉及到这些点，而且也不应该被这些问题所局限，但作为一个参考，依然希望能给团队提供一个好的思考框架。

可用性

• 外部依赖有哪些？如果这些外部依赖崩溃了我们有什么处理措施？
• 我们 SLA 是什么？主要是指可用性目标几个 9? 50/90/99 分位数的响应时间是多少？QPS 是多少？
• 我们的超时、重试、过载保护、服务降级机制是什么？如何避免雪崩
• 我们的调用方有哪些？分别有什么服务配额？是否需要对关键的服务调用方单独部署？

运维

• 我们都有配置了哪些监控？如果出现问题，我们需要查看哪些信息？这些信息是否都有记录？
• 报警的处理流程是什么？
• 系统上线流程和步骤是什么，出了问题后是否可以回滚，以及怎么回滚？

安全

• XSS，CSRF，SQL 注入这些是否需要处理？
• 3 防怎么搞：防抓，防 DDOS，防恶意访问
• 是否有请安全团队 review
• 是否有风控的需求？
• 信息存储时是否设计到密码、信用卡、身份证等敏感信息，这些信息是怎么存储和访问的？

扩展性

• 分层，分模块怎么拆分比较合理？拆分出来的模块可以搞成服务单独部署吗？
• 应用层可以水平扩展吗？有用 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/metaq/notify)？为什么用它们？
• DB 是否可以用、以及用哪种 no sql (hbase/tair/mangodb/redis) 来优化？
• 业界或者其他团队是否有处理过类似问题？他们是怎么处理的？是否可以 copy 或者借鉴？

服务调用和服务治理

• 请求同步处理还是异步队列处理比较好？
• 服务接口的 URI 设计合理吗？可以向下兼容吗？
• 服务间的调用协议是什么(dubbo/hsf/thrift) ？有公司标准的调用协议可以用吗(hession/protobuffer)？
• 客户端和服务端的调用协议是什么(http/ws/私有)？有公司标准的调用协议可以用吗？
• 有什么服务治理相关的要考虑的吗？
• 能否接入 SLA 服务治理？

业务监控

• 正常的业务逻辑外，可能会有哪些奇葩或者恶意的操作？我们应该怎么处理？
• 除了系统上的监控外，需要什么业务维度的监控吗？
• log 是怎么记的？如果要 debug 能有什么开关迅速打开吗？log 怎么 rotate？log 会影响性能吗？

复用

• 项目中有用什么新技术吗？为什么要用新技术？未来其他人接手容易吗？
• 项目中有什么复杂计算的地方吗？这些计算可以用什么算法优化吗？
• 这个项目可以抽象出来什么可以复用的东西吗？
• 项目中的什么可以不用自己做，调用现成服务吗？

测试

• 新的系统设计是否容易独立测试

兼容性

• 新的系统是否和已有系统冲突，怎么融进去