即时通讯后端【免费下载链接】WuKongIMMore than just IM 不只是即时通讯(IM)项目地址https://gitcode.com/gh_mirrors/wu/WuKongIM点击查看免费下载导读本文围绕 WuKongIM 仓库中的架构决策记录 ADR-0040Separate deployment from Cloud Lease lifecycle 展开讲解该即时通讯项目如何在自动化云仿真chat-lifecycle场景中把「临时云基础设施的生命周期管理」与「WuKongIM 产品的部署激活」拆分成两个彼此独立、可分别测试的职责边界。读完本文你将理解 Deployment Action 为何只能消费非机密 Lease Receipt、不可变 Deployment Bundle、Deployment Plan 与临时 SSH 凭证却绝不允许触碰云资源的获取与释放并能从wkcloudlease、wkcloudbundle、wkcloudgate三个命令入口的源码实现中验证这套分离设计的落地方式。决策背景一次部署失败不应变成隐藏的云资源变更在自动化云环境中一个常见的架构陷阱是把「部署业务软件」与「管理云资源」揉在同一个执行体里部署脚本一旦失败就直接调用云 API 去创建、替换或销毁主机来自愈。这种做法表面上省事却带来三个难以测试的问题职责无法独立验证——基础设施生命周期策略与产品部署逻辑耦合在一起任何一个环节改动都要重跑整个云流程失败处理不可审计——部署失败后发生的资源变更缺少类型化证据无法判断是哪一步、在什么凭证授权下做了何种变更权限边界模糊——执行部署的进程同时拥有云资源的创建/释放权限扩大了被攻破或误操作时的爆炸半径。WuKongIM 的 ADR-0040 正是针对这个问题给出的架构决策激活activation将是一个专用的 Deployment Action它只消费非机密 Lease Receipt、不可变 Deployment Bundle、Deployment Plan 与临时 SSH 凭证它既不能获取也不能释放云资源。顶层编排者top-level orchestrator独占资源的获取与释放操作并对 Deployment Action 产出的类型化 Deployment Receipt 做出反应。这一决策同时呼应了更早的 ADR-0039Extract a reusable Cloud Lease boundary——临时云的采购、库存、访问授权、过期、释放与清扫被收敛到一套 provider-neutralprovider 无关的 Cloud Lease 契约之后才能进一步把产品部署从这套契约的生命周期操作中彻底剥离开。三个可独立测试的层次从 ADR-0040 的表述与仓库代码结构看这套分离设计把整体拆成三层每层都有独立源码包与测试层次职责源码位置关键能力基础设施生命周期Cloud Lease报价、采购、库存重建、访问授权、释放、清扫internal/usecase/cloudlease cmd/wkcloudleaseprovider-neutral可复用于任何仓库消费者产品部署Deployment Action离线 Bundle 封存与校验、生成 Deployment Plan、评估就绪门禁internal/usecase/clouddeploy cmd/wkcloudbundle cmd/wkcloudgate只消费非机密 Lease 库存无任何 provider 生命周期权限顶层编排orchestrator跨阶段工作负载策略、资源获取/释放决策scripts/cloud-deployment/下的执行脚本与工作流测试独占云资源变更消费类型化 Receipt 驱动状态机从源码结构可以推断cloudlease包的包注释明确写着产品部署和工作负载概念必须留在包外见 types.go而clouddeploy包则声明自己只接受经过校验的、非机密的 Lease 库存且不具备 provider 生命周期权限见 FLOW.md。两侧的对称约束正是 ADR-0040 的代码级体现。Cloud Lease 生命周期命令只读与变更权限的分离cmd/wkcloudlease是云租约生命周期的命令边界。它暴露的命令清晰地划分出「只读证据」与「付费变更」两类能力见 lifecycle_commands.go命令能力分类说明dry-run演练仅使用内存 fake provider 跑完整生命周期不产生网络与计费行为quote只读对严格 Cloud Lease Plan 做一次无副作用的价格/容量决策inspect只读从 provider 库存重建某个精确 Lease 的 Receiptacquire付费变更创建或重建一个显式授权的付费租约需--plan --quote --bootstrap-accessgrant_access/revoke_access付费变更对活跃租约添加/移除一条带过期时间的入站授权release付费变更删除租约并证明零库存sweep付费变更按仓库边界调和过期租约直至释放或进入 pendingwkcloudlease的 FLOW.md 明确指出只读的 quote/inspect 权限永远不会授权 acquire、release 或 sweep。这是通过不同的 provider 构造路径实现的——见下文源码佐证。关键命令行参数以acquire为例它要求三个版本化输入同时满足严格解码见 lifecycle_commands.gowkcloudlease acquire \ --plan $request_dir/plan.json \ --quote $request_dir/quote.json \ --bootstrap-access $request_dir/bootstrap-access.json--planwukongim.cloud_lease/v1版本的严格 Cloud Lease Plan包含 LeaseID、RequestID、Provider、Region、Repository、Operator、ExpiresAt、Budget、Network 与 HostGroups 等字段--quotewukongim.cloud_lease.quote/v1版本的 Quote 结果--bootstrap-accesswukongim.cloud_lease.bootstrap_access/v1版本的公共引导身份authorized keys。release与sweep则只消费精确 Selector 或--provider/--region/--repository三元组其中sweep对三个参数要求精确非空值见 lifecycle_commands.go防止跨仓库误操作。双构造器lifecycleAuthorized 标志权限分离的底层保障来自 Alibaba 适配器的双构造路径。在 openapi.go 中func NewOpenAPIFromOIDCEnvironment(region string) (*OpenAPI, error) { return newOpenAPIFromOIDCEnvironment(region, false) // 只读 } func NewLifecycleOpenAPIFromOIDCEnvironment(region string) (*OpenAPI, error) { if os.Getenv(lifecycleAuthorizationEnv) ! lifecycleAuthorizationValue { return nil, fmt.Errorf(%w: explicit Alibaba lifecycle mutation authorization is required, ErrInvalidConfig) } return newOpenAPIFromOIDCEnvironment(region, true) // 付费变更 }只读构造器quote/inspect 使用从临时 OIDC 角色凭证创建 SDK 客户端lifecycleAuthorized false生命周期方法VPC、EIP 等变更不可达付费变更构造器acquire/release/sweep 使用额外要求环境中存在精确的显式授权值否则直接失败关闭。也就是说仅仅持有库存证据inventory evidence本身没有任何变更授权价值。cmd/wkcloudlease的 boundary_contract_test.go 验证了未经验证的 schema 在构造 provider 之前就被拒绝测试断言错误路径下 provider 工厂调用次数为零从侧面印证了命令在接触云 API 之前就先做严格输入校验。Deployment Action只消费、不变更与租约生命周期相对部署侧被设计成纯粹的消费者。cmd/wkcloudgate是部署门禁命令的入口见 deployment_commands.go它只提供两个子命令deployment-plan把活跃租约绑定到离线部署包wkcloudgate deployment-plan \ --lease-receipt $request_dir/receipt.json \ --bundle-manifest $bundle_root/bundle-manifest.json \ --bootstrap-pubkey $($request_dir/deployment_ed25519.pub) \ --purpose repair --generation $generation参数含义见 deployment_commands.go参数必填说明--lease-receipt是严格的活跃 Cloud Lease Receipt JSONschema 必须为wukongim.cloud_lease.receipt/v1--bundle-manifest是严格的离线 Bundle 清单 JSONwukongim.cloud_deployment.bundle/v1--purpose否默认immutableimmutable或repair两种激活目的--generation否默认 1从 1 开始的部署代数immutable强制为 1--bootstrap-pubkey否Lease Receipt 绑定的完整 Ed25519 公钥集合可重复传入--now否可选 RFC3339 校验时间测试与确定性场景deployment-plan内部依次完成严格解码 Lease Receipt → 校验 schema →ValidateReceipt→若存在 bootstrap 标签校验完整公钥集合 → 读取 bundle manifest → 根据 purpose 调用BuildPlanimmutable或BuildRepairPlanrepair→ 输出 Deployment Plan。BuildPlan的实现见 deployment.go将 Lease 库存中的实例、数据盘、公网地址归一化并绑定到固定的四主机拓扑3 个 service 节点 1 个 load 节点256 个物理 Hash Slot、12 个逻辑 Slot 组、3 份副本生成wukongim.cloud_deployment.plan/v2版本的计划并计算不可变plan_digest。deployment-gatefail-closed 的就绪门禁wkcloudgate deployment-gate \ --lease-receipt $WK_CLOUD_LEASE_RECEIPT \ --plan $WK_CLOUD_DEPLOYMENT_PLAN \ --bundle-manifest $WK_CLOUD_BUNDLE_MANIFEST \ --snapshot $WK_CLOUD_READINESS_OUTPUTdeployment-gate先通过ValidatePlanForLease证明「传入的 Plan 确实由这份 Lease 与 Manifest 推导而来」——包括 repair 专属的stagerepairLease 标签与精确的候选代数见 deployment.go再用EvaluateReadiness对就绪快照逐项把关见 deployment.go每个主机必须是 Ubuntu 24.04 x86_64、基础离线工具可用、运行时 Bundle 摘要与计划一致、数据盘挂载于/var/lib/wukongim-cloud、磁盘容量与 5% 空闲阈值达标、时钟漂移不超过 1 秒、必需 systemd 单元处于活跃集群必须收敛3 节点成员就绪、256 个物理 Slot 全部有健康 leader 与副本集、12 个逻辑组就绪、无挂起的 controller 任务load 节点必须就绪3 个 worker、完整 Prometheus targets7 个、HTTP 代理 / Manager / Demo / Analysis 网关全部可用。任何一个检查失败都会输出类型化失败而非裸错误文本Outcome携带稳定的failure.code如slot_topology_unready与last_completed_gate见 deployment.go供编排者分类重试。全部通过时输出wukongim.cloud_deployment.receipt/v2版本的 Deployment Receipt其中包含 Lease 与 Plan 的摘要绑定、激活时间、公共端点与四主机证明作为交付给工作负载编排器的非机密交接物。cmd/wkcloudgate的 deployment_commands_test.go 验证了关键的安全语义repair Plan 若使用普通 Lease Receipt 会被拒绝并输出FailureInvalidPlandeployment-plan在 bootstrap 公钥缺失或部分时会失败非版本化或未知 schema 的 Receipt 文档一律拒绝。不可变 Deployment Bundle部署的只读物资部署所消费的第二个不可变输入是离线 Bundle。cmd/wkcloudbundle负责封存与校验见 offline_commands.gowkcloudbundle seal-offline --root $bundle_root --source-sha $SOURCE_SHA --control-sha $CONTROL_SHA wkcloudbundle verify-offline --root $bundle_rootseal-offline对固定的四主机原生部署意图做无符号、无追随no-follow的目录扫描生成deployment-intent.json与bundle-manifest.json记录每个文件的精确模式、大小、内容摘要最终形成一个sha256:前缀的不可变 Bundle 摘要见 bundle.goverify-offline独立重算完整的清单契约不改动任何文件符号链接、变更的清单、模式/大小不匹配、摘要漂移全部 fail-closed。offline_commands.go 的离线命令绝不克隆源码、不构建二进制、不读取凭证、不接触云 API——这与 ADR-0040 中Deployment Action 只消费、不变更的定位完全一致。对应测试 main_test.go 用伪造 ELF 头与固定拓扑配置验证了 seal/verify 往返。实战调用链从 Receipt 到 Deployment Receipt在真实工作流中这些命令由scripts/cloud-deployment/下的共享执行脚本串联。以本地修复direct repair场景为例prepare-local-runtime.sh 展示了严格的输入前置校验for input in $request_dir/receipt.json $request_dir/deployment_ed25519.pub \ $request_dir/diagnostic_ed25519.pub $request_dir/run-plan.json $request_dir/run-policy.json \ $generation_dir/bundle/cloud-deployment-bundle.tar.gz; do [[ -f $input ! -L $input ]] done随后依次执行verify-offline校验 Bundle →deployment-plan生成 repair 计划 → 用jq断言计划 schema、purpose、source_sha、generation、拓扑256 个物理 Slot、12 个逻辑组、4 个主机→ 生成运行时环境变量含从计划提取的expires_at、预算四项limit/stop/committed/estimated微元值与行项目→ 输出deployment-plan.json与加密的运行时归档。注意--purpose repair --generation $generation的组合正是 ADR-0040 中修复会话可在同一租约上安装多个受保护 main 候选的落地形态。共享执行入口 deploy.sh 则体现了「部署失败不得演变为隐藏 provider 变更」的要求激活、收集证据、门禁评估各有独立超时与失败分类失败输出只写类型化wukongim.cloud_deployment.failure/v1文档绝不发布原始 stderr就绪轮询循环中每次先删除旧快照再收集新证据防止门禁消费过期证据只有门禁通过且 Receipt schema 与 plan_digest 完全匹配时才写入ready并删除失败文件脚本自身不获取、不释放任何云资源——FLOW.md 明确This entry never buys resources, releases a Lease, or starts a coordinator见 scripts/cloud-deployment/FLOW.md。顶层编排者的独占职责与后续演进分离之后获取/释放云资源成为顶层编排者的独占职责。相关 ADR 记录了这条边界上的后续演进可作为理解 ADR-0040 影响的补充材料ADR-0047Retain one lease across deployment repair——部署或就绪失败不会释放主机再去购买新主机而是保留精确租约、等待受保护 main 控制修订后以同一 Lease Receipt、Bundle 与按租约封存的 SSH 身份重新调用 Deployment Action若必须更换产品源或 Bundle则当前租约先释放到经认证的零库存付费运行终止新租约需要新的显式启动ADR-0041Use four PostPaid hosts for automated chat lifecycle——演练与正式租约使用不可变的 12 小时 / 96 小时 AutoRelease 到期成功或终态失败后立即释放不故意持有到到期ADR-0042Expose the load node for the bounded Cloud Lease——仅对自动化 chat-lifecycle 运行load 节点开放 22 端口 key-only SSH 与 80 端口 HTTP三个 service 节点保持私有离线所有规则与授权密钥随租约释放一并移除。这些决策共同印证了一个事实Deployment Action 的正确性是输入精确、输出类型化、全程无云权限而云资源的生灭始终由编排者通过 Cloud Lease 生命周期命令以可审计的方式完成。小结ADR-0040 为 WuKongIM 的自动化云部署划定了一条清晰的职责边界Cloud Lease 生命周期wkcloudleaseinternal/usecase/cloudlease独占 provider 交互用双构造器把只读证据与付费变更严格分离Deployment Actionwkcloudbundlewkcloudgateinternal/usecase/clouddeploy只消费非机密 Lease Receipt、不可变 Bundle、Deployment Plan 与临时 SSH 凭证产出类型化 Deployment Receipt 或结构化失败顶层编排者独占资源获取/释放依据类型化证据驱动多阶段工作负载策略。这种分离让基础设施生命周期、产品部署与工作负载策略可以各自独立测试仓库中每个命令均有对应*_test.go契约测试也让部署失败处理永远不可能变成隐藏在部署脚本里的云资源变更——这正是该 ADR 的核心价值所在。赞分享即时通讯后端【免费下载链接】WuKongIMMore than just IM 不只是即时通讯(IM)项目地址https://gitcode.com/gh_mirrors/wu/WuKongIM点击查看免费下载相关推荐BentoML 部署实战基于 BentoCloud 的 Deployment 全生命周期管理指南BentoML 部署实战基于 BentoCloud 的 Deployment 全生命周期管理指南 本文是 BentoML 开源仓库 gh_mirrors/b模型推理服务人工智能后端大模型MLOpsLLMOpsDataHub ML Model Deployment 实体实战指南从 URN 标识到生产环境部署全生命周期管理DataHub ML Model Deployment 实体实战指南从 URN 标识到生产环境部署全生命周期管理 导读 ML Model Deployment数据目录数据治理数据血缘后端前端数据工程数据集成OpenShift 部署生命周期钩子Deployment Hooks设计解读提案、API 与实战验证OpenShift 部署生命周期钩子Deployment Hooks设计解读提案、API 与实战验证 部署钩子Deployment Hooks是 Op测试云原生质量保障上一篇终极免费音频格式转换工具 FlicFlac一个 U 盘就能带走的快速便携转换神器下一篇Whisky 零基础上手指南Apple Silicon Mac 免费运行 Windows 软件的兼容层方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考