架构设计开发的稳定性思考

最近接触了很多生产上的稳定性问题，总结了下，其实很多问题都是在前期埋下的坑。如果在架构设计、详细设计和编码的时候提前规避掉，会大大减轻后期的运维压力。这里整理下个人理解供参考，欢迎讨论。

本文主要分3个大章节介绍：

架构设计，是希望能站在项目出发点和全局的角度去看整个架构，思考合理性和系统边界的依赖关系，重点放在解决根本问题上，避免出现设计偏差。

详细设计，其实是一种文档规范，基于统一的规范认识，保证各个干系人对于问题和解决方案理解一致。一些关键图形，更能便于其他人快速理解设计意图。

稳定性，主要介绍了在工作中的各个阶段，应该要考虑的重点，对于线上发布变更的内容，要做到可监控、可灰度、可应急。

一、架构设计

1.1 基本背景

简短介绍需求目标（或技术目标），提炼出架构设计上要解决的问题重点（必要性）。

例：本次需求主要是开发一款电子合同签订工具，提供给商业拓展人员使用，提高合同签订效率，预计提效75%，每年节约成本XX元，主要的功能有电子签章、电子条款、电子合同审核流程等。

1.2 业务全景图

主要用于说明上下游关系，判断架构和依赖的合理性；

1.3 改造点

列出涉及到的应用、模块的改造点，重点、风险点、难点

二、详细设计

2.1 用例图

角色、功能、依赖描述

2.2 系统间时序图

描述系统之间的调用时序关系

2.3 系统内流程图

描述内部功能的流转、关键操作

2.4 ER图

数据模型设计、表结构变动

2.5 外部依赖

依赖的外部服务的接口、MQ、工作流

2.6 对外接口服务

对外提供的SOA接口、前端接口、MQ

三、稳定性

安全生产架构重点：灰度和变更、资损防控、攻防、容灾4大重点。

日常治理：巡检、监控治理、限流体系、预案保鲜

日常机制：故障管理、变更管理

可监控：监控是系统的眼睛，通过加入埋点、指标监控、数据监控，能及时发现系统出现的问题，及时介入处理，及时止损。

可灰度：通过流量灰度的方式，观察线上变更的运行情况，如果出现异常，能够将影响缩小到可控范围内。

可应急： 当线上出现问题时，能快速回滚、降级、切换和数据恢复，避免造成恶劣影响。

3.1 接口设计

3.1.1 依赖的外部接口

1. 确认外部接口的QPS、RT时间，合理设计线程池和超时时间
2. 接口是否可降级，梳理强弱依赖，弱依赖做异常自动降级
3. 确认接口的幂等性，尽可能要求支持幂等
4. 确认接口的交互三态（成功、失败、未知异常）确认，对每一种情况都有处理措施（补偿、告警、日志）
5. 接口规约，字段名称、字段长度、字段类型
6. 接口变更，必须兼容老业务；

3.1.2 对外提供的接口

1. 提供接口的QPS、RT时间；
2. 接口设计幂等；
3. 接口有明确的返回值，不要通过抛异常的方式返回，约定好未知异常的处理方式；
4. 接口规约，字段名称、字段长度、字段类型
5. 接口变更，必须兼容老业务
6. 确认调用方的可信度，验证合法性、完整性、真实性，考虑限流、鉴权、越权等设计；
7. 判断接口是否需要高并发、大数据量压测，提前告知测试；

3.2 开发

3.2.1 消息

1. 是否允许消息重复，消息投递不保证不重复，订阅端需要依据业务属性做好幂等处理；
2. 是否允许消息丢失，如不允许，需要有核对机制；
3. 是否容忍消息乱序，如不允许，需考虑在消费端进行排序；
4. 是否允许消息延迟，如不允许，需考虑告警机制；
5. 消息处理异常时，不建议抛出异常，需catch异常，防止大量报错导致的堆积；
6. 不可丢弃的消息，考虑落表补偿或死信队列；
7. 配置合理的consumer线程数；
8. 引入消息，相比rpc调用，复杂度有增高，请在合理场景使用；
9. 对线上已存在的消息进行变更，应考虑兼容，避免消息消费方异常；

3.2.2 缓存

1. 是否可降级，考虑缓存失效或Redis不可用的情况；
2. 注意热key和大对象场景；
3. 是否需要预热，避免对DB的瞬时压力；
4. 是否大流量场景，防止缓存击穿；
5. 是否允许缓存的不一致，如果不允许，需要进行缓存同步（实时检查、定时检查）；

3.2.3 SQL

1. SQL查询必须指明要查询的字段，杜绝select *
2. 查询条件上要有索引，避免全表扫描影响数据库性能，且查询条件必须同DB字段类型一致，避免查询过程DB进行类型隐式转换造成索引不可用；
3. 注意分页查询，小心OOM；
4. 文本字段，注意是否会有特殊字符，如果需要支持特殊字符，需使用utfmb4格式，防止报错；

3.2.4 编码

1. 空指针异常不被允许；
2. 涉及到更新外部应用数据的，建议先落地本地数据，再发起请求，调用失败后有补偿、回滚机制；
3. cache代码块中，必须清晰打印日志，不能吃掉异常；
4. 代码报错后的处理措施；

3.2.6 工作流

1. 是否多机房部署，发布或切机房是否会影响；
2. 并发调用、多次调用的影响；
3. 未按时执行对业务的影响；
4. 是否可监控；

3.3 测试

3.4 发布

发布前，check发布流程；

发布中，分批灰度、监控；

发布后，观察、监控；

3.5 监控

1. 新服务需配置CPU、内存、NPE、异常量监控，关键业务异常可打点告警；
2. 线上数据的持续核对机制；

附一张技术风险领域大图