Huly Network 路线图与待办清单深度解析从 ZeroMQ 基础实现到高可用与安全扩展的演进路径【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform本篇技术指南围绕 HulyHuly — All-in-One Project Management Platform旗下子项目Huly Virtual Network的官方路线图文档 foundations/net/todo.md 展开逐一拆解其已完成基线与高优先级演进计划并结合仓库内 foundations/net/packages 的真实源码、测试用例与部署 Pod 进行实现级佐证。读完本文你将理解 Huly Network 当前单实例协调器 多 Agent 容器编排架构的落地形态掌握智能容器终止、Rust 重写、HA 高可用、性能基准测试、流式传输与外部安全接入六大方向的设计动机与工程要点以及它们各自的源码落点。一、文档定位Huly Network 的发展蓝图todo.md 是 Huly Network 的 TODO 与路线图文档它清晰地划分了已完成工作与待推进方向两条主线已完成Completed基础功能实现、基于 ZeroMQ 的传输层、基础测试、基础限流逻辑高优先级计划High Priority Initiatives智能容器终止Smart Container Termination、Rust 版 NetworkServer 协调器、协调器高可用HA、综合性能测试套件、流式传输、外部客户端/Agent 安全接入其他重要任务OpenTelemetry 监控与可观测性。这份文档的价值在于它直接揭示了当前 Huly Network 的架构短板与演进方向——尤其是Network Server 单实例、无 HA这一现状与后续高可用计划之间的张力以及 Huly Collaborator 协作服务对智能容器终止能力的依赖。以下各节将逐项展开并结合源码确认当前已有什么和计划要补什么。二、已完成基线ZeroMQ 传输、基础测试与限流2.1 ZeroMQ 双向 RPC 传输层文档确认基于 zeromq transport 的基础功能实现已完成。仓库中的实现位于 foundations/net/packages/backrpc/src/server.tsBackRPCServer类基于 ZeroMQ 的Router套接字构建绑定tcp://${host}:${port}默认端口3737见 foundations/net/packages/server/src/server.ts 的NetworkServer构造器。从源码看该 RPC 层支持一整套双向消息操作码backrpcOperations操作含义源码位置hello客户端握手携带aliveTimeout服务端记录lastSeenbackrpc/server.tsping/pong心跳保活未注册客户端会被要求重新 hellobackrpc/server.tsrequest/response/responseError同步请求-响应含错误对象序列化backrpc/server.tsevent服务端向客户端推送事件广播通道backrpc/server.tsclose客户端主动断开backrpc/server.ts服务端会维护clientMapping客户端 ID → ZeroMQ 消息路由地址从而实现反向请求Back RPC——即 Network Server 可以主动向 Client 发起getContainer、terminate等调用这是 Agent 侧容器生命周期被集中管理的关键机制见 foundations/net/packages/server/src/server.ts 的AgentCallbackHandler。2.2 基础限流逻辑文档列出的基础 rate limit 逻辑在BackRPCServer中有两处具体体现每客户端并发请求上限requestsLimitPerClient 25当client.requests.size requestsLimitPerClient时服务端拒绝新请求并返回retry见 backrpc/server.ts、backrpc/server.ts按客户端独立的心跳超时每个客户端通过 hello 携带自定义aliveTimeout默认取timeouts.aliveTimeout服务端在checkAlive()中按perClientAliveTimeoutSeconds逐客户端判定失活并调用closeHandler见 backrpc/server.ts。此外 foundations/net/packages/core/src/api/timeouts.ts 定义了全局默认超时参数这也是后续性能测试与故障演练的重要基线export const timeouts { aliveTimeout: 3, // 秒 - 判定 Agent/Client 失活的超时 unusedContainerTimeout: 5, // 秒 - 未被引用的容器终止前等待时间 pingInterval: 1 // 秒 - 向 Agent 发送心跳的间隔 }2.3 基础测试基础测试已就位核心包均配有 Jest 测试foundations/net/packages/core/src/test/network.spec.ts 等覆盖协调器核心逻辑foundations/net/packages/backrpc/src/test/backrpc.spec.ts 与 foundations/net/packages/backrpc/src/test/zmq.spec.ts 覆盖 ZeroMQ 传输与 RPC 语义foundations/net/packages/client/src/tests/client.spec.ts 等覆盖客户端连接、容器连接建立与释放。需要说明的是这些测试属于基础功能正确性验证而文档规划的综合性能测试套件见第五节则是面向压测与瓶颈定位的进阶工程两者并不重合。三、智能容器终止Smart Container Termination3.1 文档目标Required for Huly Collaborator service to be used for.文档明确指出该能力是Huly Collaborator 服务落地的前置条件。其核心诉求可归纳为四点Pre-termination State容器在无法立即终止时应能返回一个特殊状态Restore Call Support网络层需支持恢复restore操作把处于 pre-termination 状态的容器拉回可用状态Graceful Shutdown允许容器先完成关键操作再被终止Timeout Handling为 pre-termination 状态定义超时策略。3.2 现状源码基础当前实现只有粗暴终止路径。容器的终止契约定义在 foundations/net/packages/core/src/containers.tsexport interface Container { request: (operation: string, data?: any, clientId?: ClientUuid) Promiseany onTerminated?: () void terminate: () Promisevoid // 立即终止无无法终止的回退 ping: () Promisevoid connect: (clientId: ClientUuid, broadcast: (data: any) Promisevoid) void disconnect: (clientId: ClientUuid) void }而协调器侧foundations/net/packages/core/src/network.ts的terminate()会从活跃容器注册表删除 → 从孤儿容器表删除 → 推送NetworkEventKind.removed事件 → 调用agent.api.terminate(uuid)。整个过程是一刀切不存在容器拒绝终止的协商机制。同时协调器通过_orphanedContainers维护无客户端引用的容器并在checkAlive()中按unusedContainerTimeout默认 5 秒自动回收见 network.ts。这正对应文档中状态恢复与优雅关闭缺失的场景——例如 Collaborator 正在处理文档同步事务时被终止会导致数据一致性风险。3.3 演进要点分析从文档与现有代码结构可以推断实现智能终止需要在Container接口与协调器terminate流程之间引入一个新的协商状态机协调器发起终止前先询问容器是否可以终止容器若处于关键事务中返回 pre-termination 状态协调器对 pre-termination 容器执行超时策略等待或强制终止在超时窗口内若收到客户端重新引用restore容器回到活跃状态。预期收益文档原文改善数据一致性与可靠性、优雅处理长任务、高负载下更好的资源管理、降低容器关闭期间的数据丢失风险。四、Rust 版 NetworkServer 协调器重写4.1 动机文档给出的重写动机聚焦四点性能Rust 的零成本抽象与高效内存管理并发更好应对高吞吐并发请求安全无 GC 开销下的内存安全资源效率更低的 CPU 与内存占用。4.2 现状TypeScript/Node.js 单线程协调器当前 Network Server 是纯 TypeScript 实现入口位于 foundations/net/packages/server/src/server.ts核心协调逻辑在 foundations/net/packages/core/src/network.ts 的NetworkImpl中。其关键数据都是内存态_agents: MapAgentUuid, AgentRecordImpl— Agent 注册表_containers: MapContainerUuid, ContainerRecordImpl— 容器注册表_clients: MapClientUuid, ClientRecordImpl— 客户端注册表_orphanedContainers— 待回收容器表pending— 启动中的容器Promise 去重eventQueue— 待广播事件队列。协调器通过TickManager周期性执行checkAlive()Agent 健康检查与sendEvents()事件广播合并见 network.ts。这套基于Map与Set的内存模型非常适合 Rust 移植——HashMap/HashSet语义天然对齐。4.3 演进注意事项文档给出的考量点也是社区移植类项目的通用陷阱保持与现有 API 的向后兼容RPC 操作码、opNames协议见 foundations/net/packages/client/src/types.ts不应改变否则 Agent/Client 端无法平滑切换平滑迁移路径现有部署含 Docker Pod应能无感知升级异步运行时建议评估 Tokio 等 async Rust 框架与当前 Node.js 事件循环模型在语义上对齐sendEvents的非阻塞广播模式尤其相关Node.js 互操作如需要评估 NAPI-RS 以便在 Node 生态内嵌入 Rust 组件。从源码结构看NetworkImpl对外只暴露Network与NetworkWithClients两个接口见 foundations/net/packages/core/src/api/network.ts接口边界清晰这为内部实现替换、外部契约不变的重写提供了良好前提。五、协调器高可用HA支持5.1 现状单点故障是硬约束这是当前 Huly Network 最明确的架构限制。仓库 READMEfoundations/net/README.md与部署文档均强调Network Server 只允许单实例运行自身不支持 HA 或集群若协调器宕机整个系统不可用。生产部署建议依赖进程级守护systemd、PM2、Kubernetes restart policy并接受重启期间的短暂停机。值得注意的对比是Agent 与容器层面已经具备一定的 HA 能力——无状态容器stateless containers支持自动故障转移具体实现见 foundations/net/packages/core/src/agent.ts 的addStatelessContainer/activateStatelessContainer以及协调器register中的同一容器 UUID 由多个 Agent 竞争注册、首个获胜逻辑foundations/net/packages/core/src/network.tsHA 专项测试见 foundations/net/packages/core/src/test/ha-stateless.spec.ts。也就是说文档中的 HA 计划针对的正是协调器这一层的单点。5.2 计划中的关键能力文档为协调器 HA 列出了四要素Active-Passive Failover备用协调器实例自动接管State Synchronization跨实例的实时状态复制——当前NetworkImpl的所有注册表都是内存态且无持久化见 network.ts这是状态同步的最大工程难点Health Checks持续监控与自动故障检测当前仅有checkAlive的 Agent 侧健康检查协调器自身的健康探测是新增项Split-brain Prevention通过共识机制避免脑裂后状态冲突。收益预期零停机部署、协调器故障自动恢复、更高可用性与更从容的维护窗口。六、综合性能测试套件6.1 文档规划的测试场景与指标文档规划了 8 类压测场景高请求量每秒数千并发请求容器弹性伸缩数百容器动态扩缩网络延迟不同网络条件与地理分布内存压力大 payload 传输与内存密集型操作故障转移与恢复协调器故障与恢复场景多租户负载多租户混合工作负载长连接WebSocket 与流式连接稳定性冷启动性能容器初始化与预热时间以及 8 类核心指标请求延迟p50/p95/p99、吞吐量请求/秒、容器启动时间、资源利用率CPU/内存/网络、连接池效率、Redis 操作延迟、负载下错误率。6.2 已有的压测工具基础仓库中已存在一个可扩展的基准测试基座foundations/net/pods/network-tool其 benchmark.ts 提供两个 CLI 子命令bench-agent注册一个 benchmark 容器 Agent支持-n/--network默认localhost:3737、-e/--endpoint默认localhost:3738、-l/--label可多次/分号分隔参数并可周期性打印容器数bench客户端压测命令支持-c/--count容器数量、-r/--requests请求数、-e/--exit结束后是否退出内部通过client.get(...)并发获取容器并以 Promise.all 并行发送echo请求、统计耗时毫秒。# 注册一个 benchmark 容器 agent node bin/network-tool bench-agent -n localhost:3737 -e localhost:3738 # 对 100 个容器各发 1000 次请求 node bin/network-tool bench -n localhost:3737 -c 100 -r 1000从源码看当前 benchmark 已覆盖高请求量、容器数量、轮询分发耗时的基本度量但 p50/p95/p99 分位延迟、多租户混合负载、冷启动时间、长连接稳定性等文档规划的指标尚未实现这正好是综合性能测试套件的增量空间。七、流式传输能力Streaming Capabilities7.1 目标场景文档提出引入流式传输以实现容器到客户端的高效部分数据传输两个典型场景大响应负载无需将整个数据集加载进内存即可流式下发对大 payload 传输和内存压力的直接回应实时数据处理结果可用即增量推送。7.2 现状基础当前ContainerConnection接口中已预留流式语义的注释占位见 foundations/net/packages/core/src/api/client.ts// A chunk streaming of results // stream: (data: any) Iterableany同时该文件中的on?: (data: any) Promisevoid提供了单向事件接收通道对应 README 中fire-and-forget 消息与事件广播模式但真正的分块流式 request/response尚未落地。从实现层看ZeroMQ 的Router消息循环backrpc/server.ts每次请求-响应是一次性序列化 一次性响应要实现流式需要在 RPC 层引入多次分片响应或独立的流通道。八、安全与外部客户端/Agent 支持8.1 计划能力全景文档规划了五类安全特性认证与授权基于 token 的认证JWT、API keysTLS/SSL 加密外部通信强制加密细粒度限流按客户端/Agent 应用限流当前仅全局限流requestsLimitPerClient是所有客户端共享的默认值见 backrpc/server.ts访问控制列表ACL外部客户端访问特定服务的细粒度权限审计日志外部访问行为的完整记录。安全考量还包括内外流量网络隔离、DDoS 防护与请求过滤、证书管理与轮换、凭据安全存储与轮换、IP 白名单/黑名单。8.2 现状纯内网信任模型当前BackRPCServer绑定默认host *客户端只需完成hello握手即可注册/请求容器不存在认证环节传输层使用 ZeroMQ 原生 TCP未启用 TLS。因此外部客户端接入计划本质上是给当前内网可信模型补上身份、加密与授权三层防线。潜在应用场景文档列出的用例第三方集成访问 Huly 服务、远程监控与管理 Agent、外部 webhook 与事件消费者、受控访问的合作伙伴应用、公网接入的移动/桌面客户端。九、监控与可观测性及其他任务文档在Other Important Tasks中明确列出了一项待办添加 OpenTelemetry 用于监控/日志。目前从仓库源码看系统主要依赖console.log/console.warn输出运行信息例如 Agent 失活告警、容器终止失败日志见 network.ts、backrpc/server.tsBackRPCServer维护了一组基础计数stats.pings/requests/responses/hellos见 backrpc/server.ts可视为接入 OpenTelemetry 指标Meter的天然数据源。此外 NetworkServer 每 5 秒打印一次客户端数、Agent 数、容器数快照见 foundations/net/packages/server/src/server.ts也是可观测性改造的切入点。十、如何参与从文档到代码的切入点todo.md 在末尾欢迎社区对任一计划贡献代码并指引参考主 README.md 的贡献指南。结合仓库结构各计划的建议起点如下路线图项建议阅读起点智能容器终止containers.tsContainer 接口、network.tsterminate 流程Rust 重写api/network.ts接口契约、server.tsRPC 实现协调器 HAnetwork.ts内存态注册表、ha-stateless.spec.ts既有 HA 模式性能测试套件pods/network-tool/src/benchmark.ts现成基座、bench_cli.md流式传输client.ts预留的 stream 占位外部安全接入backrpc/server.ts握手/限流/路由逻辑OpenTelemetrybackrpc/server.tsstats 指标总结Huly Network 的路线图清晰呈现了一条先打通可用、再补齐韧性的演进路径ZeroMQ 双向 RPC、基础测试与限流构成当前可用基线随后以 Huly Collaborator 落地为牵引推进智能容器终止以性能与资源效率为目标推进 Rust 协调器重写以单点故障消除为目标推进协调器 HA以压测基座network-tool为起点构建综合性能测试套件并规划流式传输与外部安全接入两大能力扩展最终用 OpenTelemetry 补齐可观测性短板。对于希望在分布式容器编排方向深入或参与贡献的开发者而言foundations/net 目录下的核心包、测试与 Pod 是理解这一切的最佳起点。【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考