FA18# 中间件稳定性治理内容提点

引言

以业界一公司的故障举例，由于强依赖缺少降级方案造成比较大的故障。

在早上8点到10点、下午5点到8点为业务高峰，也就是上下班高峰期。

容器团队通过弹性调度在低峰区缩容、高峰期扩容。

容器pod的重建依赖一个摘流系统。

摘流负责发布前流量的拉出、发布后流量的拉入。

摘流系统依赖CMDB去检查应用的合法性。

故障发生在CMDB系统出现假死、整个CMDB无法访问。

‍摘流系统无法访问CMDB、流量的拉入拉出失效。

在高峰期容器弹性扩容后、无法引入流量、导致大量服务不可用。

反思改进，  容器弹性扩缩容强依赖摘流系统、缺少摘流系统异常的降级应对方案。

反思改进，  摘流系统强依赖CMDB系统、缺少CMBD异常后的降级措施。

反思改进，容器弹性扩缩容是后来新增能力，未对依赖的上下游方案通盘走查，是否存在强依赖以及应对措施。

当故障出现时，5分钟发现、5分钟定位、10分钟恢复，5-5-10。

架构设计上避免故障发生对业务的影响。

例如：RocketMQ主从跨可用区交叉部署。

例如：Kafka核心服务3个副本。

例如：注册中心/配置中心等本地磁盘/缓存容灾设计。

提供容灾迁移能力，当故障发生时迁移到灾备集群。

常备低水位容灾集群、一键/自动迁移到灾备集群。

完善SOP应急手册、人员互备实时Oncall。

应急恢复演练达到或不断逼近10分钟。

为什么需要重视故障演练？

提高容错性、可恢复性、验证高可用能力。

验证关键指标等告警的时效性。

应急操作恢复的时效演练。

场景：磁盘IO、CPU飙高、磁盘损坏、节点宕机、主从切换、网络分区等。

符合预期，心里有数。

不符预期，强化改进。

不同等级中间件需符合停留期要求。

变更范围由小到大验证。

变更从非核心服务到核心服务验证。

中间件变更需要整理文档，变更文档需要织评审。

满足可监控、可应急、可灰度基本要求。

变更单需要审批流程。

每个组件梳理完善关键指标。

吞吐QPS、连接数、节点数量、响应时间、节点可用性、硬件指标水位。

确保指标监控告警畅通有效。

每周定期巡检确保水位正常。

定期复盘线上涉及中间件的案例。

业界的典型案例分析并沉淀文档。

举一反三其他组件和场景。

把别人的经验变成自己的。

反思自身组件需要提高的点。

变更须组织CR并落实记录。

记录CR文档，例如：需求、分支、代办改进项。

强化代码评论，注意评论与代码对应。

使用CR工具，例如：GitLab Merge Requests

先讲解代码结构与主流程。

静默阅读对代码做出评论。

互备同学主评/其他人参评。

讲解人对评论解释和答疑。

总之，不断尝试更为有效的CR方式。