一种基于edX平台的MOOC系统的制作方法

本发明实施例涉及在线教育技术领域，尤其涉及一种基于edX平台的MOOC系统。

背景技术：

在摩尔定律的预言下，随着计算机硬件的蓬勃发展，大规模开放在线教育成为了最热门的领域之一。

自2008年Dave和Bryan等人提出了大型开放式网络课程(Massive Open Online Courses，简称MOOC)这一术语之后，国内外各知名高校都展开了MOOC平台的开发和MOOC课程的制作。其中最为标志性的事件是2011年Stanford大学将吴恩达教授(现任百度首席科学家)的《机器学习》(Machine Learning)等三门课程免费发布在网上，该课程一经发布收获了良好的反应，超过10万人注册了这门课程。网络学习者对于这几门课程的高度认可使得吴恩达等人共同创办了Coursera平台。Google X实验室研究员Sebastian Thrun的《人工智能导论》课程也在这三门课程之列，收到了16万人的注册学习，后来他和两名同事创办了Udacity平台。在2012年，麻省理工学院(Massachusetts Institute of Technology，简称MIT)和哈佛大学(Harvard)共同创办edX平台，旨在配合校内教学的同时将课程推广到世界各地，并分析学习过程中的数据，从而进一步提高教学质量。截止到2016年3月，edX已经拥有超过700万的注册用户，共计开设了七百多门课程；Coursera平台已经拥有超过1500万的注册用户，1400多门课程；Udacity也有了400万的注册用户。

自2012年以来，MOOC变得越来越流行，来自世界各地的学生数量每年都在快速地增加，中国也不例外。为了满足中国学生的需求，国内的一些高校也开始发展自己的MOOC平台。北京大学的MOOCs@PKU平台和清华大学的学堂在线分别于2013年9月、10月开放注册和学习。特别是学堂在线，自从成立以来就收获了广泛的关注和认可，超过100万用户选修了学堂在线中开设的500门课程。由于学堂在线起步较晚，加之为中文课程，这个数字虽然落后于国外同类平台，但也足以说明MOOC在中国的热度。MOOC火热的原因是多方面的，但最为重要的是因为名校的课程质量通常较高，大多数人都希望可以学习到这样的课程。

当前流行的MOOC系统架构分别为edx和学堂在线。edX的架构主要分为三层。第一层是面向用户的LMS、CMS系统，它们采用Django框架编写；第二层是面向LMS、CMS系统提供的第三方服务，elastic search(全文检索)、youtube(视频存储)、MongoDB(课程内容存储)、MySQL(业务内容存储)、Memcached(session的缓存)等等，它们被系统调用以解决某一特定业务相关的数据存储和检索问题。第三层是自我维护的服务及其依赖的第三方服务，包括Comment Service(提供论坛服务)、XQueue(提供离线任务处理服务)、Analytics(提供分析服务)，它们除依赖上述的第三方服务之外，还依赖于某些成熟的第三方服务，如XQueue依赖于RabbitMQ和Celery，Analytics依赖于Hadoop、Hive等。

edX的架构由于其存储是作为第三方模块被不同的服务调用，存在存储和服务高度耦合的问题，从而导致整个MOOC系统不利于扩展；现有技术中的edX的架构没有负载均衡机制，限制了系统的可承载量；且视频服务是通过第三方的视频网站Youtube进行管理，虽然降低了成本，提供了不错的性能，但是Youtube等第三方视频服务提供者不存在视频内容访问控制或者相关控制较弱，不能结合用户行为对视频内容的安全性进行控制，因此存在着视频内容安全的隐患。

因此，如何提高MOOC系统的可扩展性、承受负载能力及安全性是现如今亟需解决的课题。

技术实现要素：

针对现有技术存在的问题，本发明实施例提供一种基于edX平台的MOOC系统。

本发明实施例提供一种基于edX平台的MOOC系统，包括：用户层、负载均衡层、应用服务层和数据服务层；其中：

所述用户层用于接收用户发送的请求并将所述请求发送至所述负载均衡层，其中，所述请求包括：获取静态内容的请求、处理逻辑业务的请求或处理视频业务的请求；

