架构作品集：四类异构系统中的同构判断

本页全部界面截图及其中的设计均为原创作品，版权所有。未经书面授权，禁止任何形式的转载、下载、剪辑、商用或用于模型训练，违者必究。详见文末版权声明。

十年间主导与参与的系统跨越智算调度、流程制造、实时通信、三维空间四个领域。 业务形态互不相通，但在架构层面反复复用的判断只有两条。 本文先陈述这两条判断，再以四个系统为例说明其落地方式与能力边界。

0. 陈述顺序的说明

技术栈清单不构成区分度。真正体现架构能力的是两点：

1. 能够清晰界定框架提供的能力与自行实现的部分 —— 本文每个系统均附一张边界表
2. 能够从形态各异的系统中抽象出同构的设计判断 —— 即下述两条主线

需要说明的是，下述四个系统分属不同运行时与技术栈， 而其核心机制在实现层面是同构的。这也是本人不将架构能力绑定于单一语言的依据。

1. 主线一 · 以单调版本号阻断过期持有者的写入

分布式系统中的核心难点并非”锁的获取”，而是“持有者是否仍具备写入资格”。

由于不存在完美的故障检测器，系统无法区分”节点已失效”与”节点暂时不可达”。 因此旧持有者可能在新持有者产生之后恢复运行，且其自身认为仍然有效。 选主机制无法解决该问题——旧持有者不具备判断自身应当退位的信息。

解决方案是为每次选举分配单调递增的序号，并将校验点置于被写入的一侧：

令牌校验必须置于资源侧，不可置于客户端侧。 若由旧持有者自行判断其主节点身份，则在假死场景下该判断恰恰不可用。

需要指出的是，在管理 Kubernetes 内置资源时不会遇到此问题——resourceVersion 已在框架层完成该保障。仅当调谐对象为外部异构系统时，该问题才会显现。

2. 主线二 · 结果需承担责任，故必须设置校验闸

技术手段可以产出一个数值，但不负责该数值是否具备签署与审计的资格。

共同原则是不达标不予放行——宁可退回重做，亦不使未经验证的结果流入下游。

网云融合 · 智算 OS Orchestrator

单次资源开通需同时向算力、网络、子网三个异构子系统申请资源： 算力对应计算资源池的配额分配，网络对应确定性网络的路径计算， 子网对应租户级的网络隔离分段（多租户环境下每个课题拥有独立的网络边界）。 若在算力侧完成扣减而网络侧路径分配失败，则形成资源超卖与残留。

调度总览 意图驱动的编排底座：意图 → 编排 → 开通 → 自愈；纳管算力 6.2 万核，编排任务 1024，可用性 99.92%

采用预留—提交两阶段模型，而非分布式事务。 跨异构子系统不存在统一的事务协调器，且两阶段提交为同步阻塞模型—— 协调者失效将导致三个子系统的资源同时锁定。因此在业务层实现 Try / Confirm / Cancel： 预占冻结以防止并发超卖，任一环节失败则逆序释放，预留单设置超时自动回收。

逆序回滚并非通过条件分支实现，而是由编排引擎的双向链表结构保证： 正向沿后继指针执行，异常后自出错节点沿前驱指针逐级补偿。

课题与租户 多课题共底座隔离：课题 → 配额 → 隔离；课题清单含算力配额与已用率，右侧为意图类型分布

将模型的作用面收敛至单一环节。 自然语言开通在形态上近似”由模型操作生产环境”，实际设计与之相反：

自然语言输入
  → 【模型层 · 概率】     意图理解与参数抽取        ← 模型仅参与此层
  → 【确定性引擎 · 无模型参与】
       默认值填充 / 配额判定 / 结构校验 / 契约策略校验 / 模板渲染 / 干跑预演
  → 【人工确认闸】        高危变更需人工确认后提交

模型不产出部署清单，亦不直接变更生产环境。

状态自愈 控制器健康评分与自愈建议，异常 → 研判 → 处置闭环

