阿里是如何抗住双11的？看完这篇你就明白了!(4)

关于健康检查，主要就分为“服务端轮询”和“客户端主动上报”两种模式，总的来讲各有优缺点，对于类似 MySQL 这类服务是无法主动上报的(除非借助第三方代理)。需要注意的是传统基于端口的健康检查很难识别“进程僵死”的问题。

提到监控那就不得不提 Google SRE 团队提出的监控四项黄金指标：

延迟：响应时间

流量：请求量、QPS

错误：错误数、错误率

饱和度：资源利用率

类似的还有 USE 方法，RED 方法，感兴趣的读者可以自行查阅相关资料。

云原生时代通常是应用/节点暴露端点，监控服务端采用 Pull 的方式采集指标，当前比较典型的就是 Prometheus 监控系统，感兴趣的可以详细了解。

当然，以前也有些监控是通过 Agent 采集指标数据然后上报到服务端的。

除了监控自身，告警能力也是非常重要的。告警的阈值配多少也需要技巧，配太高了不灵敏可能会错过故障，配太低了容易“监控告警疲劳”。

强弱依赖治理

这是网上找的一张“系统依赖拓扑图”，可见面对这种复杂性，无论是通过个人经验，还是借助“链路跟踪工具”都很难快速理清的。

何为强弱依赖?A 系统需要借助 B 系统的服务完成业务逻辑，当 B 挂掉的时候会影响 A 系统中主业务流程的推进，这就是“强依赖”。

举个例子：下单服务依赖“生成订单号”，这就是“强依赖”，“扣库存”这也是 “强依赖”。

同理，当 A 依赖的 B 系统挂掉的时候，不会影响主流程推进，那么就是“弱依赖”。例如：购物车页面中显示的库存数是非必须的。

如何梳理出这种强弱依赖，这个在阿里内部是有专门的中间件可以做的，目前开源社区没有替代品，可能就要结合链路跟踪+个人的经验，针对系统级，接口级去做链路梳理。

我们重点关注的是 “强依赖”，而“弱依赖” 通常是可以执行容灾策略的，例如：可以直接降级掉，可以返回为空或者默认值、执行兜底等。

总结出来关键有几点：当前业务功能/应用/服务、依赖的服务描述、依赖类型(比如：RPC 调用)，峰值调用量、链路的流量调用比例、强弱等级、挂掉的后果等。

容量规划

容量规划是非常重要的，无论是成本控制还是稳定性保障都需要。否则压根不知道需要投入多少资源以及资源投入到哪里。

需要了解系统极限水位在哪里，再推算出合理的“阈值”来做好“过载保护”，这也是执行是限流、降级等预案体系的关键依据和基础。

第一阶段：主要依靠经验值、理论值等来预估的，或者是靠“拍脑袋”的

前几年资本市场情况比较好，互联网公司比较典型的现象：老板，我需要买 100 台服务器，50 台跑应用，20 台跑中间件，10 台做数据库…预计可以扛住日均 1000W 访问量，每天 100W 订单…

靠谱一点的人还能扯出 “MySQL 并发连接数在几 core 几 G 大概能到 xxx”、 “Redis 官方称可以达到 10W TPS”之类的参考值，这种至少听起来还有那么一点道理。

不靠谱的人呢?那可能就真是瞎说的一个数字，或者会说“我上家公司就用了这么多支撑的”，其实纯靠拍脑袋的。

总之，这都是很不靠谱的，会造成资源分配不合理，有些浪费而有些饥荒。

第二阶段：通过线下压测手段来进行

线下压测通常是压测的单接口、单节点，压测结果可以帮助我们了解应用程序的性能状况、定位性能瓶颈，但是要说做整体的容量规划，那参考价值不大。

因为实际情况往往复杂太多，网络带宽、公共资源、覆盖场景不一致、线上多场景混合等各种因素。

根据“木桶短板”的原理，系统的容量往往取决于最弱的那一环节。正所谓 “差之毫厘，失之千里”。

第三阶段：通过线上单机压测来做

比较常见的手段有：线上引流、流量复制、日志回放等。其中线上引流实施起来最简单，但需要中间件统一。

通过接入层或服务注册中心(软负载中心)调整流量权重和比例，将单机的负载打到极限。这样就比较清楚系统的实际水位线在哪里了。

第四阶段：全链路压测，弹性扩容

（编辑：ASP站长网）