所述负载均衡层包括负载均衡服务器和内容分发网络，所述负载均衡服务器用于接收所述用户层发送的所述请求，根据所述系统的当前状态将所述请求发送给满足要求的服务器，并接收所述服务器返回的数据，将所述数据返回至对应的所述用户层；其中，所述服务器包括：所述内容分发网络、逻辑服务器和视频服务器；所述内容分发网络用于接收所述负载均衡服务器发送的所述获取静态内容的请求；

所述应用服务层包括所述逻辑服务器和所述视频服务器；所述逻辑服务器用于接收并处理所述负载均衡服务器发送的所述处理逻辑业务的请求，所述视频服务器用于接收并处理所述负载均衡服务器发送的所述处理视频业务的请求；

所述数据服务层用于存储数据并处理收到的所述逻辑服务器发送的所述处理逻辑业务的请求、所述视频服务器发送的所述处理视频业务的请求和所述内容分发网络发送的所述获取静态内容的请求。

本发明实施例提供的一种基于edX平台的MOOC系统，通过设置负载均衡层将用户发送的请求根据系统的当前状态进行分配，实现了动态请求和静态请求的分离处理，同时通过设置视频服务器，提高了视频资源的安全性，减轻了应用服务层的负载压力，并提高了系统的可扩展性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种基于edX平台的MOOC系统结构示意图；

图2为本发明实施例提供的基于edX平台的MOOC系统的工作原理示意图；

图3为本发明实施例提供的应用服务层结构示意图；

图4为本发明另一实施例提供的应用服务层结构示意图；

图5为本发明又一实施例提供的应用服务层结构示意图；

图6为本发明实施例提供的应用服务层工作原理示意图；

图7为本发明实施例提供的客户端结构示意图；

图8为本发明另一实施例提供的基于edX平台的MOOC系统结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本发明实施例提供的一种基于edX平台的MOOC系统结构示意图，如图1所示，所述系统，包括：用户层101、负载均衡层102、应用服务层103和数据服务层104；其中：

所述用户层101用于接收用户发送的请求并将所述请求发送至所述负载均衡层102，其中，所述请求包括：获取静态内容的请求、处理逻辑业务的请求或处理视频业务的请求；

具体地，用户层101是系统中所有的用户所使用的设备，包括电脑终端(PC端)、平板、手机等设备，用户使用PC端的浏览器、移动APP等设备向负载均衡层102发送请求。其中用户可以通过用户层101发送获取静态内容的请求、处理逻辑业务的请求或处理视频业务的请求。

所述负载均衡层102包括负载均衡服务器1021和内容分发网络1022，所述负载均衡服务器1021用于接收所述用户层101发送的所述请求，根据所述系统的当前状态将所述请求发送给满足要求的服务器，并接收所述服务器返回的数据，将所述数据返回至对应的所述用户层101；其中，所述服务器包括：所述内容分发网络1022、逻辑服务器1031和视频服务器1032；所述内容分发网络1022用于接收所述负载均衡服务器1021发送的所述获取静态内容的请求；

具体地，负载均衡层102是直接与用户层101相互传输数据的，包括负载均衡服务器1021和内容分发网络(Content Delivery Network，简称CDN)1022。其中，负载均衡服务器1021的作用是重定向和反向代理，重定向就是将用户发送的请求根据系统的当前状态将其进行分配，分配给不同的用于执行请求的服务器，并接收执行请求的服务器返回的数据，将数据返回至用户层101。内容分发网络1022是建立在网络边缘，临近于用户的一组服务器。它主要由分布式存储、内容管理和负载均衡等功能。内容分发网络1022的意义是对获取静态内容的请求进行加速，由于MOOC系统中存在着大量的静态资源，如图片、层叠样式表(CSS)、动态脚本(JavaScript，简称JS)，这些内容都是不随着用户操作的变化而变化的，它们统称为静态资源。而静态资源相比于MOOC系统中的其他部分而言，请求更为频繁，因此称对静态资源的请求为获取静态内容的请求。如果不对静态资源进行单独处理而统一放在逻辑服务器1031上，会导致系统负载过大，影响系统响应时间。因此可以用缓存、内容管理和网络流量管理等技术将静态资源存储在内容分发网络1022中，当负载均衡服务器1021接收到用户层101发送的获取静态内容的请求时，将该请求发送给内容分发网络1022，实现用户的就近访问，从而大大加快静态内容的分发速度。

