Velocity 不用愁！Velocity 系统的前端工程化之路 | 京东云技术团队

Velocity 是一个基于 Java 的 Web 页面模版引擎。十多年前，Velocity 将 Java 代码从 Web 页面中分离出来，使得开发者能够并行网页开发和 Java 开发。随着十年前后端分离的浪潮涌动，回首再面对这些基于 Velocity 的旧系统，无论是后端还是前端人员维护，都会存在诸多问题：

（1）后端人员维护：不熟悉前端开发模式，需要花费大量精力学习 UI 和 Js 框架；

（2）前端人员维护：Velocity 渲染依赖 Java 环境，需要花费大量精力学习 Maven 工程、环境配置，且前端 MVC 框架版本老，开发效率低。

这种情况广泛存在于零售内部的一些旧系统中，且业务需求的不断迭代，会导致系统维护成本越来越高。针对需要频繁迭代的页面模块，常见的应对措施是采用前后端分离方案，对页面进行整体重构，但如此以后，整体重构的代价是巨大的，主要体现在如下几点：

（1）需要覆盖所有的业务场景和需求；

（2）缺乏覆盖全场景的测试物料；

（3）页面重构本身不带来业务价值。

我们团队承担了 B 端业务，由于业务启动时间早，也不可避免需要维护这些 Velocity 系统。

针对老系统维护难的痛点，我们在实践中探索了一种对老系统侵入程度低、技术架构缓步升级的技术路线，分为 4 个步骤，分别是（1）搭建 Velocity+MVC+MVVC 混合架构；（2）建立 Velocity 单文件组件化能力；（3）创建 Velocity 本地沙盒环境；（4）Velocity 页面前后端分离。下面分别进行详细说明：

一、 搭建 Velocity + MVC + MVVC 混合架构

Velocity 系统多数还在使用 JQuery 等 Js 框架，开发效率低，亟待改善。对比 MVC 框架和 MVVC 框架，MVVC 框架封装了视图层逻辑，开发效率显著提升。

因此第一个步骤是在 Velocity 页面中引入 MVVC 框架，实现两套技术架构的共存。我们引入了 Vue 以及配套的 UI 组件库，考虑 Vue 的主要因素有以下几点：

（1）Vue 支持 Js 资源链接的方式引入和使用，即在 Velocity 页面中加入一行 script 标签即可实现开箱即用；

（2）Velocity 的页面编写语法与 Vue 的模板语法非常接近。

混合架构内部，模板渲染需要分两步进行： Velocity 模板首先在服务端渲染为 Vue 模板，Vue 模板在客户端渲染为最终页面。

混合架构存在的问题是，由于一些 Session 内关键参数是服务器直出，Vue 并不能直接获取到这些参数，因此传参的方案是在页面中提前埋了一些占位符，Vue 执行时通过访问 DOM 来获取。

后续需求迭代时，可以逐步将业务逻辑从老旧 MVC 技术栈迁移到新的 MVVC 技术栈中，实现开发、维护效率的提升。

二、 建立 Velocity 单文件组件化能力

当项目规模较大时，不同模块之间可能存在一些相似的功能或逻辑，摆在面前的问题是如何实现模块级的功能复用。

因此第二个步骤是在 Velocity 系统中引入组件化能力，实现跨页面代码复用。Velocity 系统由于渲染依赖 Java 环境，难以适用基于 NodeJs 的前端工程化能力，无法直接使用 Vue 的单文件组件化能力。幸运的是，可以利用 Velocity 的包含（#include）和解析（#parse）能力，配合 Vue 的 API 接口，实现一种创新型的 Velocity+Vue 单文件组件化技术。

如果你熟悉 Vue，你肯定对 Vue 单文件组件很熟悉了，即一个文件名以.vue 后缀结尾的文件，它描述了一个 Vue 组件，内部结构的三板斧：template、script、style，简单来说分别描述了组件的模板呈现、逻辑交互、css 样式。

Velocity 单文件组件的组织方式参照了这个层级结构，使用一个文件名以.vm 后缀结尾的文件，描述了一个 Velocity 组件，由于缺乏工程化的能力，区别点在于：（1）为了兼容低版本浏览器，需要使用 script 标签来承载模板；不考虑浏览器兼容性的情况下，也可以直接使用 template 标签。（2）需要手动调用 Vue.component 执行组件的注册。

实现单文件组件化之后，Velocity 页面可以通过粒度更小的组件来层层组装，实现系统的业务耦合程度进一步降低。

三、 创建 Velocity 本地沙盒环境 + 前端工程化

前面两个步骤对系统整体架构进行了大幅优化，但是仍有一个痛点没解决：Velocity 渲染依赖 Java 环境，习惯了本地开发的前端同学会很无语：改一个小问题需要本地盲开发->在线部署容器->看效果->继续盲修改，一来二去几个小时就过去了。

因此第三个步骤是实现 Velocity 本地编译和开发环境，并且引入工程化技术实现热更新。

解决 Velocity 本地编译的核心思路是模拟 Server 的环境变量，并且支持 Velocity 语法编译。我们搭建了一套基于 Velocity 的前端沙盒工程，前者通过在工程中 mock 服务端变量的方式来实现，在本地 JSON 数据源承载这些环境变量；后者是基于 Velocity 语法 AST 重构，开发了一套解析引擎 Velocity-loader，支持在 webpack 中实时解析文件并注入环境参数。

沙盒能力引入后，开发流程转变为本地实时开发 Velocity，热更新达到毫秒级，开发体验只有一个字：爽。

四、 Velocity 页面前后端分离

事实上，对比前三个步骤，我们距离 Velocity 页面彻底前后端分离已经很接近了。

第四个步骤是真正实现 Velocity 页面的前端独立构建和部署，并永久摆脱依赖 Server 端渲染。但由于 Vue-loader 实际上会在工程编译时把模板语法解析成 render 函数，已经破坏了模板语法的结构，因此不能支持在客户端动态的解析 Velocity，需要固化渲染环境变量。Velocity 的动态数据渲染部分需要改写为 Vue 的语法来实现，托靠客户端 Ajax 来刷新动态数据和页面。

至此，我们完整实现了对 Velocity 后端应用向前端工程化逐步演进之路，路漫漫其修远兮，吾将上下而求索，也欢迎各位看官共同探讨。

作者：京东零售 陈震

内容来源：京东云开发者社区