流量到达之前就识别出瓶颈节点
中心性之间性
在一个图中,对于每一对节点,都有一个最短路径将它们连接起来。节点N的中心性之间性 = 所有最短路径中穿过N的比例。
中心性之间性高的节点在许多其他对的路径上。 如果它慢下来,许多流量就会慢下来。如果它失败,许多流量就会中断。
架构阅读: 高中心性之间性节点是每次架构审查都应该额外关注的对象。它们是瓶颈,单点故障,并且在一个方面是容量关键的组件。它们往往是:
- DNS提供者(在每个客户端与每个服务之间)
- -ingress代理(在每个客户端与每个后端之间)
- 主数据库(在每个后端与每个读操作之间)
- 认证服务(在每个用户与每个授权操作之间)
检测无需测量: 图的拓扑结构可以识别出高中心性之间性节点。你不需要流量数据;你需要的是架构图。一个节点如果在许多其他对的路径上,它是结构上关键的。
运营后果: 高中心性之间性节点应得到不成比例的投资,包括(1)容量预留,(2)冗余,(3)可观察性和(4)事件响应playbooks。
最小切割将最小部分分开
最小切割定理简明术语
在两个节点之间的图的最小切割 = 你必须移除的最小数量的边(或节点),以将它们分开。
操作性阅读: 最小割限制了最坏情况下的爆炸半径。如果 '客户' 和 '数据库' 之间的最小割是 1 边（一个单独的代理），那么失去那个边就会断开所有客户与数据库的连接。如果最小割是 5，你需要同时失去 5 个组件才能完全断开；糟糕运气，但有界。
为爆炸半径设计: 在每个重要边界处增加最小割。多个代理；多个缓存节点；DCs 之间的多条网络路径。每次添加都提高最小割值 1。
图表模式在图形术语中的应用: 将资源划分为不相互共享最小割的独立子图。一个子图内的故障无法传播到其他子图，因为边不存在。
直径设置故障传播距离
图直径 = 任意两个节点之间的最长最短路径。
故障传播: 当一个节点失败并尝试将流量回退时，它们会触摸上游节点，直到距离直径的距离。一个直径为 3 的系统（客户 -> 代理 -> 后端 -> DB）意味着 DB 故障会影响 3 层上游层次的重试风暴。
启示: 直径越短，故障隔离速度越快，但也意味着节点集中度越高。每个设计都有其权衡。
计算真实架构的最小割
一个架构：1 个 DNS，1 个 CDN，3 个反向代理，12 个后端副本，1 个 DB 主库。
通过图形度量进行故障模式审计
综合
你现在可以识别出高之间性节点，计算每个边界的最小割，并通过直径估算故障传播距离。
应用所有三个。
系统：50个客户端终端 -> 1个DNS -> 2个CDN POPs -> 4个反向代理 -> 16个后端副本 -> {DB集群（1个主节点+2个从节点），Redis集群（5个节点），3个外部API。}
陪衬笔记
陪衬笔记
这个几何学的课堂通过图形指标（边界性、最小割、直径）重新阐述了失效模式与爆炸半径的主要课堂。
最后一个陪衦，geometry_of_observability_and_capacity，讨论了CDN POP抓取范围的Voronoi单元，延迟三角形的光速底部，以及代理层重新审查的排队曲线。
很棒。