告别是为了彼此变得更好---SPA 前后端彻底分离的探索之路

前后端分离,目前对于一个前端开发者来说,或者将其放在软件开发领域的历史背景下,都是再平常不过的一件事情了。17 年时进行了一个前后端彻底分离方案的实践,每次想起来这个方案时,总觉得它不够完美。现在将其写下来和大家交流,期望可以促进方案的后续完善。

邂逅

自从接触前端开发,一共接触到了三种前端项目发布的方式:

  1. 通过 FileZilla 直接将前端资源文件上传到业务服务器
  2. SSH 到业务服务器,通过 Git 更新前端项目代码,然后进行新版本资源的构建
  3. 将构建好的前端资源文件推送到 cdn

刚加入丁香园前端团队时,前后端分离的 SPA 项目的实现方式是:前端和服务端项目是两个代码仓库,HTML 模板由服务端语言(JSP/PHP)输出,HTML 引用的前端资源是通过前端资源发布系统发布到 cdn 上。涉及到 cdn,就会面临 cdn 缓存的问题。解决 cdn 缓存问题的方案是传统的时间戳机制。具体操作流程是服务端提供一个更新时间戳的接口,当前端每次发布新版本后,去调用更新时间戳的接口。

基于时间戳机制的前端项目发布流程大致为:

  1. 在发布系统进行项目发布
  2. 通过相关接口更新时间戳

看上去这个流程很简单高效,对不对?让我们来根据实际情况来细化一下这个流程:

  1. 登录发布系统
  2. 在发布系统点击对应项目的发布按钮
  3. 等待前端资源构建并发布成功
  4. 资源发布成功后,调用更新时间戳的接口
  5. 发布完成

流程细化之后,我们可以把流程分为5步,平均算下来每次前端同学进行一次项目发布,大概需要3分钟。在等待发布系统构建资源的时候,前端同学可以并行的去做一些放松的事情,比如:去餐吧喝杯咖啡,上个厕所,随手修个 bug。放松之后,更新一下时间戳,新版本发布便大功告成。接下来便可以进入愉悦的新需求开发之旅了,一切都显得如此惬意。

去年的我,也是这样认为的。因为当时在负责的新版调查问卷(SPA)和 Insight(可以看做 n 个 SPA)等项目,大概平均每天发布一次,所以用来发布的时间成本还是能接受的。

16年年底时,加入了大众医学部,开始和伙伴们一起负责来问丁香医生等项目。项目依旧是前后端分离的 SPA,构建好的前端资源依旧是发布到 cdn,解决 cdn 缓存问题同样采用的是时间戳机制。一切都是熟悉的配方,熟悉的味道。当参与了一段时间的需求迭代后,我发现事情似乎没有想象的那么简单。

让我有这种感受的原因,主要有两点:

  1. 更新时间戳的接口即使在内网,也是需要鉴权的。并不像调查问卷等项目,直接在浏览器访问一下更新时间戳的接口就可以了。鉴权的方式是需要微信扫码。
  2. 需求迭代速度谦虚一点说,很快。仅生产环境,几乎每天都要发布至少一次。

此时细化的一次发布流程变为:

  1. 登录发布系统
  2. 在发布系统点击对应项目的发布按钮
  3. 等待前端资源构建并发布成功
  4. 资源发布成功后,调用更新时间戳的接口(需要鉴权)
  5. 访问更新时间戳的页面,页面弹出鉴权二维码
  6. 发布者拿起手机
  7. 打开微信,点击扫一扫,扫描二维码
  8. 微信接收到同意授权的模板消息
  9. 点击模板消息进行授权,授权成功后进入更新时间戳页面
  10. 点击更新时间戳按钮
  11. 等待生效(服务端有缓存机制)
  12. 发布完成

一次前端发布的时间,平均在7分钟左右。在实际工作中,需要在测试环境、(预发环境)、生产环境进行发布。从团队的角度来看,管理后台等项目也在采用这种发布方式。毛估一下,每周团队在项目发布上就需要花费 2 ~ 3 个小时((7min * 2 * 2 * 5)/ 60)。

此外,这种前后端分离的方式还有以下几个问题:

  • HTML 模板开发效率较低。项目所使用的 HTML 文件需要前端同学写好后发给后端,后端再进行“套模板”,这种做法本身就有一个流程的复杂度。后端同学如果对 HTML 掌握的不熟练,那么需要前端同学去跟后端同学结对编程,来确保 HTML 的正确,此处有一个沟通成本。项目上线后,如果需要对 HTML 进行改动,需要前端先修改好 HTML,然后把 HTML 发给后端,后端再次进行“套模板”。后端同学修改好 HTML 模板文件后,可能不会因为这一个改动进行发版,需要跟随着后端项目的其他改动代码一起发版,此时对于前端、测试同学有一个等待的成本。
  • cdn 资源有一点点浪费。页面中所有前端资源是使用同一个时间戳,这意味着每次更新时间戳都会更新页面中的全部资源引用地址,从而当用户再次使用应用时,需要重新下载页面引用的所有资源。而前端的某个新版本,可能仅仅是需要更新部分资源文件即可。
  • 加长了应用的响应时间。这一点同样是由上一点描述的时间戳机制导致的,重新下载“新”的资源而不是利用浏览器的缓存,必然会导致用户需要等待更长的时间。