所述应用服务层103包括所述逻辑服务器1031和所述视频服务器1032；所述逻辑服务器1031用于接收并处理所述负载均衡服务器1021发送的所述处理逻辑业务的请求，所述视频服务器1032用于接收并处理所述负载均衡服务器1021发送的所述处理视频业务的请求；

具体地，应用服务层103包括两大组件，一个是分布式的逻辑服务器1031，另一个是视频服务器1032。逻辑服务器1031可以有多个，用于接收负载均衡服务器1021发送的处理逻辑业务的请求，在MOOC系统中，主要有用户管理、课程的退和选、课件查看和管理、讨论、答疑、作业、测验、系统日志等功能，但不局限于上述所列举，视频服务器1032也可以有多个，用于接收并处理负载均衡服务器1021发送的处理视频业务的请求，包括提供视频观看与上传等功能。应当说明的是，逻辑服务器1031和视频服务器1032是相互独立的，因为视频业务和其他功能之间没有耦合关系，使用专门的视频服务器1032进行处理可以降低逻辑服务器1031的负载，提高处理效率。同时，设置视频服务器1032可以实现对视频的自行管理，提高了视频的安全性。

所述数据服务层104用于存储数据并处理收到的所述逻辑服务器1031发送的所述处理逻辑业务的请求、所述视频服务器1032发送的所述处理视频业务的请求和所述内容分发网络1022发送的所述获取静态内容的请求。

具体地，数据服务层104用于存储数据和提供查询功能，接收并处理逻辑服务器1031发送的处理逻辑业务的请求、视频服务器1032发送的处理视频业务的请求和内容分发网络1022发送的获取静态内容的请求，并将数据返回给对应的逻辑服务器1031、视频服务器1032和内容分发网络1022。

本发明实施例通过设置负载均衡层将用户发送的请求根据系统的当前状态进行分配，实现了动态请求和静态请求的分离处理，同时通过设置视频服务器，提高了视频资源的安全性，减轻了应用服务层的负载压力，并提高了系统的可扩展性。

在上述实施例的基础上，所述根据所述系统的当前状态将所述请求发送给满足要求的服务器，包括：

根据请求的内容类型、网络时延、所述服务器的负载情况将所述请求发送给满足要求的服务器。

具体地，负载均衡服务器1021根据内容类型、网络时延、所述服务器的负载情况将接收到的请求发送给满足要求的服务器。例如：若负载均衡服务器1021接收用户层101发送的获取静态内容的请求，则将该请求发送给内容分发网络1022，由内容分发网络1022根据该请求将对应的数据发送给负载均衡服务器1021，由负载均衡服务器1021返回给对应的用户层101；若负载均衡服务器1021接收到用户层101发送的处理逻辑业务的请求，则将该请求发送给能够处理该请求的、且负载较小的逻辑服务器1031；另外，用户可能来自于各个地方，用户所处的地理位置不同，其网络环境也不尽相同，因此，针对不用的网络环境的用户请求，将其分配给不同的服务器。

图2为本发明实施例提供的基于edX平台的MOOC系统的工作原理示意图，如图2所示，负载均衡服务器201接收用户层发送的请求，并根据该请求的内容类型、网络时延、服务器的负载情况等因素将该请求发送给满足要求的服务器202，其中服务器202中包括内容分发网络、逻辑服务器和视频服务器，由该服务器202从数据服务层203中对应的数据库中获取数据，并将数据通过负载均衡服务器201返回给用户层。应当说明的是，本发明实施例中的负载均衡服务器201与图1中的负载均衡服务器1021一致，数据服务层203与图1中的数据服务层104一致。

本发明实施例通过根据请求的内容类型、网络时延、所述服务器的负载情况将所述请求发送给满足要求的服务器，将不同类型的请求分配给不同的服务器，降低了系统的负载能力，将动/静态资源分离处理，降低了服务器的耦合性，提高了系统的可扩展性。

在上述实施例的基础上，图3为本发明实施例提供的应用服务层结构示意图，如图3所示，所述应用服务层103包括：前台接口层1033和后台服务层1034；

所述前台接口层1033用于接收并处理所述负载均衡服务器1021发送的所述请求；所述后台服务层1034用于记录日志和缓存数据。

