分布式系统稳定性建设-架构设计篇_系统稳定性建设方案-CSDN博客

本文链接：https://blog.csdn.net/baidu_32452525/article/details/143810478

分布式系统稳定性建设-架构设计篇

系统稳定性建设是系统工程的核心内容之一。以下是一些重要的方面:

架构设计:
- 采用模块化、松耦合的架构设计,以提高系统的可扩展性和可维护性。
- 合理划分系统功能模块,降低单个模块的复杂度。
- 定义清晰的接口和数据交换标准,确保各模块之间协调工作。
- 监控与报警:
  - 部署全面的监控体系,实时跟踪系统的运行状态和关键指标。
  - 建立完善的告警机制,及时发现并定位系统问题。
容错机制:
- 建立完善的异常处理和容错机制,及时检测并隔离故障,防止故障传播。
- 实现关键功能的冗余备份,提高系统的可用性。
- 设计自动恢复和自修复机制,缩短系统故障的恢复时间。
性能优化:
- 进行系统性能测试和瓶颈分析,确定系统的承载能力。
- 优化关键模块的性能,提高系统的整体响应速度。
- 采用缓存、异步处理等手段,缓解系统的瞬时压力。

架构设计

研发阶段主要参与人员是研发，主要产出物是技术方案设计文档和代码，一个是研发阶段的开始，一个是研发阶段的结束，我们要把控好技术文档和代码质量，从而减少线下bug率及线上的故障。

技术方案评审

技术文档的评审需要有本团队的架构师和相关研发，测试，产品，上下游系统的研发同学参与；
确保我们的实现和业界最佳实践的差异，确保合理性，避免过度设计；我们所要做的是开放心态采取大家的意见，严控技术文档的质量；
技术方案关注点：
- 限流：计数器算法，滑动时间窗口算法，漏斗算法，令牌桶算法
- 熔断降级
  - 熔断和降级是两件事情，但是他们一般是结合在一起使用的。熔断是防止我们的系统被下游系统拖垮，比如下游系统接口性能严重变差，甚至下游系统挂了；这个时候会导致大量的线程堆积，不能释放占用的CPU，内存等资源，这种情况下不仅影响该接口的性能，还会影响其他接口的性能，严重的情况会将我们的系统拖垮，造成雪崩效应，通过打开熔断器，流量不再请求到有问题的系统，可以保护我们的系统不被拖垮。
  - 降级是一种有损操作，我们作为服务提供者，需要将这种损失尽可能降到最低，无论是返回友好的提示，还是返回可接受的降级数据。降级细分的话又分为人工降级，自动降级。
    
    人工降级：人工降级一般采用降级开关来控制，公司内部一般采用配置中心Ducc来做开关降级，开关的修改也是线上操作，这块也需要做好监控；
    
    自动降级：自动降级是采用自动化的中间件例如Hystrix，公司的小盾龙等；如果采用自动降级的话；我们必须要对降级的条件非常的明确，比如失败的调用次数等。
- 高可用：
- 超时：可根据线上TP99耗时）
- 重试：写接口重试一定要做好接口的幂等性、指数回退重试
- 兼容：
  - 向前兼容性：向前兼容性指的是旧版本的软件或硬件能够与将来推出的新版本兼容的特性，简而言之旧版本软件或系统兼容新的数据和流量。
  - 向后兼容性：向后兼容性则是指新版本的软件或硬件能够与之前版本的系统或组件兼容的特性，简而言之新版本软件或系统兼容老的数据和流量。
- 隔离：隔离是将故障爆炸半径最小化的有效手段，可以通过系统隔离、环境隔离、数据隔离、核心，非核心隔离、读写隔离（CQRS）等手段
代码Review

codeReview是研发阶段的最后一个流程，对线下的bug率和线上质量及稳定性有着重要的作用，针对于代码如何review，谈一些自己的看法：
- 形成团队代码风格：首先一个团队的代码应该形成该团队的代码风格，这样能够提高codeReview的效率及协作的效率，作为新加入的成员，应该遵循团队的代码风格规范。
- Review的关注点：代码review切记不要陷入细节，主要以review代码风格为主，如果一个团队形成统一的代码风格，我们通过review风格就能将大部分问题发现，在关注功能的同时，再关注下性能，安全。
- 结对编程：在代码编写过程中，我们要培养结对编程的习惯，这样针对某次需求，codeReview时，熟悉该模块的同事把控下细节，架构师把控风格。
- 控制每次review代码量：每次提交代码进行review时，不要一次性提交review大量的代码，要将review的内容细分，比如一个方法的实现，一个类等。
- 开放心态：review的过程其实是学习提升的过程，通过代码review，虚心接受别人的意见，学习优雅代码的编写方式，提高自己的代码水平。

上线阶段

上线三板斧

可监控：对业务指标和技术指标（可用率，TP99, 调用量）进行监控和告警，无聊时业务指标还是技术指标，都需要能达到能够监控业务或者技术的可用性，性能，并发。
可灰度：通过灰度执行变更以限制爆炸半径，降低影响范围，同时灰度过程要做好兼容。灰度分为不同维度的灰度：机器维度，机房维度，地域维度，业务维度：用户，商家，仓，承运商等。
可回滚：线上出现问题时，我们应该优先止损，其次才是分析根因。止损的最快方式就是回滚，回滚分为代码回滚和数据回滚。
- 代码回滚即将我们代码恢复到原有的逻辑，代码回滚有两种方式：开关控制和部署回滚。最快捷的方式是开关控制，一键开关打开或者关闭就可以实现回滚到原有的逻辑，操作成本最低，止损最快速。
- 第二种方式就是部署回滚，通过发布平台，例如行云将代码回滚到上个稳定运行的版本。有时候我们代码回滚完，如果没有做好向前兼容性，系统应用依然有问题，例如上线过程中产生了新数据，回滚完后，代码不能处理新的数据。所以这个时候又涉及到数据的回滚，数据的回滚涉及到修数：将产生的新数据无效掉，或者修改为正确的数据等，当数据量比较大时，数据的回滚一般耗时费力，所以建议做好向前兼容性，直接代码回滚。

