【系统架构师-案例分析】2025年5月份案例分析第一题-架构评估
案例描述：
某科技公司开发了一个面向开发者的在线大模型训练平台系统，该平台主要面向具备一定编程基础的用户，支持基于 Python 的模型编写、训练和部署流程。系统旨在简化模型开发流程，用户无需了解底层计算硬件配置，平台将自动解析代码并智能匹配训练资源进行运行。
该系统设计初期就充分考虑了系统质量属性对平台稳定性、易用性和用户体验的影响，具体需求如下：
1.用户提交模型训练任务时，系统应在1 分钟内分配资源并开始任务运行；
2.数据库发生故障时，能够在 20 分钟内切换至备用数据库，保证平台继续运行；
3.服务器发生故障时，能够自动切换至备用服务器，保障系统业务连续；
4.系统出现故障时，平台能够继续正常运行并通知管理员，同时应提供相关的操作日志、系统日志、访问日志和调试日志等信息；
5.用户界面需自动适配不同设备的分辨率和屏幕比例；
6.提供常用快捷键操作，提升平台易用性；
7.系统支持切换界面语言，方便不同语言背景用户使用；
8.支持远程用户进行测试和操作，但需限定为注册用户；
9.系统应支持来自不同终端设备（如浏览器、命令行工具、移动设备等）和操作系统（如 Windows、Linux、macOS）的注册用户同时远程访问与操作平台，系统需能正确解析并响应各类客户端的指令，保证功能一致性与协同操作能力；
10.当系统功能需要调整时，应在 3 天内完成功能修改和部署上线；
11.系统需具备良好的故障恢复能力，在发生系统级故障时，15 分钟内需完成修复；
12.系统需具备良好的异常容错机制，部分模块出错不应影响平台整体运行。
问题一：12分
根据上述系统描述，依次写出每条需求对应的系统质量属性。
1.用户提交模型训练任务时，系统应在 1 分钟内分配资源并开始任务运行（1）；
2.数据库发生故障时，能够在 20 分钟内切换至备用数据库，保证平台继续运行（2）；
3.服务器发生故障时，能够自动切换至备用服务器，保障系统业务连续（3）；
4.系统出现故障时，平台能够继续正常运行并通知管理员，同时应提供相关的操作日志、系统日志、访问日志和调试日志等信息（4）；
5.用户界面需自动适配不同设备的分辨率和屏幕比例（5）；
6.提供常用快捷键操作，提升平台易用性（6）；
7.系统支持切换界面语言，方便不同语言背景用户使用（7）；
8.支持远程用户进行测试和操作，但需限定为注册用户（8）；
9.系统应支持来自不同终端设备（如浏览器、命令行工具、移动设备等）和操作系统（如 Windows、Linux、macOS）的注册用户同时远程访问与操作平台，系统需能正确解析并响应各类客户端的指令，保证功能一致性与协同操作能力（9）；
10.当系统功能需要调整时，应在 3 天内完成功能修改和部署上线（10）；
11.系统需具备良好的故障恢复能力，在发生系统级故障时，15 分钟内需完成修复（11）；
12.系统需具备良好的异常容错机制，部分模块出错不应影响平台整体运行（12）。
参考答案：
（1）性能（2）可用性（3）可用性（4）可用性（5）易用性（6）易用性（7）易用性（8）可测试性（9）互操作性（10）可修改性（11）可用性（12）可用性
解析：
本题要求把自然语言需求映射到系统质量属性。第1条强调“1分钟内分配资源并启动”，典型关注响应时间与吞吐，归属性能。第2、3条提出“数据库/服务器故障后切换并持续运行”，其核心是服务不中断与高可用，因此归为可用性。第4条要求“故障仍可运行并上报且提供各类日志”，体现容错、降级与运行可观测性，其度量对象是业务是否可继续，仍归可用性。第5、6、7条围绕适配不同分辨率、多语言、快捷键等交互体验改良，显然指向易用性。第8条“仅注册用户可远程测试与操作”，强调可控测试、可观测与可隔离性，面向测试组织与执行的便利，归可测试性。第9条要求“多终端多OS并发、统一解析与一致语义”，本质是跨平台、跨协议、跨形态的协议与语义兼容，归互操作性。第10条“3天内改动上线”，直指变更成本与发布效率，归可修改性。第11条“系统级故障15分钟内恢复”，度量的是恢复时间目标（RTO）与业务连续性，归可用性。第12条“模块出错不影响整体”，强调故障隔离、降级与容错，仍归可用性。
需要注意的是，实务中“可用性/可靠性/可恢复性”常被混用，但在质量属性分类里更推荐以是否保持对外可用服务来判定归类：只要指标落在不中断、可切换、可恢复、可继续等范畴，优先归入可用性；若主要关注故障率、平均无故障时间等统计性指标，再偏向可靠性。本题第2/3/4/11/12条都以“业务是否继续提供”为判据，因而可用性更贴切。此外，第8条若从“认证授权、安全性”理解也可成立，但题干将其与“测试和操作”捆绑，意在可控测试与受限访问，以可测试性为佳；第9条若从“跨端适配”理解可落在可移植性，但其强调“同时远程访问、正确解析指令、保证一致性与协同”，更符合互操作性对接口/协议/语义一致与协作的要求。该映射方案与标准答案一致，亦与常见质量属性术语库（如SEI、ISO/IEC 25010）相容。
问题二：13分
根据题干描述，将下图空白处补充完整，并说明该平台为什么适合用解释器风格
参考答案：
（1）程序执行的当前状态（2）解释器引擎（3）解释器引擎的内部状态
该平台适合采用解释器风格架构，是因为其核心功能是对用户提交的 Python 模型代码进行解析和执行，而不需要用户关注底层硬件实现。
解释器风格能够将代码解析为抽象语法树，并逐条解释执行，天然适用于这种“代码即任务”的场景。它不仅支持灵活地扩展新语法和命令，还便于在执行过程中嵌入日志记录、调试信息和资源调度逻辑，增强系统的可控性与可维护性。因此，解释器风格非常契合该平台对动态性、灵活性和任务控制能力的需求。
解析：
解释器风格由“程序（待解释的指令序列/AST）”“解释器引擎”“引擎内部状态”“程序执行的当前状态”等构件协作完成。程序执行的当前状态刻画运行时上下文（如指令计数器、作用域栈、变量与张量缓存、随机种子、会话与资源句柄等），解释器引擎负责将用户代码解析为中间表示并驱动逐条执行，引擎内部状态保存解释器自身的控制信息（如调度策略、优化开关、后端选择、算子注册表、插件与安全沙箱策略等）。对本平台而言，用户“提交代码即提交任务”，平台需在不暴露硬件复杂性的前提下对脚本进行静态/动态分析、依赖解析、算子/设备匹配、数据与日志通道编排，随后按策略在GPU/CPU/分布式集群上执行——这些都与解释器在运行时做决策的特性天然契合。