当前提供的 oj 后端完全只是一个框架，并且功能并不完备，并且相应的判题状态、采集信息并没有和远端判题系统实现对齐。remote-judge 远端判题系统作为一个完整独立的判题后端服务，在功能上与 oj 后端存在一些耦合，比如都是用消息队列 RabbitMQ 来异步的维护判题信息，并且 remote-judge 与 oj 后端均有各自的题库，导致项目合并出现一些问题。本次的博客就是重点解决上述问题，完成 oj 系统的联调，跑通整个链路。
首先解决耦合的问题，在这里提出两种合并思路：
1）由于 remote-judge 已经是一个完整的判题服务了，一个比较直观的优化想法就是：将 oj 后端有关调度的部分删去，然后 oj 后端对于判题服务实际上就是一个代理，对用户的提交请求进行转发，相应的调度还有判题流程全权交给现有的判题服务 remote-judge 来进行实现，同时将 remote-judge 与 oj 后端共享数据库，这样就可以只通过题号去数据库中查询判题用例，并且远端判题系统可以直接将判题结果写入数据库。这个方法有很多好处，最主要的一个减少了网络的传输，避免了从 oj 后端到 remote-judge 传输完整的判题相关的用例信息，对于一些大输入的情况而言很有价值。
2）remote-judge 内部的实现也是解耦合的，实际上分为 server 与 judger 两大模块，judger 是通过 rpc 直接与 server 进行通信的，但是对应的接口实际上是和 oj 后端的请求是一致的，也就是说：我们完全可以将oj 后端直连 judger 模块，利用 judger 的判题能力和代码沙箱的调用功能。这个方法的最大好处在于：我们几乎不需要进行代码修改，只需要更改 oj 后端的配置，并且启动时只需启动 judger 模块即可。
我优先考虑了第二种情况，因为开发足够方便，并且保留了第一种实现方式，以便后续对系统进行优化。