人员能力培养

单个技术同学个人技术以及稳定性保障能力是团队在每个稳定性任务上拿到结果的执行者和基础，因此技术主管重视识别不同同学个人优势和不足，针对性做工作安排以及培养锻炼。

只要线上意识上足够重视，能力对于大部门技术同学是可以培养的。

团队内同学由于入行时间、历史经验等各方面原因，对于当前系统稳定性保障能力是有强弱的差异的，对于个人是正常情况，但对于团队而言，不能因为团队个别同学能力上存在不足而引入团队层面稳定性保障风险。

需要主管很好熟悉以及判断同学能力段位，在负责系统和模块、流程机制约束、辅导人等方面做好差异化安排。

例如校招同学X个月不做线上发布，前X个月发布有师兄协同发布机制，并发高或资金交易等等风险高的系统让更加有经验的负责。

同时设计培养机制，能力当前不足但有潜力的同学，可以安排由经验丰富的同学指导以及提供一些进阶实操路径，按照节奏从易到难逐渐承担更高风险的系统职责。

能力培养方式有技术Review、代码CR和辅导、参与团队稳定性保障机制、安排合适师兄指导、过程中主管指导、逐渐承担更高职责等。

监控报警

日常巡检

系统的监控与报警能够一定程度发现系统存在的问题，系统存在的一些隐患需要通过对系统的巡检去发现，如果优化不及时在极端情况会导致故障，巡检粒度建议每周巡检一次自己所负责的业务系统。

系统巡检重点要关注如下几点：

系统指标：系统 CPU、负载、内存、网络、磁盘有无异常情况波动，确认是否由发布导致，还是系统调用异常。
慢接口：通常 RT 大于3s的接口需要重点关注，极端并发场景下容易导致整个系统雪崩。
慢查询：MySQL 慢查询需要重点关注，随着数据量上涨，需要对慢查询进行优化。
错误日志：通过错误日志去发现系统隐藏的一些 BUG，避免这些 BUG 被放大，甚至极端情况下会导致故障。

必须控制无效报警的数量，例如单应用无效报警（不需要线上问题进行定位以及修复处理的）不要超过5条，个人维度无效报警天级别不超过10条。

线上问题应对

常见问题分类

根据图片内容，我将生成对应的Markdown表格：

分类	子类	细分
应用	业务逻辑错误
	并发问题
	幂等问题
	状态机问题
	上游业务逻辑问题/接口报错
	接口兼容问题
	…
存储	数据库	主从延迟
		慢sql
		大事务
		死锁
		分页错误
		…
	缓存	缓存击穿
		缓存穿透
		缓存雪崩
		大key
		热key
		数据一致性
		…
	ElasticSearch	分片数量设置不合理
		分片数量超过集群上限
		慢查询
		写入后立马查询
		一次性写入数据量过多，过大
		…
中间件	系统升级
	消息积压
	使用方式不当
	没有做好降级
	…
安全	越权访问
	SQL注入
	DDos攻击
	…
流程	上线流程
	数据库变更
	配置变更
	…

问题生命周期

故障处理生命周期：

发生 - 问题初次出现的阶段
发现 - 问题被发现和确认的阶段
响应 - 开始采取行动的阶段
定位 - 确定问题根源的阶段
修复 - 解决问题的阶段
复盘 - 总结经验教训的阶段

每个阶段都对应一个关键问题：

如何预防问题发生，我们可以从研发的规范，研发的流程，变更流程这几个方面进行预防。

类	子类
研发流程	明确需求
	充分自测
	codeReview
	QA测试
	线上回归
研发规范	代码规范
	日志规范
	数据库规范
	分支规范
	依赖规范
变更流程	业务低峰期变更
	上线checkList double check
	线下验证后再上线
	日志和指标监控
	适当增加降级开关
	做好回滚预案

如何及时发现问题

对于问题发现的渠道，工作中接触到的有如下几种：自我意识，监控告警，业务反馈；

自我意识：每周对核心接口的不规律跳点，毛刺进行可用率，性能，调用量的review，以通过这种主动的，自我意识行为发现潜在的线上问题。每周会对上周核心接口的可用率，TP99，调用量，进行分析的，对于可用率降低，TP99有毛刺，不规范的流量调用会进行排查原因，尽早自我发现问题，同时也会对机器的CPU, 内存使用率，Mysql, redis , es各种存储进行review。

监控告警：发现问题最常用的渠道，通过主动的监控指标，被动的接收告警来发现问题，告警指标我们分为业务指标和技术指标，具体可以见上文。

业务反馈：这种发现问题的方式是我们最不愿意看到的，如果等到业务反馈，说明线上问题已经影响到用户，我们常常因为监控告警的缺失，漏报而导致落后于业务发现问题，所以我们最希望每个人，团队都有这种自我意识，将线上问题提早发现，防患于未然。