一种Web应用的更新方法、装置和系统的制作方法

一种Web应用的更新方法、装置和系统的制作方法
【技术领域】
[0001] 本申请涉及网络技术领域，特别是涉及一种Web应用的更新方法、一种Web应用的 更新装置和一种Web应用的更新系统。
【背景技术】
[0002] 随着互联网技术的发展，Web (网络）应用程序作为动态网站的实现基础越来越 广泛应用，Web应用程序可W由Java(-种面向对象的程序设计语言）、PHP(Hyp&rtext Preprocessor,超文本预处理语言）、Python( -种面向对象、直译式计算机程序设计语言） 等诸多语言实现，为基于浏览器的客户端用户提供网页浏览等Web服务。
[0003] 对于Web应用，为了便于开发、维护等要求，需要对Web应用逻辑划分层次，使得不 同的开发人员可同时对更层进行开发。
[0004] 其中，分层中一般会包括视图层，可W是用户看到并与之交互的界面，互联网行业 经常调整展现的内容，改变用户交互、文案等W提升用户体验或者发布新功能。
[0005] 在传统的发布过程中，所有代码（包括视图层）的修改，都使用统一的发布过程： 修改代码一代码合并一编译一打包一代码分发一部署。
[0006] 可W看到整个过程中，修改视图层需要经过复杂的发布过程，更新时间十分长。并 且，每次更新都需要发布Web应用的全量的发布包，发布过程占用大量的网络资源。
[0007] 在发布过程中，由于应用容器需要重启，无法对外提供服务。所W集群的发布过程 需要经过停流量、重新部署、开启流量非常复杂的操作。
[0008] 上述发布过程修改代码的业务逻辑风险非常高，每次重新部署会加载所有的资源 文件，包括视图文件W及后端逻辑文件，造成每次发布的风险不可控，稳定性也有潜在的风 险。
[0009] 因此，目前需要本领域技术人员迫切解决的一个技术问题就是；如何提出一种 Web应用的更新方法，用W减少发布流程，减少网络资源的耗费，减少风险，提高稳定性。

【发明内容】

[0010] 本申请实施例所要解决的技术问题是提供一种Web应用的更新方法，用W减少发 布流程，减少网络资源的耗费，减少风险，提高稳定性。
[0011] 相应的，本申请实施例还提供了一种Web应用的更新装置，用W保证上述方法的 实现及应用。
[0012] 为了解决上述问题，本申请公开了一种Web应用的更新方法，包括：
[0013] 接收针对Web应用中独立的展示层的资源更新文件；所述展示层中具有资源文 件，所述资源文件具有加载时间，所述资源更新文件具有修改时间；
[0014] 判断所述修改时间是否大于或等于上一次的加载时间；若是，则在所述展示层中 加载所述资源更新文件。
[0015] 优选地，所述展示层用于加载Web应用中的交互界面；
[0016] 所述展示层中包括W下至少一种资源文件：
[0017] 网页文档、模板文件、图片、级联样式表、脚本对象。
[0018] 优选地，所述资源更新文件为针对所述展示层中的资源文件进行更新的增量文 件。
[0019] 优选地，所述接收针对Web应用中独立的展示层的资源更新文件的步骤包括：
[0020] 将针对Web应用中独立的展示层的资源更新文件存储至对应的目录中；
[0021] 对所述资源更新文件配置修改时间。
[0022] 优选地，所述在所述展示层中加载所述资源更新文件的步骤包括：
[0023] 启动所述展示层对应的模板引擎；
[0024] 采用所述模板引擎加载所述目录中的资源更新文件。
[00巧]优选地，所述Web应用还包括应用层，所述展示层与所述应用层相互独立，所述展 示层与所述应用层在同一个Web容器中运行。
[0026] 本申请实施例还公开了一种Web应用的更新装置，包括：
[0027] 资源更新文件接收模块，用于接收针对Web应用中独立的展示层的资源更新文 件；所述展示层中具有资源文件，所述资源文件具有加载时间，所述资源更新文件具有修改 时间；
[002引时间判断模块，用于判断所述修改时间是否大于或等于上一次的加载时间；若是， 则调用资源更新文件加载模块；
[0029] 资源更新文件加载模块，用于在所述展示层中加载所述资源更新文件。
[0030] 优选地，所述展示层用于加载Web应用中的交互界面；
[0031] 所述展示层中包括W下至少一种资源文件：
[0032] 网页文档、模板文件、图片、级联样式表、脚本对象。
[0033] 优选地，所述资源更新文件接收模块包括：
[0034] 存储子模块，用于将针对Web应用中独立的展示层的资源更新文件存储至对应的 目录中；
[0035] 配置子模块，用于对所述资源更新文件配置修改时间。
[0036] 优选地，所述资源更新文件加载模块包括：
[0037] 启动子模块，用于启动所述展示层对应的模板引擎；
[0038] 加载子模块，用于采用所述模板引擎加载所述目录中的资源更新文件。
[0039] 本申请实施例还公开了一种Web应用的更新系统，所述系统包括发布平台和一个 或多个服务器；
[0040] 其中，所述发布平台包括：
[0041] 资源更新文件发布模块，用于发布针对Web应用中独立的展示层的资源更新文 件；
[0042] 所述服务器包括：
[0043] 资源更新文件接收模块，用于接收针对Web应用中独立的展示层的资源更新文 件；所述展示层中具有资源文件，所述资源文件具有加载时间，所述资源更新文件具有修改 时间；
[0044] 时间判断模块，用于判断所述修改时间是否大于或等于上一次的加载时间；若是， 则调用资源更新文件加载模块；
[0045] 资源更新文件加载模块，用于在所述展示层中加载所述资源更新文件。
[0046] 优选地，所述展示层用于加载Web应用中的交互界面；
[0047] 所述展示层中包括W下至少一种资源文件：
[0048] 网页文档、模板文件、图片、级联样式表、脚本对象。
[0049] 优选地，所述资源更新文件接收模块包括：
[0050] 存储子模块，用于将针对Web应用中独立的展示层的资源更新文件存储至对应的 目录中；
[0051] 配置子模块，用于对所述资源更新文件配置修改时间。
[0052] 优选地，所述资源更新文件加载模块包括：
[0053] 启动子模块，用于启动所述展示层对应的模板引擎；
[0054] 加载子模块，用于采用所述模板引擎加载所述目录中的资源更新文件。
[00巧]与【背景技术】相比，本申请实施例包括W下优点：
[0056] 本申请实施例通过将展示层进行独立管理，在对展示层进行更新时，可W直接在 展示层进行修改，发布资源更新文件，可W不用关必后端代码的更新，无需通过代码合并、 编译、打包等复杂的传统发布过程，大大减少了发布的流程，加快了发布时间，同时，减少了 更新的风险、提高了展示层的稳定性，大大提高了更新效率。
[0057] 本申请实施例通过热加载的方式更新展示层，无需重启Web容器，在集群部署过 程中无需进行停流量、重启Web容器、开启流量送样复杂的发布过程，大大提高了操作的简 便性，进一步提高了更新效率。
[0058] 本申请实施例在更新展示层时，发布增量文件，无需发布全量的发布包，大大减少 了在发布过程的网络资源消耗。
【附图说明】
[0059] 图1是一种传统的代码合并是示例图；
[0060] 图2是一种传统的发布包的发布示例图；
[0061] 图3本申请的一种Web应用的更新方法实施例的步骤流程图；
[0062] 图4本申请的一种资源更新包的发布示例图；
[0063] 图5是本申请的一种Web应用的更新装置实施例的结构框图；
[0064] 图6是本申请的一种Web应用的更新系统实施例的结构框图。
【具体实施方式】
[0065] 为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实 施方式对本申请作进一步详细的说明。
[0066] 对于Web应用，为了便于开发、维护等要求，需要对Web应用逻辑划分层次。
[0067] 一般都采用经典的MVC框架来划分层次。MVC(Model View Controller)把一个 Web应用的输入、处理、输出流程按照模型（Model)-视图（View)-控制器（Controller) 的方式进行分离，用一种业务逻辑、数据、界面显示分离的方法组织代码，送样一个Web应 用可W被分成Η个层一模型层、视图层、控制层。
[0068] 视图（View)代表用户交互界面，对于Web应用来说，可W概括为HTML(Hypedext Markup Language,超文本标记语言）界面，但有可能为 XHTML (The Extensible Hyper Text Markup Language,可扩展超文本标识语言）、XML巧xtensible Markup Language,可扩展标 记语言）和Applet (小应用程序）。一个Web应用可能有很多不同的视图，MVC设计模式对 于视图的处理仅限于视图上数据的采集和处理，W及用户的请求，而不包括在视图上的业 务流程的处理。业务流程的处理交予模型（Model)处理。比如一个订单的视图只接受来自 模型的数据并显示给用户，W及将用户界面的输入数据和请求传递给控制和模型。
[0069] 模型（Model);就是业务流程/状态的处理W及业务规则的制定。业务流程的处理 过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模 型的设计可W说是MVC最主要的核必。业务模型还有一个很重要的模型郝就是数据模型。 数据模型主要指实体对象的数据保存（持续化）。比如将一张订单保存到数据库，从数据库 获取订单，并可W将送个模型单独列出，所有有关数据库的操作只限制在该模型中。
[0070] 控制（Cont