上一篇文章把需求、变更执行和独立的交付验证连接在同一个控制循环中。在那个例子里，新配置已经生效，但缓存仍然返回旧的清单文件（manifest）。
现在，我们继续深入到平台与具体组件之间的边界：现成机制通过适配器组合起来时，命令的原有含义能否保留下来？这里的新配置还没有激活，但加载成功已经被宣告为变更生效。
CDN 管理服务向 Varnish 加载一份新配置。针对 vcl_r1 的 vcl.load 成功，服务便把变更标记为已应用。然而，VCL 列表仍然显示 vcl_r0 处于 active 状态，客户端也仍然收到旧内容。
Varnish 完成的恰好是请求它执行的操作：编译并加载新 VCL。切换需要另一条命令 vcl.use。管理服务与 Varnish 之间的适配器丢失了这个区别，把加载称为激活。所选历史版本 7.6.5 的 CLI 文档和源代码明确区分这两种操作。[1, 2]
即使每个开源组件都正常工作，这种断裂也可能出现在组合中。各组件有自己的机制，也有自己对“成功”的定义。平台需要保留这些含义，把它们与获准执行的变更关联起来，并明确验收结果还需要哪些依据。
下面以 Apache Traffic Control、Varnish、NGINX 和 Envoy 为例，讨论职责如何分配：哪些能力直接复用，哪些边界通过集成连接，哪些缺失逻辑需要补充。先从一个节点开始，这样，无须展开全球 CDN 的结构，也能看清适配器错误及其修正方法。
一个节点和一次变更
在所选组合中，NGINX 接收 HTTPS 请求，并将请求转发给一个 Varnish。NGINX 的缓存关闭。Varnish 从两个源站中选择一个，并缓存响应。独立的控制器（controller）保存当前有效的需求和变更权限，其适配器执行 Varnish 命令。
验证客户端（verifier）经过同一个 HTTPS 前端和 Varnish 发出请求。它从独立的需求责任方（authority）获取预期字节。适配器不能从被检查节点的响应中为自己生成成功标准。控制器对照执行结果和验证结果，另行决定是否验收这个步骤。
把需求记为 I1：用于有限范围金丝雀验证（canary）的命名空间 /canary/a16/ 下，新请求应转向源站 O_B，并返回已知的清单文件响应体 M_B。源站 O_A 返回不同的响应体 M_A。正在工作的 VCL vcl_r0 选择 O_A。准备好的 vcl_r1 只改变金丝雀验证命名空间内的源站选择，转向 O_B，同时保留其他规则。
这里有两个作用范围。需求只涉及金丝雀验证命名空间，而 vcl.use 会切换整个缓存节点的 active VCL。因此，控制器必须另有当前有效的节点 VCL 激活权限。准备配置产物时，还必须确认金丝雀验证范围之外的行为保持不变。修改一个 URL 的权限和一次响应体匹配，都不能证明这两点。
为了让例子隔离出适配器边界，约定以下模型条件：
- 只使用一个选定的 Varnish 实例，每个修订对应一份 VCL；没有 includes、VMOD 依赖、labels、
return(vcl(...))或额外的 fallback 机制。没有其他管理主体、重启或 VCL 名称复用；所选探测请求也没有沿用旧的未完成事务。两个可用源站的地址固定。 - NGINX 保留 GET、Host 和路径。Host 显式设置为
proxy_set_header Host $http_host；proxy_pass不带 URI，没有 rewrite 或内部重定向。这项配置有实质意义：NGINX 默认向上游传递$proxy_host，而不是原始客户端 Host。[3] - 在
Accept-Encoding: identity下比较 HTTP 200 的完整响应体，没有 Cookie、Authorization、Range、条件请求、重定向或前端对响应体的转换。两个源站都返回固定字节、可正常缓存的清单文件。 - 反例探测和修正后的探测使用同一命名空间内的不同路径 U− 和 U+。实际生效的 Varnish hash 保留 Host 和完整路径，不把这两个路径合并为同一个键。两个键确实都是冷键：此前没有请求过它们，也没有预取或并发填充。Varnish 的标准 hash 使用 URL 和 Host，但仍需单独确认所选配置的实际行为。仅仅使用一个新 URL，不能保证得到冷键。[4]
每次探测都经过普通前端和缓存路径。使用不同的冷键，使第二次探测能够检查修正后的顺序，而不会命中第一次探测可能缓存的 M_A。
加载如何被误当成应用成功
在这个条件明确的反例中，适配器加载 vcl_r1，跳过 vcl.use，却为 I1 返回平台状态 applied=true。
| 步骤 | 获得的依据 | 可以得出的结论 |
|---|---|---|
vcl_r1 的 vcl.load 成功 |
原生加载操作的回执 | vcl_r1 已编译并加载 |
适配器报告 applied=true |
同一份回执，没有切换 | 这些依据不足以支持该平台状态 |
新鲜的状态回读显示 active vcl_r0、available vcl_r1 |
给定模型中所选实例的状态 | 新 VCL 没有成为 active VCL |
| 普通请求 U− 收到 M_A | 在预期为 |
337
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