该平台的 30+ 微服务采用统一的交付路径，集群期望态以 Git 为唯一事实源， 绕过流程的手工变更会在下一个对账周期被自动回正。完整的流水线设计见后文 交付工程一节。

能力边界：框架提供与自行实现

框架提供的是调谐循环与选主原语；循环内的业务语义、 以及如何使外部系统承认该原语，由本人设计与实现。

IMES · 制造执行平台

流程制造企业连续生产场景，全厂数万测点、万级 EPS 数据接入。 核心诉求为账实相符——单笔计量偏差即构成资金损失。

生产运行总览 炼化制造执行平台，20+ 微服务按领域拆分；生产指令闭环：计划 → 排产 → 执行 → 回执

同一系统内并存两种一致性策略。 选择强一致或最终一致的依据是单次错误的容忍度： 油罐计量涉及物料、资金与安全，扣减数量而未增加库存等同于物料账面消失，采用同步强一致； 状态通知与日报聚合存在数百毫秒延迟不构成实质损失，采用消息最终一致。

分布式事务的模式选择依据为”能否自动生成反向 SQL”：

该选择的代价亦需明确：AT 模式为弱隔离，存在”本地事务已提交而全局事务未裁决”的窗口， 依赖全局锁保障；而全局锁仅拦截其他全局事务，不拦截绕过代理的本地直连写入， 因此关键表的全部写入路径必须经由代理。

计划排产 按装置产能与工艺约束，把生产计划拆解为可执行操作指令

顺序性保障应精确至真正需要的维度。 同一油罐的计量事件必须有序——先扣减后增加与先增加后扣减，其中间态库存值不同。 但不同油罐之间不存在顺序依赖。因此按油罐标识分区，而非全局有序： 全局有序意味着全部消息集中于单一分区，吞吐量将显著下降，且不具备必要性。 顺序性保障存在成本。

设备巡检 装置运行状态与巡检记录，异常即时告警

能力边界：框架提供与自行实现

数据中台的核心难点不在计算能力，而在口径统一： “当日产量”的统计范围为装置级或全厂级、是否计入损耗、跨零点批次的归属日期， 均需明确定义。口径不一致将导致生产、调度、财务三方报表无法对齐。

瞩目云 · RTC 实时通信

峰值在线会议数千场，单场峰值 1,280 人。 核心诉求为海量在线用户的会议状态毫秒级同步。

实时通信总览 云视频会议与统一通信平台；十万级长连接，端到端时延 47ms

扇出收敛决定系统的规模上限，而非性能优化项。 在 1,280 人的会议中，单个成员变更事件若广播至服务端全部十万连接， 则单次变更产生十万条推送；而成员变更属于高频事件。 按会议房间维度订阅投递后，扇出复杂度由 O(在线总数) 收敛至 O(房间人数)， 单次成员变更的推送量由十万级降至千级。

需要说明的是，按房间维度的分组投递机制由框架原生提供。 本人完成的部分是分组维度的选定（会议房间构成该业务天然的隔离边界）， 以及慢消费者的隔离处理——若广播采用同步阻塞写入， 单个网络状况不佳的成员将阻塞整个房间的投递， 因此采用有界队列与非阻塞投递，广播路径上不执行阻塞式 IO。

实时信令网关 连接分片、有界并发池、运行时调优，8 网关分片支撑单机十万级长连接

框架维护连接生命周期，会议域的业务状态需由应用层建模。 框架可感知连接断开，但不具备”该连接对应主持人”的语义， 亦无法决定主持权的转移目标、以及旧主持人恢复后其指令的有效性。

将主持权建模为全局唯一且可转移的独占资源，采用 epoch 与原子状态跃迁， 防范两类性质不同的竞态：

会议中台 会议状态机与活跃会议管理，公有云与私有化双形态交付

会议开场瞬间形成极端热点集中。 千余名用户在同一秒内请求同一缓存键（邀请短链）。 若该键恰在此刻失效，全部请求将同时穿透至数据库。 处理方式为互斥重建与逻辑过期：仅允许单一线程回源重建，其余请求读取旧值； 缓存键不设物理过期，过期时间存储于值中，读取到逻辑过期状态时触发异步刷新， 从而保证读请求始终有返回。

