Skip to content

3.0: local proxies and contract-aware call admission (#775) - #802

Closed
SunSi12138 wants to merge 1 commit into
devfrom
wip/775-contract-admission-recovery
Closed

SunSi12138 wants to merge 1 commit into
devfrom
wip/775-contract-admission-recovery

Conversation

@SunSi12138

Copy link
Copy Markdown
Owner

关联

Refs #775。此 PR 在完整验证前保持 Draft,不将已写实现或测试等同于验收完成。

实现

  • CreateProxy<T>(options) / Get<T>() 仅进行本地构造;代理冻结本地契约与注册代次,调用时才选择远端。
  • 每次 RPC 在既有目标拓扑内筛选 ContractId/hash/receipt 匹配的候选,并使用实际保留的同一 session 发送。蓝绿 session 重定向后重新验证实际目标。
  • FailFast 返回结构化观察;WaitForCompatible 事件驱动等待,1024 个共享等待槽覆盖调用和显式 readiness waiter。等待、重试、背压及响应共享原始逻辑 deadline。
  • GetContractReadiness / WaitForContractAsync 显式区分缺失、尚未观察、不兼容、兼容、不可用与停止;多集群 API 保持指定 cluster 的边界。
  • Register/Replace 返回不含 Assembly/Type/代理的 receipt;minimum-version 仅在同一 server instance/registry epoch 内比较,exact-registration 另外固定 RegistrationId。
  • 协议 minor/floor 从已发布 2.0.3 的 4 升至 5,要求 ContractAdmission capability。Request 与 manifest 使用明确的 v1 扩展格式,旧 peer 在握手时 fail closed。
  • 服务端在业务反序列化/实例激活前检查所选不可变注册,versioned admission 在同一 registry gate 下读注册与版本;既有 module lease/drain 保持最终生存期边界。
  • 流建立后不迁移;本地注册退休唤醒未准入等待;取消、超时和停止释放等待状态。

重要兼容边界

版本目标为 3.0.0。生成代理工厂签名和 RpcMethodDescriptor 的 32-byte unmanaged 布局保持不变,requirement 通过内部 bound-channel 重载传递。直接把 client 转为未绑定 IRpcChannel 后以任意 codec/ID 调用会被拒绝,避免旧 codec 偷换为当前注册的 hash;请使用 CreateProxy/Get。

当前验证状态

基线:eb99fe887cf2129d9b88441245ca0a4a6406b6c2。

  • 实现与测试已写入独立分支。
  • git diff --check。
  • 16 项 release-version guard,对照实际 v2.0.3 (4f9295ffb37ce68985051c11bfd9afc0e23166f3);未修改版本递增策略。
  • 独立最终源码 review 通过(8a9bae36),覆盖实际 reservation、receipt/server 边界、等待/退休释放和 descriptor unmanaged 布局。
  • 全 solution restore/build:Release 构建 0 warnings / 0 errors。
  • 新增 admission 单测 51/51;Generator 269/269;协议 54/54;服务端串行 496/496;LoadTest 77/77。
  • 6 项真实 TCP 回归通过,包含延迟 manifest、同 hash receipt、stale-wire 预激活拒绝及本地退休/collectible ALC 卸载。
  • 生产引用、runtime architecture、maintainability(既有 18 项 allowance 未增加)、生成程序集无 runtime 依赖、3.0 public API 清单检查。
  • 完整 Unit/Generator/Integration 门禁。
  • 真实 transport、collectible ALC 与 NativeAOT 实际执行证据。
  • 本地 base/head TCP 对照:146 条测量、3,348,726 次验证操作、0 正确性失败;较长配对复测未复现初始吞吐负差,unary 分配约 272.065 B/op 未变化。
  • 稳定 runner 上的性能界限确认,以及 SHM RPC allocation / OneWay / NativeAOT 门禁(本地 IPC 阻断,不计通过)。
  • 最终精确 head 的 canonical CI。

最终本地 Unit 2065/2093、Integration 408/458 通过;其余分别 28/50 项均受本地 Unix socket/named-pipe 限制。完整运行发现的 3 项兼容行为/fixture 问题已修复,5 项针对性回归及完整 suite 的对应测试均通过。NativeAOT 原生发布与规范 formatter 同受该执行环境 IPC 限制;managed TCP admission smoke 通过不替代 NativeAOT 证据。以上未勾选阶段仍未完成,等待最终精确 head 的 CI。

已写回归包含五种调用形状、延迟广播下不发 payload、混合 endpoint、同 hash/不同 registration、独立 registry timeline、容量、取消/停止/deadline、真实 TCP stale-wire 预激活拒绝、stream pinning、retry re-admission 与本地 retirement/ALC。

远端 production head: 3aedcfc71e85a43fa71a266b7fd0e6d18939d4ff;tree 与独立 review 的本地 8a9bae36 完全一致。最终 CI 链接将在验证运行后补齐。

… for 3.0 (#775)

Pure local proxy construction; bounded deadline-aware waits; immutable session and registration validation across all RPC shapes; protocol5 fail-closed identity envelopes; server pre-decode admission and collectible lifecycle regression coverage.

Reviewed source tree identical to local 8a9bae36094e23213165ced6fd2e961a0a665c09. Canonical CI validation pending.

Copy link
Copy Markdown
Owner Author

已验证远端 production head 3aedcfc71e85a43fa71a266b7fd0e6d18939d4ff 的完整 tree 与独立审查的本地 8a9bae36 一致。

精确 source 验证使用单独 workflow-only 分支,definition commit 为 36f7b42c4682c1cef9de97dc35be12d333a8b14d。所有 15 个 checkout 和 9 个 codec provenance 字段固定 production SHA;checkout 后验证 HEAD、clean tree 和 canonical workflow 校验和。Quick/Extended/codec/managed-allocation 的原有命令、矩阵、预算及 negative control 保持不变,普通 PR Fast 也保持不变。

运行中:

OneWay 是保留原始测量的性能证据,不是新增或放宽的 regression budget;空报告/零执行不会被当作成功。PR 保持 Draft,待最终结果。

Copy link
Copy Markdown
Owner Author

正常 PR 的 6 个 workflow 已全部通过。第一轮 exact-source Quick/Extended 的主 job 也通过,包含完整 tests、NativeAOT transport/topology、packages、load 和 Chaos;但整体验证尚未完成:新增 provenance 检查在 macOS 缺少 sha256sum、Windows CRLF checkout 上失败,现已改为 Python 校验 canonical Git blob bytes,保留 exact HEAD / clean tree / 4 个 SHA256 断言。

另一个验证 wrapper 问题是 OneWay 使用 65536 invocation override,超过 benchmark 原有 4096,导致 base/head 都达到既有 8MiB send queue 上限、无有效结果。失败原始证据保留,严格 validator 正确拒绝;没有提高 queue budget。现恢复 canonical 4096,其他参数不变。该 benchmark 仅反映 sender-side queued completion,不证明逐条服务端接收/派发吞吐;继承的两个 PayloadSize 行不是两个不同 OneWay payload。

独立 review 后发布 workflow-only definition 6d9d4fb8f06b8e636a0a2e789bb20ea999b80e91,production SHA 仍为 3aedcfc71e85a43fa71a266b7fd0e6d18939d4ff:

首轮 exact-source allocation 的 4 项既有预算与 spread 检查均通过;+512 B/op negative control 按预期失败。PR 继续保持 Draft。

Copy link
Copy Markdown
Owner Author

最新验证补充(production 仍为 3aedcfc71e85a43fa71a266b7fd0e6d18939d4ff):

  • 上条记录中的 Quick v2、Extended v2 和 Allocation/OneWay v2 已全部完成并通过;Quick 共32个 job,Extended 的8个 browser skip 是原有条件。功能、NativeAOT、SHM、格式/API/版本及既有 allocation gates 已通过。
  • 但 OneWay 性能仍是阻塞项,不能因 workflow 执行成功而视为无回退。首轮有效 TCP sender-side benchmark 比基线慢约56–82%;同机交错 ABBA+BAAB、3次launch×15次actual×4096调用的复核覆盖2,949,120次调用,两个继承参数标签的 head/base 中位比约1.88和1.91。两个标签实际发送相同参数,测量的是发送侧排队完成,非逐条接收确认。该复核换为 Intel 主机后仍复现,首轮为 AMD。
  • 分离的 CPU profile 中,actual-tagged 发送调用采样显示既有发送队列 Monitor.Enter 慢路径占比增加;admission 约占 head 发送侧采样的6–8%。这支持继续定位队列/接收侧压力,但不是已证明的根因。采样粒度和跨线程阶段归属有限,保留原始 nettrace。
  • BDN 进程级分配数受异步接收进度影响,不用于断言分配回退。新增原有 SHM completion-barrier harness 的精确 base/head ABBA 比较完成80,000次已接收调用,保持5次sample及全部预算不变:800.418→800.312 B/op,差−0.106 B/op,说明该受控路径没有可见每调用分配增长。

证据:

所有对照固定 base eb99fe887cf2129d9b88441245ca0a4a6406b6c2,未修改生产代码、队列预算或 gate 来消除信号。PR 保持 Draft,下一步先定位成本,再对有依据的最小优化做独立 review 和相同对照验证。

Copy link
Copy Markdown
Owner Author

设计方向已调整。现以 Issue #775 的新设计 为后续实现基线;本 PR 不再推进,也不合并。

新边界:

  • Proxy 只做本地构造;
  • Control Plane 在连接、拓扑、Manifest 变化时维护不可变 Route Snapshot / Picker;普通调用不再逐次遍历远端 Manifest;
  • 数据面只负责选中并保留实际发送的 Session;
  • 服务端在业务解码/实例激活前完成权威 contract/hash/version admission;
  • 对同一服务端实例的动态 Register/Replace,使用 receipt 表达跨连接顺序,不把 Manifest 广播当作必要屏障;
  • OneWay、stream、retry、ALC、AOT 与性能单独验收。

关闭原因是架构方案需要重新划分职责,不是宣称已经证明 OneWay 回退由 ContractManifest 检查造成。 本 PR 已完成的功能/CI/真实 transport 证据保留;其 OneWay sender-side 对照中 head/base ~1.88–1.91 的耗时信号仍是后续实现的性能回归参考。该指标不等于服务端接收吞吐,尚未证明具体根因。

后续实现从当时最新 dev 创建新分支和新 PR,不继续叠加本 PR 的提交,也不整体搬运其 115 文件改动。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant