节点、边、方向
请求作为图的行走
请求触摸的每个组件都是一个 节点 : 客户端、DNS解析器、CDN边缘、反向代理、后端副本、数据库、缓存。
两个节点之间的每个连接都是一个 有向边 : 请求向前流动,响应向后流动。前向边表示打开的TCP连接及其上的协议。
一个请求是一个 路径 通过这个图。系统为了回答请求所做的总工作等于在每个节点上的工作之和,加上每条边的延迟。
为什么关心? 一旦绘制出图,代码中的属性就会显现出来:
- 跳数 : 路径中的有向边数量。每个跳都会增加延迟(网络回合.trip加节点处理)。跳数越少,延迟的下限就越低。
- 入度 : 指向一个节点的边数量。高入度意味着节点从多个源接收请求,并且必须扩展或保护自己。
- 出度 : 从一个节点指向下游的边数量。高出度意味着节点依赖于多个下游,而下游有很多故障方式。
- 切点 : 删除它后,图将被分离的单个节点。没有同行的反向代理是一个切点;删除它会删除对其源的所有访问。
流量的集中地
Fan-In = Concentration
In-degree of a node = number of edges pointing into it. In a request graph, in-degree = number of upstream sources that send requests.
Fan-in pattern: many clients -> one CDN; many CDN edges -> few origin proxies; many proxies -> fewer backend replicas; many backends -> single database.
Concentration matters because the highest in-degree node sees the most aggregate load. The DB at the end of the chain may see queries from every active request in the entire system, even if no single user generates much.
Fan-Out = Dependency
Out-degree of a node = number of edges pointing out of it. High out-degree means many downstream dependencies.
A backend that calls a database, two caches, three external APIs, & a queue has out-degree 7. Its success probability is roughly the product of each downstream's success probability (if all are required for a successful response).
0.999 ^ 7 ≈ 0.993: a backend with 7 downstreams each at 99.9% reliability can only achieve ~99.3% reliability itself, even with no bugs of its own.
Reduce out-degree by: caching downstream results, making non-critical downstreams optional (graceful degradation), parallelizing what can be parallel.
The Asymmetry
Fan-in concentrates load; fan-out multiplies risk. A well-shaped graph minimizes both at the highest-impact nodes.
The database (highest fan-in): cache aggressively to reduce load. Read replicas to spread fan-in across multiple nodes.
The orchestrator service (highest fan-out): circuit breakers per dependency, graceful degradation, bulkheads.
插入节点购买灵活性
Indirection = Adding an Intermediate Node
没有代理，图为：client -> backend。客户端必须知道后端的地址。移动后端需要更新客户端（通过DNS或配置）。这是一种紧密绑定。
有代理，图变为：client -> proxy -> backend。客户端只知道代理。移动后端需要更新代理的上游配置，而不是客户端。
图操作：在现有边上插入一个节点。新的边client -> proxy稳定；新的边proxy -> backend现在团队负责管理。
几何阅读：间接性增加了一层，解耦了上游变化与下游变化。每层的边可以独立重wire。
间接性成本
每层增加：
- 一跳延迟（客户端到代理的边）
- 路径上一个额外的切点（代理本身）
- 一个额外的地方可能出错
益处（重wire，扩展，屏蔽，终止TLS，分发负载）通常在任何非平凡系统中超过成本。但是有极限：每层间接性增加一个跳跃和一个SPOF候选者。
民间规则：任何问题都可以通过添加一层间接性来解决（除了太多层间接性的问题）。
将架构阅读为图
综合
你现在可以将系统架构阅读为图：计算跳数，识别切点，度量fan-in集中度，根据fan-out计算可用性天花板，并评估间接性交易-off。
应用所有四点。
一个新服务具有这样的架构：客户端 -> CDN -> 反向代理（2个副本） -> 后端层（8个副本） -> { 主数据库，缓存集群（3个节点），外部API }。
陪读笔记
陪读笔记
这个几何学的课重新把Proxies & Origins的主要课转化为一个有向图分析。
这个课程中的下一个陪读，geometry_of_stateless_horizontal_scaling，会从主要的扩展课中提取副本数学，并得出队列曲线、Little's Law和80%利用率弯的几何学。
好样的。