高级软件架构师 on 撷时录

ACOJ在线评测平台-架构风格论文

Tue, 06 Oct 2026 00:00:00 +0800

摘要

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，采用两台机器同时使用方式解决。针对第二种问题我方采用了多节点互备和服务接管等策略，在一台服务暂停的情况下，另外一台服务接管，以增加可用性。

第二章计算机系统基础知识

Tue, 06 Oct 2026 00:00:00 +0800

计算机系统概述

计算机系统 = 硬件 + 软件

graph TD Root["计算机系统"] %% 硬件分支 Root --> HW["硬件"] HW --> CPU["中央处理器"] CPU --> ALU["运算单元"] CPU --> CU["控制单元"] HW --> Mem["存储器"] Mem --> MainMem["主存(内存)"] Mem --> ExtMem["外存"] HW --> InDev["输入设备"] InDev --> Keyboard["键盘"] InDev --> Mouse["鼠标"] InDev --> InOther["..."] HW --> OutDev["输出设备"] OutDev --> Monitor["显示器"] OutDev --> OutOther["..."] %% 软件分支 Root --> SW["软件"] SW --> SysSW["系统软件"] SysSW --> OS["操作系统"] SysSW --> Compiler["编译工具"] SysSW --> SysOther["..."] SW --> AppSW["应用软件"] AppSW --> Office["办公软件"] AppSW --> Entertainment["娱乐软件"] AppSW --> AppOther["..."]

系统分类维度：

第三章信息系统基础知识

Tue, 06 Oct 2026 00:00:00 +0800

待定

论文

Tue, 06 Oct 2026 00:00:00 +0800

用法：先定题目方向（架构风格、高可用、安全、性能、质量属性等），再填入同一项目。摘要三段、正文“背景—职责—总述三点—分点展开—验收—不足”，三点之间换方向只换论点，不换结构。【】内为必填，不要写具体表名、接口路径、框架版本。

摘要

【项目起止时间】，我参与了【项目名称】的研发。该项目的目标是建立一个【系统定位】，该平台旨在【核心功能】，为【业务对象】提供【业务目标】等服务。我在该项目中担任【角色】，全程参与了系统的分析规划和设计工作。本文以该项目为例，详细探讨【论文主题，如软件架构风格 / 高可用性设计 / 信息安全体系】在软件系统架构中的应用及其实现。

在构建【系统名称】时，我们采用了【总体方案，如分层组合 / 主备加集群 / 纵深防御】，【要点A】能够【作用A】，确保【价值A】；而【要点B】则对【对象B】进行【作用B】，提供了【价值B】。这两层结构相互补充，使得平台既能满足【需求A】，又能进行【需求B】。通过【手段A】进行【处理A】，结合【手段B】进行【处理B】，我们成功打造了一个【系统特性】的【系统类型】。通过这一实践，我们进一步验证了【论文主题】在现代软件系统架构中的重要性和实用性。

在我的带领下，项目实施的非常顺利，于【上线时间】成功上线运行，并获得【评价主体】的一致好评。

正文

随着【行业趋势或业务矛盾】，原有【旧做法】已难以支撑【新约束，如并发、安全、扩展】。公司自【年】年【月】月起【调研 / 立项准备】，规划【建设目标】。

【年】年【月】月我司受托建设本项目。本项目【部署与范围一句话】，我在项目中担任系统架构师职务，主要负责系统整体架构设计，该系统主要完成【业务能力】，主要功能模块包括【模块一】、【模块二】、【模块三】、【模块四】以及【模块五】等。