具体地，应用服务层103在逻辑上又可以分为前台接口层1033和后台服务层1034，其中前台接口层1033用于接收并处理负载均衡服务器1021发送的请求；后台服务层1034用于记录日志和缓存数据，因为每个服务器都有日志记录，该日志记录用于记录用户何时何地进行了何种操作，有利于进一步分析用户的行为；且应用服务层103的前台接口层1033和后台服务层1034之间是相互独立的关系，因此对于逻辑业务的部署方式也是灵活多变的，后台服务层1034既可以单独位于某一或多台逻辑服务器1031上，也可以将前台接口层1033和后台服务层1034部署于同一台服务器上。一个前台接口层1033的逻辑业务需要对应一个后台服务层1034，但一个后台服务层1034可以服务多个前台接口层1033的逻辑业务。因此前台接口层1033和后台服务层1034可以根据逻辑业务需求和逻辑服务器1031的负载能力对应的调整。

本发明实施例通过前台接口层和后台服务层实现了与负载均衡层的通信，以及记录各服务器的日志，有利于进一步分析用户的行为。

在上述实施例的基础上，将各所述处理逻辑业务的请求根据被访问的频繁程度分配给所述逻辑服务器1031。

具体地，逻辑服务器1031可以为一台，也可以为多台，而负载均衡服务器1021负责将接收到的请求转发到对应的逻辑服务器1031上，且每个逻辑服务器1031上可以部署不同的逻辑业务，使逻辑服务器1031执行对应的逻辑业务，即负载均衡服务器1021将接收到的处理逻辑业务的请求根据被访问的频繁程度分配给逻辑服务器1031，例如：某些逻辑业务被访问的比较频繁，则可以使用多个逻辑服务器1031来分担压力；某些逻辑业务被访问的较少，则可以将某几个逻辑业务部署在同一个逻辑服务器1031上。

本发明实施例通过将各所述处理逻辑业务的请求根据被访问的频繁程度分配给逻辑服务器，提高了系统的负载能力，使系统处理速度更快。

在上述实施例的基础上，图4为本发明另一实施例提供的应用服务层结构示意图，如图4所示，所述前台接口层，包括：WSGI接口10331和后台应用服务10332；

所述WSGI接口10331用于接收负载均衡服务器1021发送的请求，并将所述请求发送至满足正则匹配的所述逻辑服务器1031或所述视频服务器1032；所述后台应用服务10332用于执行接收到的所述请求。

具体地，WSGI接口10331接收由负载均衡服务器1021发送的请求，并解析该请求的URL路径，对其进行正则匹配，由于每个逻辑服务器1031或视频服务器1032对应一个或多个URL路径的正则表达式，所以将该请求分配给对应的满足正则匹配的逻辑服务器1031或视频服务器1032来响应该请求。后台应用服务10332在逻辑上用于执行接收到的请求。

本发明实施例通过前台接口层的WSGI接口对请求进行解析及正则匹配，并将请求发送给满足正则匹配的服务器，实现了请求的合理分配，从而提高了系统的性能。

在上述实施例的基础上，图5为本发明又一实施例提供的应用服务层结构示意图，如图5所示，所述后台服务层1034包括：日志记录服务10341、数据服务10342和缓存服务10343；

所述日志记录服务10341用于记录所述系统日志；

所述数据服务10342用于所述逻辑服务器1031和所述视频服务器1032对所述数据服务层104进行访问；

所述缓存服务10343用于存储系统缓存。

具体地，系统中每个服务器都会产生日志，因此日志记录服务10341用于记录系统中产生的日志；数据服务10342是单独的模块，在模式-视图-控制器(Model-View-Controller，简称MVC)的架构中相当于Model层，服务器需要通过数据服务10342访问数据服务层104；在MOOC系统中，由于课程内容是逐步被教师添加的，各种课程内容(课件、视频、习题等等)具有强时效性，即在课程内容更新后的一段时间内，访问会很频繁，而更早出现的章节和当前更新的内容的访问次数相差较大，相对而言访问次数较少。因此，MOOC系统具有较强的数据冷热分离性质，通过缓存替换策略，如：LRUO1等可以计算出被教师添加的课程内容的“热”值，并将“热”值高的课程内容存放在缓存层中，当有课程内容加入时，会将“热”值最低的课程内容从缓存中删除，从而维持了缓存层的数据尽可能“热”。

