前端中台化的奥秘：解锁格局做大的关键

作者简介

侯策，曾先后就职于法国ENGIE集团、百度等国内外知名互联网企业，具有丰富的开发经验和团队管理经验。曾担任 GIAC 全球互联网架构大会演讲嘉宾，FDCon2019 中国前端开发者千人峰会演讲嘉宾。著有《前端开发核心知识进阶》、《React状态管理与同构实战》。

— —

近些年，“前端领域应该如何在公司业务中落地Node.js”这类问题屡见不鲜。

Node.js自2009年诞生以来便抢尽风头，圈粉无数。但同时一定有工程师不禁要质疑——Node.js真的已经开辟天地，占据架构体系的一席之地了吗？听说Node.js在国外早已如火如荼，国内现在到底是个什么状态？听说阿里因为Node.js扛下了“双十一”，确实如此吗？

没错，风头越大，质疑声也就越多。但当争议和浮华褪去，技术的落地：就让上帝的归上帝，撒旦的归撒旦。那么，究竟应该如何在公司业务中落地Node.js呢？本篇我们就来共同探讨。

▊命中注定的缘分——当Node.js遇见端到端测试困局

端到端测试，也叫UI测试，E2E测试。说白了，与常见的自动化测试非常相似，它站在用户使用的角度，基于协议或其他技术手段打开真实浏览器，与浏览器中页面交互。

端到端测试有着肉眼可见的优势，比如，项目经过不断的开发最终肯定会趋于稳定，在适当的时机引入端到端测试能及早发现问题，进而保证产品的质量。这种让软件代替人工，实施快速、反复测试的方案，收益非常明显。有人总结出端到端收益公式：

端到端收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本

即便收益明显，且相关领域工具层出不穷，但端到端测试的落地实施目前仍称不上广泛。在有条件接入端到端测试的团队中，端到端测试似乎也没有发挥到应有的作用。究其原因，除了“项目特点不适合”，我认为还和端到端测试在开发上线流程中接入的阶段有密不可分的关系。

具体来说，相当多的团队会将端到端测试放到本地执行，和项目代码强耦合。比如，本地通过npm script脚本来实施端到端测试。端到端测试需要保证最新待测试页面具有可访问性，因此相关脚本需要优先保障本地服务成功搭建。以 npm run e2e 这样的npm script为例，相关流程如图1所示。

本质上，这是一种“看心情”的执行方式。一般需要开发者在本地开发完毕之后，自觉执行脚本并观察端到端测试结果。看心情的事情，自然是无法正规化、流程化、平台化的，也注定是比较鸡肋的存在。

顺着上述思路，我们可以想到：借助huskey将上述端到端测试放到pre-commit或者pre-push阶段强制执行。这样一来，端到端测试得以流程化，从“看心情”执行变成了“强制执行”。

但进一步思考，在pre-commit/pre-push阶段执行的弊端也很明显：增加了额外的git hooks，延长了代码提交流程，直接影响了上线效率。如果是一个hot-fix紧急修改bug，这样的时间殇是我们无法接受的。同时，本地阶段执行端到端测试的一个前提是，先要保证本地服务的可用性。暂且不谈开启本地服务的时间开销，一个更尴尬问题在于：本地服务环境和线上环境是有天然差别的，本地执行的端到端测试难以幂等于线上真实效果。

基于上述情况，端到端测试在团队技术体系中，要么渐渐成为一个“漂亮的玩具”，华而不实；要么成为一个开发者眼见心烦的累赘，最终沦为鸡肋。

这么看来，端到端测试想要破局并实现突破，势必在执行流程上进行创新。为此，我们认为：端到端测试应该搬到容器上进行，融合到CI/CD阶段实施，彻底做到自动化、服务化。

这里插入一个知识点：什么是CI/CD阶段呢？

CI和CD都是现代互联网应用编译和发布流程当中的常用词语，分别表示持续集成（Continuous Integration）和持续部署（Continuous Deployment）。

在持续集成环境中，开发人员将代码提交到主干master，并触发Gitlab的hook自动推进代码编译。不同的团队对持续集成阶段的定义也许会有略微不同，我所在团队在持续集成阶段主要完成构建项目流程。具体来说，在这个阶段，中台团队使用基础镜像启动容器拉取最新代码，安装必要依赖，执行单测脚本，并最终commit出下一阶段（持续部署阶段）的镜像。

在持续部署阶段，中台使用构建阶段（持续集成阶段）产出的镜像启动容器，按照一定的pipeline流程，串行发布最新版本应用，最终启动服务。

了解CI/CD的概念之后，将端到端测试后置到CD/CD阶段，并在真实容器中执行——这似乎是一个很好的尝试和创新。

▊ 通过Node.js实现端到端服务

截至目前，根据“在容器中执行端到端测试服务并接入CI/CD”的设计思想，我们可以画出一个简单的流程图，如图2所示。

这里涉及服务粗略设计及基础环境的搭建。那么，如何开发一个在容器上运行的端到端测试系统呢？前面也提到过，其实就是在合适的时机去触发端到端框架的执行，想来就这么简单。但是我们在设计一个系统、一个平台时，应该考虑更多问题，比如：

• 横向多项目扩展能力
• 平台化服务能力
• 运行效率极致化设计方案
• 通报与预警中断机制
• 合理选型技术方案以及存储方案

▊ 总结

在这篇文章中，我们简单介绍了Node.js助力传统端到端测试，要想了解更多关于最终实现破局和创新的双赢项目案例，可以关注我的知乎专栏：Lucas的前端杂谈。

对于前端开发者来说，学习并实施Node.js最关键的就是格局。我们要熟知 Node.js的特性，更要有所谓的“后端”思维、架构思维。我相信Node.js的蓬勃发展和落地，不是因为它具有了某种与生俱来的力量，而是因为它的某些特点符合技术发展趋势和自然更迭规律。

▊ 彩蛋环节

想和我交流更多前端知识，可以关注我的新书：《前端开发核心知识进阶：从夯实基础到突破瓶颈》

前端领域从2013年左右开始崛起，从Backbone到三大框架的此消彼长中，想要梳理出具有体系性的学习要点更难。我是这个特殊时期的亲历者、实践者和深思者，在本书中我简明扼要地讲解了前端应知应会的技巧，使各阶层读者都可从中受益。让我们与时俱进地开启前端攻城狮难以回避的33个核心话题！

▼内容简介▼

本书共分8部分，涵盖33个主题，内容涉及JavaScript基础强化、JavaScript语言进阶、不可忽视的HTML和CSS、前端框架、前端工程化、性能优化、编程思维和算法、网络知识等，聚焦前端开发基础知识和进阶技能，关注前端工程化和体系化，结构清晰，循序渐进，深入浅出。

在重构基础知识方面，本书将标准规范和实践代码相结合。在培养进阶技能方面，本书深度剖析了技术背后的原理和哲学。书中列举的项目设计案例涵盖了许多经典面试题目，不仅能帮助初级开发者夯实基础，还能为中、高级开发者突破瓶颈提供帮助和启发。