谈谈 Go 服务稳定性建设 万俊峰Kevin kevwan@github About me go-zero 作者 • 阿里云MVP • 腾讯云TVP • ArchSummit 明星讲师 • GopherChina 主持人&金牌讲师 • 极客时间 Go 专题出品人 • 腾讯云开发者大会讲师 TOC 稳定性的定义 Go 服务稳定性手自 稳定性的度量 Go 服务监控告警 Go Go 服务排障 稳定性定义 可用性 正确性 延迟 ’ alt=‘OCR图片’/> Go 服务稳定性手段 需求合理性 技术方案简洁性 code review 单元测试 自动化回归 稳定性手段 正确性（涉及到钱的服务） 幂等 至少一次 保序 浮点精度 (decimal) 正确性校验机制 稳定性度量 可用性 时间纬度 时间纬度 请求成功率 稳定性度量 正确性（涉及到钱的服务） 财务对账系统 安全风控 稳定性度量 时延 Average P50 P99 P99.9 ’ alt=‘OCR图片’/> Go 服务监控告警 具 • Prometheus • 基础指标需要自动上报 • 业务指标按需上报（但要使用便捷） • OpenTelemetry • 链路不能断 • 消息、电话 • 普通告警消息

jpg) 自动化支持程度低 很多重要的用例没法自动化 编写和维护脚本的投入甚至超过了人工测试的成本 平台搭建成本高 需要招聘专门的测试开发人员，花费大量的研发经费。 ## 日 系统稳定性差 脚本编写成本高 脚本不够鲁棒，设备经常断开连接。  场景 兼容性测试 性能测试 问题 功能回归测试 收益 技术 解决方案 自动化支持程度低 脚本编写成本高 平台搭建成本高 系统稳定性差 Airtest AirtestIDE AirLab DeviceFarm 开源项目 节约成本 私有化部署 完善流程 云测试平台 保障质量 ![Image](/uploads

alt=‘OCR图片’/> 现代微服务架构的挑战 用好微服务的挑战：稳定性 ’ alt=‘OCR图片’/> 现代微服务架构演进 微服务N大件：服务提供者，服务消费者，注册配置中心，微服务治理 对微服务体系中的各个组件、环节进行稳定性治理，是把微服务做稳做好的必不可少的一环 ’ alt=‘OCR图片’/> 微服务治理划分：全生命周期的稳定性治理 开发态与测试态 服务契约 服务调试 端云互联 金丝雀发布 A/B Test 全链路灰度 运行态 稳定性 应用自身稳定性风险 不确定流量（流控、热点防护） 不稳定调用（熔断、隔离） 不稳定架构与基础设施（容灾多活） 安全 服务鉴权 服务零信任 Kratos CloudWeGo 服务框架 据调研数据 70%的线上问题都是由于变更导致的 运行时稳定性问题更是防不胜防 ’ alt=‘OCR图片’/> 全链路流量治理（漏斗模型） alt=‘OCR图片’/> 核心场景1：全链路灰度控制消除变更态稳定性风险 安全变更三板斧：可灰度、可监控、可回滚全链路灰度是控制变更影响面，保障变更稳定性的必不可少的能力 灰度规则：按流量特征（如 uid）或按流量比例 全链路灰度 = 流量染色+流量路由+全链路全方位框架的支持 ’ alt=‘OCR图片’/> 核心场景2：流量防护与容错保障运行时稳定性 激增流量 激增流量导致系统CPU/Load飙高，无法正常处理请求

uments/3/9/f/8/39f8f7059b648c5287e5e0d148b942ed/p11_4.jpg) 技术架构变化：因商业或者演化而变带来不稳定因素 非云原生：无法对应变化=稳定性无法保证 人员变化：没有知识沉淀导致的不稳定因素   云原生：主动对应变化=稳定性保证   配置变化：因环境而变带来的不稳定性因素 - 落地的核心问题：业务微服务的划分和设计(DDD, 咨询方案等)、部署困难、维持运行困难、云资源管理与应用管理视角分离导致复杂性等 - 传统方案:仅仅考虑了一部分变化而引起的不稳定，如通

rowspan="3">稳定性集群类稳定性用来评估 k8s 集群本身的稳定性产品类稳定性用来评估产品各组件的稳定性系统类稳定性用来评估 kernel、docker 等系统底层等对产品稳定性的影响稳定性。  ## 1 ## 混沌工具 ## a1b9a259d779bfeba7888af7c5c/p24_2.jpg) For Chaos Mesh, 通用组件的开箱即用；比如 Redis、Kafka 等等 欢迎对混沌测试，对私有云稳定性感兴趣的同学一起关注云原生社区 stabilitySIG、Chaos Mesh 社区和网易伏羲～ 云原生社区