问题 1（每题 1.5 分，共 9 分）：(a) 性能；(b) 可用性；(c) 可修改性；(d) 安全性；(e) 易用性；(f) 可测试性。
提示：(a) 有明确时间度量（决策延迟≤1 秒）→性能；(b) 故障自动接管→可用性；(c) "修改局部化、工作量小"→可修改性；(f) 失败可复现是典型的可测试性场景（易被误判为可用性）。此题设计完全对标 2025 上半年真题"在线大模型训练平台"。
问题 2（每题 2 分，共 8 分）：(a) 敏感点（实例数→单一质量属性：吞吐/延迟）；(b) 权衡点（可用性↑ 与 复杂度/正确性风险↓，影响多个质量属性）；(c) 风险点（集中纳管存在单点隐患，可能危及可用性）；(d) 非风险点（已满足要求、无潜在问题）。
问题 3（共 8 分）：(1) 选择心跳机制（2 分）：节点数量大（上千个），由各 GPU 节点上的代理按固定周期（如每 5 秒）主动向资源管理服务上报心跳，管理端只需被动接收、超时判死（连续 3 个周期未收到即判定失效），避免了管理端逐一 ping 上千节点的请求风暴与调度开销，网络与管理工作量更均衡；ping/echo 更适合管理端按需、定点探测某个可疑节点的场景（2 分）。
(2) 错误恢复战术应用（每条约 1.3 分，答 3 条）：①主动冗余——主备调度器同时接收任务状态，主故障时备节点零延迟接管；②备件——训练 Pod 异常退出后由 K8s 重新拉起新实例接管；③回滚——训练任务支持从最近 checkpoint 恢复，不必从头重跑；④状态再同步——备调度器接管后从共享存储同步任务队列状态，避免漏调度；⑤被动冗余/主备切换——资源管理服务主备部署，主失效后由备节点接管并重建 GPU 池视图。
问题 1（共 8 分）：批处理层（3 分）：管理主数据集（全量、不可变），周期性（如每小时/每日）对全量数据进行预计算，产出批处理视图，高吞吐、可重算、容错性好，但延迟高。速度层（3 分）：处理批处理视图尚未覆盖的最近增量数据，低延迟产出实时视图（Flink/Storm），通常牺牲一定的准确性换取时效（增量近似算法）。服务层（1 分）：对两类视图的查询结果进行合并，对外提供统一查询接口（批视图 + 实时视图）。缺点（1 分+）：同一业务逻辑要在批、流两套系统中重复开发与维护，数据口径易不一致，运维与资源成本高，服务层合并逻辑复杂。此题对标 2023 下半年案例真题（智慧交通 Lambda/Kappa）。
问题 2（共 9 分）：Kappa 核心思想（4 分）：只用流处理一套系统，以 Kafka 为可重放的数据中枢（日志即真相），所有数据当作无限流处理，批处理只是流处理的一种特例（重放），从而"一套代码、一套口径"。优势（3 分）：消除批流双链路，开发运维成本大幅降低；数据口径天然一致；架构简单、链路可回溯。重算处理（2 分）：新起一个流处理作业（版本 v2），从 Kafka 最早位点（或指定时间点）重放历史数据，计算结果写入新表；验证无误后原子切换查询指向，最后停掉旧作业——即"以重放代批处理"。
问题 3（共 8 分）：(1) 分层（4 分）：ODS（贴源层：原始数据近原样落地）→ DWD（明细层：清洗、标准化、维度退化）→ DWS（汇总层：按主题轻度聚合）→ ADS（应用层：面向报表与接口的结果数据）。意义：清晰的数据血缘与复用、逐层降噪提高数据质量、统一口径避免重复计算、屏蔽底层变化对应用的影响。
(2) Iceberg 收益（每条约 1 分）：①湖上支持 ACID 事务，避免读写冲突与脏读；②支持 upsert 与增量读取，CDC 入湖与流批一体更顺畅；③Schema 演进与分区演进无需重写数据；④时间旅行/快照回滚，便于数据订正与审计；⑤多引擎（Spark/Flink/Trino）共享一份数据，配合对象存储实现存算分离降低成本。
问题 1（每层名称 0.4 分 + 职责 1.2 分，共 8 分）：①感知层（设备接入层）——采集视频、开关量等环境数据，执行开门/声光报警等控制指令；②边缘层（边缘计算层）——对本地视频流做结构化解析与实时推理（人形检测、车牌识别），过滤无关数据，仅上报告警片段与元数据；③网络层（传输层）——提供 5G/光纤/LoRa 等多网接入、协议转换与可靠传输（QoS 保障、断点续传）；④云端/平台层——海量数据存储与检索、AI 模型集中训练、设备与边缘节点的注册纳管、配置下发、监控运维；⑤应用层——告警处置工作流、轨迹回溯、指挥大屏、统计分析等业务应用。
提示：分层命名不要求完全一致（感知/接入/边缘/网络/平台/应用），按"端—边—云"逻辑合理作答即可；职责与名称对应正确是得分关键。此题对标 2026 上半年案例真题"AIoT 智能安防云边协同"。
问题 2（共 9 分）：(1) 优势（每条约 1 分，4 分）：①低时延——推理在本地完成，告警延迟从秒级降至数百毫秒，满足周界告警实时性；②省带宽——仅上传结构化结果与告警片段，回传流量下降 90% 以上；③断网可用——边缘具备本地自治能力，断网期间持续检测与本地告警，恢复后补传；④数据就近处理保护隐私——原始视频不出园区，仅元数据上云，满足合规要求；⑤云端算力聚焦于模型训练等重任务，资源利用更合理。
(2) 缺点（每条约 1.6 分，答 3 条，5 分）：①边云网络依赖与一致性风险——边云链路中断或抖动时告警无法同步、配置无法下发，出现"边缘可见、云端失明"；②边缘算力受限——轻量化模型精度低于云端大模型，误报/漏报率上升；③运维复杂度高——200 台异构边缘节点分布各楼宇，系统升级、故障排查、监控告警都远难于集中式；④模型/配置版本一致性难保障——各节点版本漂移会导致行为不一致；⑤数据治理分散——原始数据留边缘、结果留云端，跨层数据关联、审计与安全防护面扩大。
问题 3（共 8 分）：(1) 边缘初筛 + 云端复核（4 分）：边缘模型采用"高召回"阈值配置（宁可多报不漏报），将候选告警连同短视频片段、置信度、上下文元数据（时间、位置、相邻传感器状态）上传云端；云端用更高精度的大模型（以及多模型交叉验证、周界联动规则、历史误报库比对）做二次判定，确认后才推送给安保人员并留存；置信度极高的（如烟雾联动确认）可由边缘直接告警、云端事后归档。要点：边缘管"快与全"、云端管"准与定"，分级阈值与上下文融合是采分点。
(2) 模型更新机制（4 分）：云端训练完成 → 模型仓库统一版本管理 → 灰度发布：先向 5% 边缘节点（试点楼宇）下发新模型，边缘采用双模型并行（新模型影子运行不接流量，对比输出差异）验证无误后逐步扩大范围；下发支持断点续传与校验（哈希校验防损坏）；每批更新后监控误报率/漏报率指标，异常自动回滚到上一稳定版本；全程记录版本台账可审计。要点："灰度 + 影子验证 + 可回滚"缺一不可。
问题 1（共 8 分）：过程（4 分）：准备阶段——协调者询问所有参与者能否提交，参与者执行事务并写 undo/redo 日志，锁定资源，应答 Yes/No；提交阶段——全部 Yes 则发送 commit，任一 No 或超时则发送 rollback，参与者执行并释放锁。缺陷（每条 1 分，4 分）：①同步阻塞——参与者持有资源锁等待协调者指令，并发能力差；②协调者单点——协调者在阶段二前宕机，参与者长时间阻塞；③数据不一致——阶段二部分 commit 消息丢失，部分提交部分未提交；④过于保守（任一节点故障即整体回滚），性能差，互联网高并发场景基本不用。
问题 2（共 9 分）：Try（1.5 分）：业务检查与资源预留（冻结库存、冻结支付额度），不做真正提交；Confirm（1.5 分）：确认提交，使用预留资源完成业务（必须成功，不再校验，保证最终一致）；Cancel（1.5 分）：取消预留、释放资源（补偿）。三问题（每条约 1.5 分）：空回滚——Try 未到达（超时/丢包）而 Cancel 先到，Cancel 应先检查事务记录，无记录则直接返回成功并记录；悬挂——Cancel 执行后迟到的 Try 才到达，预留的资源将无人释放，对策是 Try 前检查是否已有 Cancel/回滚记录（状态机拦截）；幂等——Confirm/Cancel 可能重试多次，操作必须可重复执行（唯一事务号+状态表/幂等表），防止重复扣减或重复释放。
问题 3（共 8 分）：(1) 本地消息表流程（4 分）：订单服务在同一本地事务中写入订单并插入消息表记录（状态=待发送）；后台任务（或事务提交后）将消息投递 MQ，投递成功更新状态；下游服务（库存/支付/积分）消费消息完成各自本地事务并回执确认；投递失败或下游失败由重试机制补偿，超限转人工处理；定时对账兜底发现不一致。要点：业务与消息写入同库同事务，保证"必发"；下游消费幂等。
(2) Saga（2 分）：将长事务拆分为 T1…Tn 个本地事务，每个配一个补偿事务 C1…Cn，某步失败则逆序执行补偿回滚；编排式=中央协调器（状态机）统一驱动流程，流程清晰易监控；协同式=服务间监听事件链式触发，松耦合但链路难追踪。
(3) 选型（2 分）：出票扣款链路资金敏感、要求较强一致性且流程固定，选 TCC（资源预留防超卖）；积分、通知类允许延迟，选本地消息表/事务消息（最终一致）；避免 2PC。言之有理、按业务一致性等级分级处理是采分核心。
问题 1（每小题约 2.2 分，共 9 分）：(1) Zigbee（或 Z-Wave/Thread 等低功耗局域组网技术）：电池供电传感器要求超低功耗与多年续航，数据量小且频率低；Zigbee 支持自组网、多跳扩展，一节电池可用 1～2 年，由网关统一汇聚转换后上云。
(2) NB-IoT（蜂窝窄带物联网）：紧急按钮是"生命线"设备，必须不依赖家庭宽带与 WiFi（老人可能欠费、断电、忘续费）；NB-IoT 走运营商网络覆盖广、穿透性强、低功耗广域（LPWAN），按键即直连云端触发告警。也可辅以 GSM 短信/电话双通道兜底。
(3) 低功耗蓝牙（BLE）连接手机或家庭网关：手环为穿戴设备，体积与电池受限，BLE 功耗极低、天然适配穿戴设备；手环经手机/网关转发上云，手环自身不直接入云。
(4) 燃气/烟雾报警器采用本地独立报警 + Zigbee/NB-IoT 双通道上报：安全类设备不能依赖云端闭环——本地声光报警独立工作（断网、断宽带仍有效），检测电路独立供电；同时经 Zigbee 上网关、NB-IoT 直接上云双路告警，任一通道故障不影响告警触达。采分提示："关键安全功能本地闭环、不依赖云端"是本题与 2026 上半年真题一致的核心理念。
问题 2（共 8 分）：三种 QoS（每条约 1.3 分，4 分）：QoS0 至多一次——发送后不等确认，可能丢失，开销最小；QoS1 至少一次——两步确认（PUBLISH→PUBACK），保证送达但可能重复，消费端需幂等；QoS2 恰好一次——四步握手（PUBLISH→PUBREC→PUBREL→PUBCOMP），不丢不重，开销最大。
选型（每条约 1.3 分，4 分）：(1) 活动心跳数据选 QoS0（或 QoS1）：单条丢失影响极小，下一条分钟级数据即将到达，用最低开销支撑海量设备高频上报；(2) 常规状态上报选 QoS1：状态数据希望尽量送达，但重复无碍（以最新值覆盖即可），在可靠性与开销间折中，配合客户端按设备 ID 去重；(3) 燃气/跌倒告警选 QoS2：生命安全相关，必须恰好一次、不丢不重——重复告警会引起混乱与资源误派，丢失则可能危及生命，宁可承担开销。
问题 3（共 8 分）：(1) 时序数据库优势（每条约 1.6 分，答 3 点，5 分）：①写入吞吐高——针对按时间追加（append-only）的写入模型优化， LSM 类存储引擎顺序写盘，轻松支撑每秒数十万点写入，而 MySQL 高频 INSERT 会因索引维护与 B+ 树随机写成为瓶颈；②按时间查询高效——数据按时间分区/分片，时间窗口聚合（如"近 24 小时活动量"）直接定位分区；③压缩率高——针对时间戳与数值列的专用压缩（列式存储、Delta 编码、Gorilla 浮点压缩），存储成本远低于行式关系库；④自动过期与降采样——原生支持 TTL 保留策略与连续查询/自动聚合，冷数据自动清理；⑤针对设备/测点建模（超级表、标签列），海量同类设备管理更自然。
(2) 处理方案（3 分）：采用降采样（Downsampling）+ 冷热分层：明细数据保留近期（如 7～30 天）用于实时分析与告警回溯；由连续查询/定时任务将历史明细聚合为小时/天粒度的汇总表（总活动量、异常次数等），报表仅查汇总表；更久远的明细按 TTL 自动归档到对象存储或直接删除。要点：细粒度近期、粗粒度远期，既省成本又保报表。
请围绕"云原生架构及其应用"论题，依次从以下三个方面进行论述：（1）概要叙述你参与管理和开发的软件项目以及你在其中所担任的主要工作；（2）详细论述云原生架构的内涵、核心技术体系（容器、微服务、服务网格、不可变基础设施、声明式 API、DevOps）及其特点；（3）结合你参与的实际项目，说明云原生架构在该项目中的具体应用，以及实施过程中遇到的实际问题与解决方法。
2023 年 5 月，我所在单位启动了某新能源汽车企业车联网平台的云原生改造项目。该平台接入全国 86 万辆智能网联汽车，承担车辆数据采集、远程控制、OTA 升级与智能座舱等业务，原平台基于虚拟机部署，存在资源利用率低、弹性伸缩慢、发布风险高三大问题。我作为系统架构设计师，负责总体架构设计、容器化迁移方案制定与关键技术选型。本文结合该项目论述云原生架构及其应用：云原生以容器、微服务、服务网格、不可变基础设施与声明式 API 为技术基座，以 DevOps 持续交付为工程方法，构建具备弹性、可观测与自愈能力的现代化应用体系。项目中，我们以 Kubernetes 为统一算力底座完成 60 余个微服务的容器化迁移，引入 Istio 服务网格实现零侵入治理，采用 Serverless 支撑突发负载，并建设 GitOps 交付流水线与立体化可观测体系。系统上线后，资源利用率由 18% 提升至 52%，弹性伸缩响应由 40 分钟缩短至 3 分钟，发布频率由双周提升至按日，系统可用性达到 99.95%。实践表明，云原生架构是应对海量接入与高频迭代的有效路径，但其落地必须以工程文化建设与演进式迁移策略为前提。
该车联网平台上线于 2019 年，采用传统分布式架构部署于 120 余台虚拟机之上：应用以 Spring Cloud 组织为微服务但依赖人工脚本发布，数据经 Kafka 汇聚至 Hadoop 集群与时序数据库。随着接入车辆由 20 万辆增至 86 万辆，日均上行消息量突破 240 亿条，平台暴露出三类突出问题：一是虚拟机资源粒度粗、环境不一致，全年平均资源利用率仅 18%，而节假日出行高峰又须提前一周手工扩容，算力"平时闲置、峰时不足"；二是发布依赖人工脚本与在线变更，一次全量发布耗时约 6 小时，2022 年曾两次因发布操作引发生产事故；三是故障恢复依赖人工介入，链路追踪缺失，平均故障定位时间超过 1 小时。2023 年 5 月，公司决定对平台实施云原生改造，项目预算 1500 万元，工期 12 个月。我担任系统架构设计师，负责目标架构设计、容器化迁移策略制定、技术选型与 DevOps 工程体系建设，并牵头解决实施过程中的关键技术难题。
云原生（Cloud Native）并非某项单一技术，而是一套充分利用云计算弹性伸缩与分布式能力来构建和运行应用的方法论与技术体系，其内涵可概括为"一个基座、四大支柱、一套方法"。一个基座即以 Kubernetes 为代表的容器编排平台，向上提供统一算力与运行环境；四大支柱包括：容器化——应用及其依赖被打包为标准化镜像，实现"一次构建、处处运行"，从根本上消除环境差异；微服务——按业务能力将系统拆分为可独立演进的小型服务，从架构上隔离变化与故障；服务网格——以 Sidecar 代理将服务发现、熔断限流、灰度发布、mTLS 加密等治理能力从业务代码下沉到基础设施层；声明式 API 与不可变基础设施——开发者仅声明系统期望状态，控制器持续将实际状态调谐至期望状态，节点故障自动驱逐重调度、副本宕机自动重建，而任何变更都以替换镜像的方式实施，杜绝在线修改导致的环境漂移。一套方法即 DevOps 与持续交付，通过自动化流水线实现高频、低风险的发布，并配合不可变基础设施实现"一切变更皆可回滚"。
与传统虚拟机部署相比，云原生架构具有四个突出特点：一是弹性，基于指标驱动的水平自动伸缩（HPA）可实现分钟级乃至秒级的容量调整，资源按需供给；二是可移植，镜像标准化使应用可跨私有云与公有云一致运行，避免厂商锁定；三是自愈，健康探针配合控制器使系统具备"故障自发现、自恢复"能力；四是可观测，指标、日志、链路追踪三大支柱贯穿全栈，为 SLO 管理与自动化运维提供数据基础。需要强调的是，云原生并非微服务的简单容器化——微服务解决的是架构层面的解耦问题，云原生则进一步覆盖了资源供给、交付流程与运维范式的整体变革，是技术架构、工程方法与组织文化的三位一体。
在算力底座建设上，我们在同城双数据中心构建了两套对称的 Kubernetes 集群，共划分 9 个节点池，按业务等级实施资源隔离：车辆远程控制等时延敏感链路独占节点池并通过污点与容忍调度与离线计算物理隔离；数据加工类负载允许混部以提升利用率。对象存储、时序数据库与 Kafka 采用云服务化产品实现存算分离，集群仅承载无状态应用。两集群由全局负载均衡实现双活接入，具备 15 分钟内整体切换的容灾能力。
在应用架构上，60 余个微服务全部完成容器化改造并配置 HPA 弹性策略，按 CPU 利用率与消息积压量双指标自动扩缩容；OTA 升级通知等强突发型负载迁移至 Serverless 平台（Knative），闲时自动缩容至零，节省了近四成常备算力。服务间治理引入 Istio 服务网格：东西向流量全链路 mTLS 加密，灰度发布由网格层按流量权重精确控制，业务代码零侵入。
在交付与运维体系上，我们建设了 GitOps 流水线：开发提交代码后，GitLab CI 自动完成单元测试与镜像构建，镜像经 Trivy 漏洞扫描方可推入制品库，ArgoCD 监听仓库变更将应用同步至测试、预发、生产环境，生产发布一律采用金丝雀策略，异常可一键回滚。可观测方面，以 Prometheus + Grafana 承载指标、Loki 聚合日志、SkyWalking 追踪调用链，统一 TraceID 贯穿消息队列，围绕"控制指令成功率""上报入库延迟"等核心 SLO 配置分级告警与自动预案。
第一个问题是有状态组件的容器化风险。改造初期，团队计划将 Kafka、时序数据库等一并迁入 Kubernetes，一次 Zookeeper Pod 漂移引发消息集群抖动，险些造成数据丢失。我据此确立了"无状态应用上云、有状态组件托管"的分级策略：自研无状态服务全面容器化；消息与存储类组件改用云厂商托管版或独立物理集群，仅通过 Operator 纳管其生命周期，收益与风险取得平衡。
第二个问题是镜像臃肿与启动缓慢。部分 Java 服务镜像超过 1.2GB、冷启动耗时 4 分钟，严重拖累弹性扩容时效。我们采用多阶段构建裁剪镜像，运行时切换为按需定制的 JRE 并启用 AppCDS 类数据共享预热，最终镜像缩减至 380MB，启动时间压缩到 40 秒以内。
第三个问题是多集群配置漂移。双活集群上线初期曾因两侧手工配置不一致引发路由异常。我们将 Git 仓库确立为唯一事实源，所有集群配置经评审合入后由 ArgoCD 双向同步，禁止任何人工直改，并通过每月一次的混沌演练（注入 Pod 延迟、驱逐节点）持续验证自愈能力与容灾预案的有效性。
2024 年 6 月，平台整体迁移完成并通过验收并稳定运行至今：全年平均资源利用率由 18% 提升至 52%，年度算力成本下降约 580 万元；弹性扩容响应时间由 40 分钟缩短至 3 分钟，平稳支撑了春节返乡高峰 5 倍于日常的流量；发布频率由双周一次提升至日均 15 次，变更失败率降至 2% 以下；系统整体可用性达到 99.95%，平均故障定位时间由 1 小时缩短至 10 分钟以内。通过本项目我深刻体会到：云原生改造的价值一半来自技术、一半来自组织——只有当团队真正建立"一切皆代码、一切可回滚"的工程文化，容器与服务网格的效能才能充分释放；同时，改造必须分级规划、演进式实施，切忌"一步到位"式的大爆炸迁移。这些经验对我后续承担更大规模的云原生与智能化架构设计工作具有重要指导意义。
随着大语言模型与检索增强生成（RAG）技术的广泛应用，向量数据库成为智能应用系统的关键基础设施。请围绕"向量数据库在项目中的应用"论题，依次从以下三个方面进行论述：（1）概要叙述你参与管理和开发的、使用了向量数据库的软件项目及你所担任的主要工作；（2）详细论述向量数据库的特点与工作原理（Embedding 向量化、相似度检索、ANN 近似最近邻索引 HNSW/IVF 等），并说明其相对于传统关系数据库/关键词检索的优势与不足；（3）结合项目实例说明向量数据库在系统中的具体应用（如 RAG 知识检索、语义搜索、推荐召回等），实施过程中遇到的问题与解决方法，以及应用效果。
随着业务系统与外部技术设施（数据库、消息、第三方服务）的耦合日益加深，如何保持核心业务逻辑的纯粹与可测试成为架构设计的重要课题。请围绕"六边形架构的设计与应用"论题，依次从以下三个方面进行论述：（1）概要叙述你参与管理和开发的软件项目及你所担任的主要工作；（2）详细论述六边形架构（端口与适配器架构）的核心思想与组成结构（领域核心、端口、适配器），说明其与传统分层架构的区别及主要优点；（3）结合项目实例说明你们如何基于六边形架构完成系统的分析、设计与开发，实施过程中遇到的问题与解决方法，以及实施效果。
架构评估是保障软件质量的重要手段。请围绕"软件系统架构评估方法及其应用"论题，依次从以下三个方面进行论述：（1）概要叙述你参与管理和开发的、开展过架构评估的软件项目及你所担任的主要工作；（2）详细论述架构评估的主要方法（SAAM、ATAM、CBAM），重点说明 ATAM 的评估步骤、效用树的构建方法、质量属性场景的构成要素，以及敏感点、权衡点、风险与非风险等评估结论的含义；（3）结合项目实例说明架构评估的具体过程、发现的主要问题与改进措施，并分析评估带来的实际效果。