摘要

  • RFC 10053 允许 CATS 根据网络和计算信息选择面向客户端的服务接点。一个接点可以承载一个或多个内部服务实例，因此选中接点并不等于识别出最终处理请求的实例。
  • 接点指标可能聚合多个服务实例；服务度量代理也可能再聚合多个接点。选定路径或看似稳定的汇总值，说明的是流量引导界面，而不是某次请求的后端执行记录或服务结果。

看得见入口，不代表看得见处理过程

设想一项在线地图路线规划服务。用户把请求发往一个服务标识，流量引导系统比较两个站点：一处网络路径更短，另一处有更多可用算力。系统选择一个可达的服务接点，并把请求送到那里。对客户端而言，这就是服务入口；接点可能亲自处理请求，也可能再决定由哪个内部实例执行。

RFC 10053 有意区分这两个概念。服务实例是依照服务商逻辑协同运行的一组资源。服务接点则是面向客户端、负责接收请求的功能，可以处理一个或多个服务实例，也可以把请求分派到它们那里，类似负载均衡器。RFC 明确指出，接点之后的引导过程对客户端和 CATS 组件都不可见。

因此，“CATS 选中了服务”需要说清楚范围。CATS 路径选择器（C-PS）综合服务度量代理和网络度量代理提供的信息，选择一个出口 CATS 转发器，可能还会选择服务接点，并确定流量路径。它决定请求从服务商架构的哪个入口进入；单凭这一步，无法确认实际执行任务的内部实例。

指标有范围，而且可能一层层汇总

RFC 10053 特别提醒，选择结果未必能揭示客户端最终调用的服务实例，在分层或递归结构中尤其如此。因此，服务接点的指标可能是多个服务实例的聚合值。第 4.2 节还允许 CATS 服务度量代理汇总多个服务接点的指标、分别保留这些指标，或两者兼用。这是两个不同的汇总层次：一层可能把同一接点背后的实例状态合在一起，另一层则可能在向选择器发布前合并多个接点的状态。

聚合本身不意味着指标是错的，而是要求读者知道指标描述什么。接点级平均值可以帮助选择入口，却未必反映尾部时延、某次请求被分配到的实例，或该请求的最终结果。站点级汇总值也可能提升引导系统的可扩展性，但它不是每个接点的独立测量。RFC 把部署选择留给服务商，没有规定唯一的选路算法。

CATS 流量分类器可以让同一请求的分组继续发往已选接点。第 4.4 节描述了接点实例亲和性：同一流量的分组沿相同路径到达同一接点，以减少乱序和不可预测的时延变化。这是一项转发属性，却不会让接点内部的分派过程变得透明。框架没有定义一种记录，把每次 CATS 选择与后端实例及请求结果逐一对应起来。

例如，一个接点把路线规划请求分配给多个内部计算实例。如果其中一个因负载变化而变慢，汇总后的接点指标仍可能看起来正常。CATS 可能继续选择该接点，却观察不到不均衡，也无法知道哪些请求受到影响。这是从 RFC 所述可见性边界推导出的可能后果，不是某个运营商的已知事故或实测结果。

这种职责划分是有意为之。RFC 10053 说明，服务商保留对内部资源和服务逻辑的控制权；服务商如何组织服务不属于 CATS 的范围。CATS 把网络状态与计算资源用于流量引导，但它不是检查服务商后端调度器的规范。网络运营者不应从有限信号中推断更多；服务商也不应把一个被选中的接点说成某次请求成功执行的证据。

RFC 10054 扩展了 CATS 的问题陈述与要求；本文的问题更窄：流量到达所选接点后，我们还能知道什么？答案取决于服务商愿意另外提供哪些遥测和记录。两份 RFC 都没有要求通用的后端分派 API、逐请求追踪或结果回执。部署可以自行补上这些控制，但必须另行验证它们是否存在。

若无额外证据，证据链就止于接点

当一次引导调整似乎降低了时延、应用团队却发现结果不稳定时，这个区别就会影响运维判断。路由和接点选择可以解释分组被送往何处；若没有服务商侧证据，它们无法说明哪个内部实例处理了请求、该实例是否依赖已退化的组件，或响应是否达到服务目标。

严谨的报告可以说：“CATS 根据这些指标及其范围选中了这个接点。”要说“这个后端成功处理了这次请求”，需要服务侧证据。要说“服务有所改善”，则需要与相关请求或用户群体对应的结果指标。即使之后把这些证据合并到同一套观测系统中，它们仍是不同的判断。

RFC 10053 是一个只覆盖单一服务商的架构框架。它没有规定确切的选路算法，也没有标准化服务商的内部服务设计。它解释了流量引导的边界，并未承诺所选接点会暴露后续发生的每个决定。

来源与范围