对于一般用户的客户端，是动态上下线的，组建云的时候，也是动态云。每个客户端上线时会向服务器进行节点注册，服务器会把其加入调度队列，当客户端下线或者断开时，服务器会把其从队列中删除。
        除了动态的这部分节点，我们还有一部分在机房的节点（静态节点），这
    这部分节点一般情况是可以提供正常的判题服务的。
        这个设计实现了云计算的一个具体的应用（软件即服务），并且将云分成    两部分，动态云和静态云。综合两部分进行调度，提高了计算效率，同时也    保证计算的结果的正确性。
3.2    硬件架构
图 2硬件结构图
最左边是现有的OnlineJudge集群，右侧是CloudServer，是云服务的一个调度服务器。最下面分成两部分，一部分是一般用户节点（这部分是动态的），还有一部分是机房节点（这部分是我们可以控制的）。其中CloudServer和节点都是跨平台的。
这样的架构，我们只需要对OnlineJudge ,CloudServer,和机房节点的机器进行文护，这样就会少很大一部分判题节点的开销。而且，把OJ，CloudServer，判题节点进行解耦，一旦某部分出现问题，可以用该部分的备用机器，而不需要停掉所有的服务，并且可以很快的从故障中恢复。
3.3    软件架构
 图 3软件结构图
在最上面是个OJ的整个平台，提供web服务，数据库服务等。下面是一个CloudServer，server向OJ请求判题任务，然后返回给OJ判题的结果。CloudServer主要的模块是一个Distribute，负责调度server给的judgeMission。下面是具体的判题节点，一共分成两块。左边是一般用户的一块，包含两部分，一部分是用户可以看到的OnlineJudge客户端，通过客户端用户可以进行看题，交题，查看判题结果，还可以参加比赛。还有一部分是隐藏在客户端内的一个判题节点。该节点在用户登录时向server注册可以判题，然后等待Distribute的判题调度。右边是机房的判题节点，是一个 纯粹的判题节点，上线时向CloudServer注册，等待Distribute调度。
CloudServer , Distribute 和两部分的节点构成了整个的云计算判题平台。平台接收OnlineJudge发来的判题请求，返回给OnlineJudge判题的结果，整个过程对OnlineJudge是透明的。
该设计的优点：
a．    把很多判题节点抽象成一个节点，对于OnlineJudge，只要把判题任务给CloudServer，然后从CloudServer上拿判题结果就行了。
b．    充分利用了用户闲置的计算机资源。减少了很大的服务器投入。
c．    有机房的判题节点作为保障，使得即使在用户都不在线的情况下所有的请求都能得到处理。
d．    把Distribute和CloudServer解耦，方便以后的Distribute算法的升级。
3.4    Server端软件结构
 图 4CloudServer结构图
Server一共分成6个主要模块。
1.    题目服务
客户端会向服务器请求五种题目类型的请求。题目的数目，某个题号的题目信息，所有的比赛列表，某个比赛的所有题目列表，比赛中的某个题目信息。这些所有的请求在服务端分成两类，一个是problem类型请求，一个是contest请求。
Problem请求数据协议
 客户端请求时，需要提供problemId，和flag字段。当flag为0时表示正常的请求题目，服务端根据problemId，然后去OnlineJudge上拿到题目的详细信息（包括title , description , input , output , sampleInput , sampleOutput , hint信息），在server端把这些信息重新整理下格式，加入html标签（以一个比较好的界面）然后填入Context字段，发回给客户端。如果problemId大于10000时，表示是某个contest中的题目。客户端请求contest中的题目时，填入的problemId为contestId*10000+该题在这个比赛中的排名。如果flag为1时，从OnlineJudge上拿到当前题库中的题目数目，然后把这个数字填入ProblemId字段发回给客户端。 云计算判题核的设计与实现+文献综述(8):http://www.youerw.com/jisuanji/lunwen_8280.html