图6为本发明实施例提供的应用服务层工作原理示意图，如图6所示，应用服务层的工作原理为：WSGI接口接收负载均衡服务器发送的请求，并将该请求中的URL路径进行解析，并对其进行正则匹配。由于每个服务器，如图6中的服务器1、服务器2…服务器N，对应一个或多个URL路径的正则表达式，故进行匹配后将该请求分配给对应的满足正则匹配的服务器来响应该请求。每个服务器都会产生日志，日志记录服务将记录服务器所产生的日志，并将记录的日志存入缓存层中，并在缓存层中设置一个阈值，当缓存层中记录的日志内存达到预设阈值，则将缓存层中的日志写入数据服务层中，并将缓存层中的日志清除。服务器通过数据服务获取数据，若服务器请求的数据在缓存层中，则数据服务从缓存层中获取到对应的数据返回给服务器，若缓存层中不存在服务器所要请求的数据，则数据服务从数据服务层中获取数据，并返回给服务器。服务器接收到数据后通过WSGI接口返回给负载均衡服务器。

本发明实施例通过应用服务层将请求进行合理的分配给服务器，降低了服务器的负载压力，提高了系统处理的速度。

在上述实施例的基础上，所述数据服务层，包括：

根据数据的形式将数据进行分类并存储在相应的数据库中。

具体地，在数据服务层104中，按照数据的内容可以分为三类不同的存储形式，一类是存储在关系型数据库中的符合关系型数据库范式的可按行存储的业务逻辑数据，如，学生信息、学生注册的课程等；另一类是树状结构的结构化数据，如，题目、讨论等文档形式；最后一类是以独立的无固定范式的文件形式，如，音视频、课件等。这三类不同的形式的数据可以采用不用的服务器进行存储，从而提高存取速度。

在上述实施例的基础上，所述内容分发网络，还用于：

将所述获取静态内容请求对应的数据发送至所述负载均衡服务器1021，并由所述负载均衡服务器1021返回至用户层101。

具体地，内容分发网络1022接收负载均衡服务器1021发送的获取静态内容的请求后，由于请求中携带的是负载均衡服务器1021的地址，因此内容分发网络1022将对应的数据发送至负载均衡服务器1021，由负载均衡服务器1021返回给用户层101。

本发明实施例通过由内容分发网络接收并处理负载均衡服务器发送的获取静态内容的请求，降低了应用服务层中逻辑服务器的负载压力。

在上述实施例的基础上，所述逻辑服务器和所述视频服务器，还用于：

接收到负载均衡服务器1021发送的相应的所述请求后，从所述数据服务层104获取相应的数据并通过所述负载均衡服务器1021返回至用户层101。

具体地，逻辑服务器1031和视频服务器1032接收到负载均衡服务器1021发送的请求后，从数据服务层104获取相应的数据，并通过负载均衡服务器1021返回至用户层101。在该过程中，负载均衡服务器1021对逻辑服务器1031进行反向代理，即用户只向负载均衡服务器1021对应的地址发送请求即可，负载均衡服务器1021把请求分配给更多个可处理请求的服务器，对于用户设备而言，这个过程是透明的，因为用户看来无论哪一台服务器处理了这样的请求，都可以得到想要的结果，并且用户无法直接访问到反向代理背后的服务器。反向代理的作用即在让使用者无从发觉的情况下使用多个服务器，一方面对访问进行了加速，另一方面保护了后端的服务器，并提高了系统的负载能力，提升用户体验。可以理解的是，本发明实施例中的服务器可以是逻辑服务器1031，也可以是视频服务器1032。

在上述各实施例的基础上，所述用户层包括客户端，用户通过所述客户端向负载均衡层发送所述请求。