在架构工作开始阶段，我们便意识到，【论文主题对应的方法，如架构风格 / 质量属性策略】是一组设计原则，是能够提供抽象框架模式，可以为我们的项目提供通用解决方案的，这种能够极大提高软件设计的重用的方法加快我们的建设进程，因此在我司总工程师的建议下，我们使用了【论点一】、【论点二】以及【论点三】这三种较常用【风格 / 策略 / 措施】。【类别一】中的【论点一】能够【能力一】，这类方法非常适用于【适用场景】。【类别二】包括【子类A】与【子类B】，我们为了【设计目标】采用了【论点二】，通过【关键机制】控制系统间信息交互，不仅能【收益一】，而且还提高【收益二】。【论点三】是基于【基本形态】的软件架构，它主要使用【通信方式】进行通信和交互，简化【被简化的工作】，最终减低了【被降低的难度】，以下正文将重点描述【论文主题】的实施过程和效果。

底层（或第一方面）我们使用【论点一】来满足【需求一】。【论点一】是【所属类别】中的一种，具备【主要优点】，在本项目中我们的架构设计需要兼容【多变部分】，一般来说这种软件编写难度非常高，代码维护难度压力也很大，因此这个设计任务便很明确了，软件设计需要高度抽象、【变化点】的适配由配置来承担。具体的做法如下，我们对【核心对象】进行了高度抽象，由于【核心对象】由很多【组成单元】组成，每个【组成单元】容量固定并且标识和数据有明确规定，因此我们将【主体】中的【属性甲】和【属性乙】进行关系建模，将整体【主体】作为一个根节点，以【组成单元】作为根节点下的叶子节点，使用结构化配置映射成了【层次名称】这【层数】层的数据结构，核心的处理采用【解析 / 装载 / 调度】生成统一对象，搭建一套可以基于可变模板（或策略）的实现，模板或策略可由【来源】转换得到，并支持热更新。这种可以将【复杂输入】映射成统一对象的做法，将【差异点】的复杂度简化，后期规则更改不会对软件产生影响，仅仅更改配置即可，最终我们使用了若干份描述文件便兼容了这些复杂的【差异组合】，规避了【直接硬编码或危险做法】带来的技术风险。

中间层（或第二方面）我们使用【论点二】来简化【协作对象】间的交互复杂度，降低系统耦合度（或提升【目标质量属性】）。主要的实现手段是，我们采用了【中间件或机制】作为连接构件，这个构件【一句话定位】，其性能和稳定性久经考验。由上文处理得到的对象化数据经过【通道】分发到各个【订阅方 / 协作方】，这些应用系统包括【系统甲】、【系统乙】、【系统丙】等，这种多应用协作的情况非常适合采用【发布订阅 / 异步解耦 / 其他机制】，能够有效解决耦合问题，我们在编码的过程中发现只要采用这种方法，整个迭代过程效率极高，错误率降低，而且我们使用的配置化方式，管理完全基于配置，清晰简单，维护性良好，例如【通道甲】、【通道乙】、【通道丙】等分类清晰，可以随时修改其结构也能够随时增加其他通道，不同系统监听的范围也可以随时变换组合。总体来说这种方法带来了非常清晰的数据流转架构，简化了编码难度，减低本项目的二次开发的难度。

应用系统层（或第三方面）我们主要采用【论点三】，主要用于解决【推广或使用上的难题】。【业务场景】有一个明显的特点，【使用方】分布在【地理或组织范围】，路途很远，且都是【网络条件】，【部分场所】也是走的【受控网络】，一般是无法远程支持的，这给我们的系统推广以及后期维护带来了很大难题，我们可以想象如果使用【被否定的方案】，更新一旦遇到问题很可能需要【运维代价】。这让我们在系统推广和维护方面面临较大压力。我们采用的【论点三】能够解决这个难题，并充分考量了现在相关技术的成熟度，例如现在的【成熟技术】完全能够实现以前【旧方案】的功能，项目中我们使用了大量的【技术甲】与【技术乙】，能够满足【交互需求】等需求。这种做法中【变更集中位置】在服务器侧，维护和软件升级只要更新服务器端即可，及时生效，用户体验较好，例如界面或规则上需要优化，改一下【页面 / 配置 / 策略】就可以马上看到效果了。