能力边界：框架提供与自行实现

智慧露天矿 · 数字孪生

数亿级点云与百 GB 量级模型。土方量作为工程结算依据， 需满足签署、审计与监理复核的要求。

数字孪生总览 地表全要素三维数字底座；三维覆盖 42.6 km²，点云 8.4 亿点，配准精度 ±2.4cm

算法库输出的是几何计算结果，而工程结算所需的是经过精度验证且可追溯的结论。 泊松曲面重建、三角剖分与点云配准均有成熟库实现， 实际工作量集中于库不覆盖的环节：地面点滤波（植被、机械与临时料堆 将被识别为地形变化，导致方量虚高）、开采边界裁剪、 以及精度闭环（独立检查点验证高程中误差、TIN 法与方格网法互验、 超差退回重算、全过程留痕）。

点云重建管线 采集 → 配准 → 泊松重建 → 瓦片生产，重建任务按采区逐单跟踪

相对配准与绝对基准属于两个独立问题。 配准算法仅保证两期数据相互贴合，不保证整体在真实坐标系中的准确性。 两期数据可能完全贴合，但整体存在系统性平移或旋转—— 该类偏差无法由配准算法检出或修正。 因此需布设地面控制点，将各期数据锚定至同一绝对大地基准。 配准解决贴合问题，控制点解决基准问题，缺少任一项方量结果均不可采信。

分级瓦片 LOD 分级瓦片与 CDN 分发，大规模模型切分后按需加载

能力边界：框架提供与自行实现

3. 交付工程 · 完整流水线设计

交付流水线的价值不在于”能把代码推上去”，而在于每一个环节都能独立失败并阻断后续， 以及失败时能立即判定失败在哪一层。下图为完整设计。

3.1 各环节的设计意图

3.2 为什么需要反向核验闸

各构建任务各自成功，不等于整体构建完整。

任务可能因触发条件不满足而被跳过、因并发取消而中止、因矩阵配置遗漏而根本未被调度—— 这些情况下单个任务不会报错，流水线整体也可能显示为成功。 若直接进入部署，缺失的制品将在部署阶段以”镜像拉取失败”的形式暴露， 而此时故障已进入生产环境。

因此在构建与部署之间插入一道反向校验：不看各任务的自报状态， 而是回过头核对制品仓库中实际存在的产物清单，与本次应产出的清单比对。 判据从”每个任务都说自己成功了”换成”应有的产物确实都在”。

3.3 三条判据

流水线设计中最容易出错的不是环节缺失，而是判据选错：

第一条尤其容易误判：对账控制器可能已完成配置同步并报告成功， 而叠加层中的版本标识并未被改写——此时同步状态为绿，线上运行的仍是上一版本。 同步成功不等于部署生效。

4. 能力域

上述四个系统分属不同运行时与技术栈，其核心机制在实现层面同构。 架构判断不依赖于特定语言，语言是实现工具而非能力边界。

版权声明

本页全部界面截图，以及其中呈现的界面设计、交互流程、信息架构、图表样式与文案，均由本人独立设计与实现，著作权归本人所有，受《中华人民共和国著作权法》及相关国际公约保护。

未经本人事先书面授权，任何单位及个人不得：

• 转载、复制、镜像、下载、传播本页图片；
• 截取画面、二次加工、修改或去除水印标识后使用；
• 用于商业用途、商业投标、宣传物料或产品演示；
• 用于人工智能模型的训练、微调或数据集构建。

经授权引用的，须完整注明作者与原文链接：https://andrewyghub.github.io/2026/08/24/architecture-portfolio

本页内容仅用于个人技术能力与作品展示。违反上述声明者，本人保留追究其法律责任的权利，违者必究。

授权与联系：1346536346@qq.com

Copyright © 2026 AndrewYG. All rights reserved.