又一手机厂商不再附赠充电器

衡量指标

不同业务所提供的服务类型千差万别，如何用一致的指标去衡量系统稳定性?标准做法是定义服务的可用性(Availability)：只要对用户而言服务“可用”，那就认为系统当前是稳定的;否则就是不稳定。用这样的方式，采集和汇总后就能得到服务总的可用/不可用比例(服务时长 or 服务次数)，以此来监测和量化一个系统的稳定性。

可是，通过什么来定义某个服务当前是否可用呢?这一点确实跟业务相关，但大部分同类业务都可以用类似的方式去定义。例如，对于一般的 Web 网站，我们可以按如下方式去定义服务是否可用：API 请求都返回成功，且页面总加载时间 < 3 秒。

对于阿里云对外提供的云产品而言，服务可用性是一个更加需要格外重视并持续提升的指标：阿里云上的很多用户会同时使用多款云产品，其中任何一款产品出现可用性问题，都会直接被用户的用户感知和放大。所以，越是底层的基础设施，可用性要求就越高。关于可用性的更多细节指标和概念(SLI / SLO / SLA)，可进一步参考云智能 SLA 了解。

可用性测量

有了上述可用性指标定义后，接下来该如何去准确测量系统的可用性表现?一般有如下两种方式。

1)探针模拟

从客户端侧，模拟用户的调用行为。

• 优点：数据真实(客户端角度)
• 缺点：数据不全面(单一客户数据)

2)服务端采集

从服务端侧，直接分析日志和数据。

优点：覆盖所有调用数据。

缺点：缺失客户端链路数据。

对可用性数据要求较高的系统，也可以同时运用上述两种方式，建议结合你的业务场景综合评估选择。

优化原则

你应该做的：关注 RT 的数据分布(如：p50/p99/p999 分位点)，而不是平均值(mean) —— 平均值并没有太大意义，更应该去关注你那 1%、0.1% 用户的准确感受。

你不应该做的：不要尝试承诺和优化可用性到 100% —— 一方面是无法实现，存在太多客观不可控因素;另一方面也没有意义，客户几乎关注不到 0.001% 的可用性差别。

优化手段

常用的稳定性优化手段有哪些?这里也总结了 8 个套路：

1)避免单点

父母：一个人在外漂了这么多年，也该找个人稳定下来了。

如何避免?

• 集群部署
• 数据副本
• 多机房容灾

只堆量不够，还需要具备故障转移能力(Failover)。

• 接入层：DNS、VipServer、SLB。
• 服务层：服务发现 + 健康检查 + 剔除机制。
• 应用层：无状态设计(Stateless)，便于随时和快速切换。

2)流控/限流

计划生育、上学调剂、车牌限号、景区限行... 人生处处被流控。

• 类型：QPS 流控、并发度流控。
• 工具：RateLimiter、信号量、Sentinel。
• 粒度：全局、用户级、接口级。
• 热点流控：避免意料之外的突增流量。

3)熔断

上午买的股票熔断，晚上家里保险丝熔断... 淡定，及时止损而已。

• 目的：防止连锁故障(雪崩效应)。
• 工具：Hystrix、Failsafe、Resilience4j。
• 功能：自动绕开异常服务并检测恢复状态。
• 流程：关闭 → 打开 → 半开。

4)降级

没时间做饭了，今天就吃外卖吧... 对于健康问题，还是得少一点降级。

触发原因：流控、熔断、负载过高。

常见降级方式：

• 关闭非核心功能：停止应用日志打印
• 牺牲数据时效性：返回缓存中旧数据
• 牺牲数据精确性：降低数据采样频率

（编辑：保山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!