项目于【年】年【月】月完成验收，这【时长】内共经历了【若干次业务高峰或变更】，这几次过程平稳顺利，其中【论点一对应部件】性能没有出现过问题，【论点二对应部件】经过多次调优也满足当前的交互总量，另外由于我们的项目多次在紧急状态下能够快速适应【规则或接口变动】，得到过业主的邮件表扬。除了业主侧几次突发性的网络故障外，项目至今还未有重大的生产事故，项目组现在留【n】个开发人员和【m】个售后在维护，系统的维护量是可控的，系统运行也比较稳定。

不足之处有两个方面，第一在架构设计的过程中我们忽略了【兼容性或范围遗漏】，个别【终端 / 子系统】因为需要兼容老的应用软件不允许系统升级，这些【对象】系统老旧，其【运行环境】不支持【新能力】，导致了系统推广障碍。第二在【高可用 / 性能 / 安全等另一质量属性】方面还有待改善。针对第一种问题，我们通过沟通协商说服业主【更换或隔离旧环境】，采用【过渡方案，如两套环境并存】方式解决。针对第二种问题我方采用了【措施甲】和【措施乙】等策略，在一台服务暂停的情况下，另外一台服务接管，以增加可用性。

第一章绪论

Mon, 05 Oct 2026 00:00:00 +0800

系统架构概述

诺依曼系统计算机

计算机硬件
计算机软件

系统架构定义

定义：IEEE 1471-2000 标准

架构是体现在组件中的一个系统的基本组织、它们彼此的关系与环境的关系及指导它的设计和发展的原则。

架构设计的作用：

解决相对复杂的需求分析问题
解决非功能属性在系统中占据重要位置的设计问题
解决生命周期长、扩展性需求高的系统整体结构问题
解决系统基于组件需要的集成问题
解决业务流程再造难的问题

软件架构发展历程

timeline title 软件架构发展历程 1968 : NATO 会议提出“软件架构” 1991 : Windton W.Royce、Waiker Royce 首次定义软件架构 1992 : Perry & Wolf 创造性阐述 {elements, forms, rationale} = software 1996 : 理论体系完善与发展阶段开始 1999 : 第一届 IFIP 软件架构会议 2000 : IEEE 1471-2000 标准发布，标志首次形式化定义

timeline title 软件架构发展 1968—1994 基础研究 : NATO 会议提出术语 : 模块化六大原则出现 : MIS 系统分层思想 1996—2000 概念体系和核心技术形成阶段 : 首次定义软件架构 : SAAM 实践方法体系 : IEEE 1471-2000 标准发布 1996—至今理论体系完善与发展阶段开始 : 软件架构描述语言（C2SADL, Wright, ACME, UniCon, Rapide） : 分析方法（SAAM, ATAM, CBAM, SBAR, ALPSM, SAEM） 2000—至今普及应用 : 软件架构描述语言 ADML（XML） : IFIP 会议、IFIP 工作组成立

模块化开发六大原则

最高模块内聚。也就是在一个模块内部的元素最大限度地关联，只实现一种功能的模块是高内聚的，具有三种以上功能的模块则是低内聚的。
最低耦合。也就是不同模块之间的关系尽可能弱，以利于软件的升级和扩展。
模块大小适度。颗粒过大会造成模块内部维护困难，而颗粒过小又会导致模块间的耦合增加。
模块调用链的深度（嵌套层次）不可过多。
接口简单、精炼（扇入扇出数不宜太大），具有信息隐蔽能力。
尽可能地复用已有模块

软件架构常用分类

分层架构

四层结构：表现层、业务层、持久层、数据库层
最常见的软件架构，事实标准架构；用户的请求将依次通过这四层的处理，不能跳过其中任何一层

高级软件架构师 on 撷时录

ACOJ在线评测平台-架构风格论文

摘要

正文

第二章 计算机系统基础知识

计算机系统概述

第三章 信息系统基础知识

论文

摘要

正文

第一章 绪论

系统架构概述

系统架构定义

软件架构发展历程

模块化开发六大原则

软件架构常用分类

分层架构

第二章计算机系统基础知识

第三章信息系统基础知识

第一章绪论