具体地，图7为本发明实施例提供的客户端结构示意图，如图7所示，客户端用于用户通过该客户端向负载均衡层发送请求。客户端运行在浏览器703内，由后台服务器701传输HTML格式的页面作为响应，其中后台服务器包括负载均衡层、应用服务层和数据服务层，HTML页面上带有该页面引用的层叠(Cascading Style Sheets，简称CSS)样式表和动态脚本(JavaScript，简称JS)，浏览器703通过解析HTML以确定从内容分发网络中加载哪些CSS样式和JS脚本，并根据HTML代码生成文档对象模型(Document Object Model，简称DOM)。浏览器703从内容分发网络702加载CSS样式和JS脚本后，按照加载成功的顺序进行JS脚本和CSS样式的解释过程，根据CSS样式解释的结果，遍历修饰DOM模型706进行显示。客户端中JS脚本采用Model-View-ViewModel(简称MVVM)模型704，将DOM模型706操作、逻辑业务和数据分离开。用户在视图层7043进行的操作，会通过视图-模型层7042反馈到模型层7041，如果模型在操作后需要修改，则模型层7041通过Restful接口向后台服务器701发送异步请求，并得到异步响应之后修改模型的内容，再通过视图-模型层7042自动将修改后反馈到视图层7043。视图层7043通过操作DOM模型706和CSS样式表705以达到和用户交互的目的。这里JS脚本可以基于AngularJS、Backbone等开源MVVM架构进行开发，但不限于上述所列，CSS样式可基于响应布局等框架如Bootstrap等进行开发，以自动适应各种PC、平板、手机等设备。

由于设备性能和网络带宽的提升，当今网页页面的复杂度急剧上升，需要的开发量也越来越大。传统的JavaScript、CSS、HTML语言等由于语言特性问题，导致很多软件工程问题无法解决，例如JavaScript不直接支持模块化，不直接支持线程同步，异步调用容易陷入回调陷阱等特性，使用其写成的代码的可维护性较差。CSS语言也存在无法模块化等特点。解决这一问题可采用其他支持更复杂语言特性的中间语言编写后转换回JS脚本和CSS语言，例如coffeescript、TypeScript、最新的EcmaScript 6标准、SASS、LESS等语言。它们的共同特点是代码易维护、可提高开发效率。值得一提的是，为了减少CDN的请求次数，可将各JS脚本文件合并为同一个文件，可提高加载速度。这样做可以更快的原因是一般JS脚本和CSS语言文件的传输时间很短，此时服务器的响应时间远多于传输时间。故一般而言，为了保证加载速度，并保护自身代码不会随意的被用户查看、修改，会对线上版本的JS脚本、CSS语言文件进行混淆、压缩和合并至同一文件等处理。

图8为本发明另一实施例提供的基于edX平台的MOOC系统结构示意图，如图8所示，系统的整个工作原理如下：

用户通过用户层801中的PC端、平板、手机等设备在浏览器上操作，通过用户层向负载均衡服务器802发送请求，负载均衡服务器根据用户发送的请求类型、网络时延、服务器负载情况对该请求进行重定向，若用户发送的是获取静态内容的请求，则负载均衡服务器802将该请求重定向到内容分发网络803，负载均衡服务器802和内容分发网络803构成了负载均衡层，由内容分发网络803将对应的数据返回给负载均衡服务器802由负载均衡服务器802将数据返回给用户层801对应的客户端；若用户通过用户层801向负载均衡服务器802发送的是处理逻辑业务的请求，负载均衡服务器802将接收到的该请求重定向到逻辑服务器804上，由于逻辑服务器804有多个，且每个逻辑服务器804上部署的逻辑业务可能不同，因此，负载均衡服务器802将该请求重定向到能够处理的、且负载较小的逻辑服务器804上，此时，负载均衡服务器802还有一个反向代理的功能，即可以将该请求发送给多个可处理的逻辑服务器804，对于用户设备而言，只是得到最终需要的结果，并不知道是哪个逻辑服务器804执行的，因为用户无法访问到这些逻辑服务器804，逻辑服务器804接收到该请求后，从数据服务层806中获取对应的数据，并返回给负载均衡服务器802，由负载均衡服务器802将数据返回给用户层801对应的客户端，且在数据服务层中根据数据的不同形式将数据分为了三类，并分别存储在不同的数据库中，一类是关系型数据库，另一类是结构型数据库，再一类是无固定范式的文件数据库；对于用户发送的处理视频的请求与处理逻辑业务的请求大致相同，只是负载均衡服务器802将请求发送给对应的视频服务器805，此处不再赘述，逻辑服务器804和视频服务器805构成应用服务层。

本发明实施例通过设置负载均衡层将用户发送的请求根据系统的当前状态进行分配，实现了动态请求和静态请求的分离处理，同时通过设置视频服务器，提高了视频资源的安全性，减轻了应用服务层的负载压力，并提高了系统的可扩展性。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。