念念不忘,必有回响

为了解决上述问题,我设计了一个的方案:

方案说明:

  • 前端项目生产环境构建时,将文件名中加入 hash 值。
  • 前端资源发布系统在资源构建成功后,将 index.html 同步到业务服务器(本着线上项目不做写操作的原则:会把 HTML 文件放到后端项目和Node项目目录之外的地方)。
  • 在业务服务器上新增一个 Node 服务。该服务的作用之一为:收到浏览器端首页的请求时,将 index.html 返回。
  • 当用户访问应用时,由运维将请求首页 HTML 的请求转给 Node 服务,其余业务接口保持原有方式不变。

方案确定后,在团队小伙伴的配合下,该方案在一个流量较小的项目上线了。

新的火花

上述方案存在一个问题的:在原有的技术体系中,引入了 Node.js。本质上是在稳定的技术体系下,增加了技术复杂度。因此,在不增加技术复杂度的前提下,需要开始探索新的解决方案。在后端同学的配合下,新方案相比于引入 Node.js 方案改动如下:

  • 业务服务器给前端发布系统提供同步 HTML 模板文件的接口,前端发布系统每次成功构建前端资源后,调用该接口将模板文件同步给业务服务器。
  • 业务服务器获取模板文件后,将文件内容存入数据库,持久化存储模板。在服务重启和用户请求时,服务端从数据库中获取模板。
  • 服务端可以将从数据获取的模板放到缓存中,这样可以避免高频的读取数据库操作。对应的业务服务器需要监控数据库中的数据变化情况,以便于及时更新缓存中的模板资源。

方案上线后,前端项目的发布流程变为:

  1. 登录发布系统
  2. 在发布系统点击对应项目的发布按钮
  3. 等待前端资源构建并发布成功

前端项目发布这件事,终于变成了点击一下发布按钮,整件事情就做好了。整个发布流程耗时变为不到一分钟。此外,当前端需要改变 HTML 模板时,也不再需要将文件发给后端同学,苦苦等待后端项目的发版。

该方案上线后,组内同学在周报中提及到的使用新方案后的感受为:

为了方便前端同学获取同步模板的进展,在发布系统中增加了同步过程的提醒:

没有银弹

上述方案相比于 JSP/PHP 提供 HTML 模板存在一个问题,就是在前端在构建 HTML 时,(暂时)不能将应用初始化的数据放入 HTML 中。解决方案是服务端提供一个接口,在应用启动时去调用该接口获取初始化数据。

对于前端加载优化,整体上思路上是需要减少网络请求的,而此方案却在增加网络请求,这意味着页面加载时间会变长。但是综合利弊之后,还是决定采用这个方案。

最终方案上线后,其实心中已经做好了页面平均加载时间会变长的心理准备,但是有些意外的是,几天后去 mta 看数据发现全国范围内平均响应时间缩短了 0.2s 左右。为什么不升反降,目前我还不能得出一个准确的答案。猜测的一个原因是: hash 值的方案避免了用户进行不必要的资源更新。

待完善

上述方案虽然做到了前端项目的一键发布,但是还不够称作为一个完善的解决方案。因为该方案只是解决了 SPA 类型项目的发布问题,对于之前“套模板”重 SEO 的项目而言,并不是很适用。(提到 2018 年的技术浪潮下,如何开发一个重 SEO 的网站这个话题,又可以写一篇文章了,其中的心路历程还是蛮坎坷的)

言归正传,在前端资源发布系统层面,该方案可以考虑去增加文件历史和发布回滚功能,以备不时只需。

这个方案是和业务线的服务端同学配合实现的,从公司层面来看,可以考虑的点是是否可以将这个方案做成一个通用的服务。

在和团队的交流时,相学长提出可以将 HTML 引用的资源抽象成 JSON Tree 进行存储。之前看过一些类似的解决方案,不过目前自己还是更倾向于分开的“更彻底”,这样可以让服务端同学更安心的提供接口。

写在最后

由于水平有限,欢迎大家对此方案提出建议。非常期待。

本文作者:丁香园前端工程师 @志遥

关注下面的标签,发现更多相似文章
评论
说说你的看法