前言

事实证明，每一届，每几年，各地高校，都会出现一些 "志士仁人" 出于提升自己或服务母校的目的打算开发一个 OJ。

我们当然也不例外。

所以，望眼当下，0202 年，一个具备怎样特质的 OJ 才能从众多 OJ 中脱颖而出，既能更好地服务母校，又能为开源界的贡献一点新思路。我想，SDUOJ 能给出一个答案。

先给出项目：SDUOJ​sduoj.gitee.iohttps://github.com/SDUOJ/OnlineJudge​github.com

特性

作为 OJ 最直接的使用者/开发者，我们清楚地明白一个好用的 OJ 除了常规功能外必须要具备的一些特质：独特的业务

友好的交互

稳定的架构

方便的运维

业务方面

业务方面，除了 OJ 的常规功能，SDUOJ 提供以下的功能：评测模板。不再局限于编程语言的概念，我对Judge 这个概念向上抽象一层，提出了评测模板的概念 —— 只要是代码，是文件，就会有客观性评测的办法。OJ 应该将这种出题的能力赋予给用户。比如我们支持了在 OJ 上评测汇编实验(8086 汇编)、操作系统实验( @jesHrz 写了 checker 来追踪学生代码中的系统调用)等等，这实际上就为课程实验的创新提供了基建。(各种评测语言当然也可以很方便的新增，SPJ 也可)

虚拟评测(Virtual Judge)。在算法竞赛训练中，使用各大 OJ 的优秀题目进行训练是常有的事。但是在缺乏一个管理者/督促者的情形下，如何将宝贵的数据资产(代码/题集/成绩)沉淀到一方系统，为学院进一步规范/改善算法竞赛集训队的训练计划以及提升学生的程序设计能力提供支撑，这是一个绕不过的坎(尤其是目睹我校 ACM 成绩波动、学生平均程序设计能力后，觉得十分重要)。(还在设计，逃

一题多面。同一道题目，可有多个题面！可支持中/英/俄文等多语言！可支持复杂/精炼/变形等题面多形式！

多种赛制(ACM/OI/IOI)、信息脱敏(可以选择性地配置比赛时要展示给选手的信息)。广泛地适用于学生实验、期末测试、竞赛训练、赛事举办等场景！

多核平台调度，单点评测、多点评测，按需配置！多核平台的评测调度策略

思路很清晰了，业务上从最基本的评测能力开始，到题目设计的能力，之后对比赛举办做支持，为实验创新提供基建，最终是为了做数据沉淀。SDUOJ 能力大图

架构方面

参加过一些算法竞赛和线上代码考试的人，应该见识过参加竞赛时评测机卡爆转为 OI 模式的情形。所以我在想，怎样的架构更适合于去应对各种不同场景的流量和评测压力。

并且，事关一个学校 OJ 的如何传承和迭代，作为代码爱好者我也不希望后人会看 shit 山一样看待我的代码，所以，微服务的拆分使得各个模块独立，更方便迭代。

从 "杭州西厂" 实习后，我偷学到了不少先进的业务理念/架构思想/技术知识。决定采用面向服务(SOA)的分布式微服务架构。

最后的架构如下图所示，后端微服务和评测机都十分方便于动态的扩缩容以应对不同场景的流量和压力。更加的高并发/高可用，相信很难遇到性能瓶颈(已经对部分复杂接口做了缓存)，如果有，那我觉得 SDUOJ 那时足够自豪。SDUOJ 架构大图

交付方面

必须得容器级交付，必须得一键部署。作为亲手装过学院的物理服务器以及使用过大厂的公有云的我，才知道部署和运维真的是很需要勇气和耐心。

SDUOJ 作为分布式应用，使用者能有经济基础在公有云上进行搭建和日常生产自然是好的，但是对于在物理机上进行安装也应该有官方支持。

所以，我给出在公有云上(比如阿里云)搭建集群的一键脚本/相关教程，以及在自己学校机房手动搭建和运维的教程经验。

(补一句，分布式是肯定比单体架构吃资源滴)

开发方面

GitHub 上分布式协作和版本控制嘛。不过使用过大厂的 devOps 后，发现 CI/CD 也是十分的必要，正在使用 GitHub Actions 和阿里云容器镜像服务来为开发增效。

... 其他

前端截图

最后贴一下前端截图吧。

更多截图请点击这里 SDUOJ。

致谢

首先感谢大佬们开源的 OJ 为我开阔眼界以及为设计 SDUOJ 提供思路！这里 SDUOJ 也开源勉强算为开源界做些微小的贡献吧！

最最重要的是，感谢有志同道合的伙伴一起开发这个项目。幸运！为了不打扰他们我就不逐一 at 了，谢谢 rr/dd/xb/xr 4 人！感恩！

----------------------- 其他，应该没有其他啦 -----------------------

SDUOJ 已经在我们学院内部使用，陆陆续续会发现/修正一些问题。对开源社区还没有发布第 1 个稳定版本，欢迎尝鲜和做开源贡献，但要用作生产则建议观望一段时间，谢谢！