摘要

2025 年 6 月至 2026 年 6 月，我参与了校园在线评测平台的研发。该项目的目标是建立一个面向教学与竞赛的在线训练系统，该平台旨在完成题目发布、程序提交与自动评测，为学生和教师提供练习、批改与运营管理等服务。我在该项目中担任系统架构师，全程参与了系统的分析规划和设计工作。本文以该项目为例，详细探讨软件架构风格在软件系统架构中的应用及其实现。

在构建该评测平台时，我们采用了分层组合的架构模式，执行层能够解释并运行用户程序，确保多种语言在统一规则下安全评测；而消息层则对评测任务进行异步分发，提供了低耦合的构件协作能力。这两层结构相互补充，使得平台既能满足高峰提交，又能进行在线维护与扩展。通过解释器对评测协议进行适配，结合消息中间件进行任务调度，我们成功打造了一个稳定可用的在线评测系统。通过这一实践，我们进一步验证了软件架构风格在现代软件系统架构中的重要性和实用性。

在我的带领下，项目实施的非常顺利，于 2026 年 6 月成功上线运行，并获得业主单位的一致好评。

正文

随着程序设计教学规模扩大和集中训练日益频繁，原有手工收作业、本机批改的方式已难以支撑并发提交和安全隔离。公司自 2025 年 3 月起开展需求调研，规划建设一套可扩展的在线评测平台。

2025 年 6 月我司受托建设本项目。本项目面向校园内网部署，我在项目中担任系统架构师职务，主要负责系统整体架构设计，该系统主要完成题目管理、程序提交、自动评测和运营维护，主要功能模块包括账号权限、题库管理、提交评测、执行调度、文件存储以及通知公告等。

在架构工作开始阶段，我们便意识到，架构风格是一组设计原则，是能够提供抽象框架模式，可以为我们的项目提供通用解决方案的，这种能够极大提高软件设计的重用的方法加快我们的建设进程，因此在我司总工程师的建议下，我们使用了解释器风格、独立构件隐式调用风格以及 B/S 风格这三种较常用风格。虚拟机风格中的解释器能够把多样的程序执行过程抽象为统一语义，这类风格非常适用于输入形式多、评测规则相对稳定的场景。独立构件风格包括显式调用与隐式调用，我们为了降低提交入口与评测执行之间的耦合采用了隐式调用，通过消息中间件控制系统间信息交互，不仅能削峰填谷，而且还提高了执行节点扩容和故障隔离的能力。B/S 是基于浏览器与服务器的软件架构，它主要使用超文本传输协议进行通信和交互，简化客户端分发的工作，最终减低了机房批量升级的难度，以下正文将重点描述架构风格的实施过程和效果。

底层架构我们使用解释器风格来满足多语言安全评测需求。解释器风格是虚拟机风格中的一种，具备良好的灵活性，在本项目中我们的架构设计需要兼容多种程序设计语言，一般来说这种软件编写难度非常高，代码维护难度压力也很大，因此这个解释器的设计任务便很明确了，软件设计需要高度抽象、协议的适配由配置文件来承担。具体的做法如下，我们对一次评测过程进行了高度抽象，由于一次评测由很多测试用例组成，每个测试用例容量固定并且标识和数据有明确规定，因此我们将题目中的语言限额和测试用例进行关系建模，将整体题目作为一个根节点，以测试用例作为根节点下的叶子节点，使用结构化配置映射成了题目、限额、用例这三层的数据结构，核心的代码采用模板解析与动态装载生成可执行对象，搭建一套可以基于可变模板的解释器，协议模板的产生可以由语言运行时说明和题目配置进行转换得到，解释器支持协议模板热部署，这种可以将用户程序和测试数据映射成统一的评测对象，将语言差异和数据协议的复杂度简化，后期评测规则更改不会对软件产生影响，仅仅更改协议模板文件即可，最终我们使用了若干份协议描述文件便兼容了这些复杂的语言与用例组合，规避了在业务系统中直接执行用户程序带来的技术风险。

中间层我们使用独立构件风格中的隐式调用来简化构件间的交互复杂度，降低系统耦合度。主要的实现手段是，我们采用了一个开源的消息中间件作为连接构件，这个构件是成熟的消息服务器，其性能和稳定性久经考验。由上文提到的解释器所需的对象化任务经过消息总线分发到各个订阅此消息的应用系统，这些应用系统包括提交服务、评测服务、重试服务等，这种多 web 应用的情况非常适合采用消息发布与消息订阅的机制，能够有效解决耦合问题，我们在编码的过程中发现只要采用这种风格的 web 应用，整个迭代过程效率极高，错误率降低，而且我们使用的配置化消息框架，消息队列的管理完全基于配置，清晰简单，维护性良好，例如评测任务主题、延迟重试主题、异常死信主题等消息队列分类清晰，可以随时修改其结构也能够随时增加其他主题的消息队列，不同的 web 系统监听的队列也可以随时变换组合，基于消息中间件的架构设计能够让系统的构件化思路得到良好实施，总体来说这种架构风格带来了非常清晰的数据流转架构，简化了编码难度，减低本项目的二次开发的难度。

应用系统层我们主要采用 B/S 的架构风格，主要用于解决终端分散、难以统一升级的问题。校园应用有一个明显的特点，机房、办公室和竞赛场地分布在不同楼宇，路途很远，且都是内网通讯，部分场所也是走的受控网络，一般是无法远程支持的，这给我们的系统推广以及后期维护带来了很大难题，我们可以想象如果使用 C/S 架构，更新客户端一旦遇到问题很可能需要运维把各机房跑一遍。这让我们在系统推广和维护方面面临较大压力。我们采用的 B/S 架构风格能够解决这个难题，并充分考量了现在相关技术的成熟度，例如现在的浏览器完全能够实现以前客户端的功能，项目中我们使用了大量的动态页面与脚本技术，能够满足在线编辑、结果查询和后台管理等需求。这种风格中页面和逻辑处理存储在 web 服务器上，维护和软件升级只要更新服务器端即可，及时生效，用户体验较好，例如界面上需要优化，改一下页面或者样式文件就可以马上看到效果了。

项目于 2026 年 6 月完成验收，这半年内共经历了三次大批量集中提交，这几次接入过程平稳顺利，其中协议解释器软件性能没有出现过问题，消息中间件的性能经过多次调优吞吐量也接近了磁盘与网络的承载上限，满足当前的消息交互总量，另外由于我们的项目多次在紧急状态下能够快速适应评测规则变动，得到过业主的邮件表扬。除了业主机房几次突发性的网络故障外，项目至今还未有重大的生产事故，项目组现在留 2 个开发人员和 1 个售后在维护，系统的维护量是可控的，系统运行也比较稳定。

不足之处有两个方面，第一在架构设计的过程中我们忽略了部分机房终端的兼容性，个别终端因为需要兼容老的应用软件不允许系统升级，这些终端系统老旧，其浏览器不支持现有页面技术，导致了系统推广障碍。第二在高可用方面还有待改善。针对第一种问题，我们通过沟通协商说服业主新购 PC，采用两台机器同时使用方式解决。针对第二种问题我方采用了多节点互备和服务接管等策略，在一台服务暂停的情况下，另外一台服务接管，以增加可用性。