vivo商城前端架构升级-总览篇

李笑星

【背景】一年前 vivo 商城还是以 Java 为技术核心，前后台一起，Java 既要负责服务、数据库，也要负责页面的渲染。在早期这种开发模式也能够很好的运行。然而随着业务迭代的加快，前端技术的发展，这种开发模式的弊端越来越明显。主要突出的有以下两个方面：前端技术栈架构繁杂且陈旧，导致迭代速度很难提升到2018年12月，整个商城前端系统随着不同需求叠加积累的原因，造成了不同页面使用不同的技术，比较典型的有jQuery，Vue，FreeMarker，artTemplate，这些不同的技术栈从开发来看，相同的内容，在不同的页面可能使用不同的技术栈，导致需要开发很多遍，对开发、测试来说工作量都是成倍的增长。无法适用多端开发的需求自2017年微信上线小程序功能后，各种小程序如雨后春笋般出现，vivo 商城一开始也推出了自己的微信小程序，然而由于业务发展，需要适配的端越来越多，原先使用原生开发的小程序方式，无法做到一套代码编到多个平台。为了提升开发效率，满足高速发展的业务需求，在过去的一年里，我们通过对商城内外部系统的全面分析，按照分层的逻辑整理出前端架构的升级指导说明。【分层架构】在《前端架构-从入门到微前端》一书中提到，前端架构自上而下可以设计为四个层次，分别为系统级、应用级、模块级、代码级，我们通过这四个层次来分析vivo商城前端架构升级过程中的种种思考和实践，最终形成了一套以 Vue + Node.js 为核心的全端架构方案。技术演进过程：分层架构实施图：一、系统级即应用在整个系统内的关系，比如如何和后台通讯，如何与其他应用集成。针对这一级别，我们进行了前后端分离、多端统一、BFF、SSR等方面的探索和实践。1、前后端分离架构升级，第一步面临的问题便是前后端分离，vivo 商城仍然处于业务高速发展时期，不能因为技术重构而停下业务版本的迭代, 因此业务版本迭代必须要和前后端分离同时进行，那怎么才能做到双线并行，平滑升级？这里举个小例子：当我们分离完成订单模块后，就会通过 Nginx 将关于订单模块的所有请求转发到新的静态资源服务上，如下图：通过前后端分离，我们彻底解放前端，让前端开发效率提升了至少2个档次。更多技术细节比如：新老页面如何同步信息，如何容灾容错等等，请关注我们的系列第二篇《vivo商城前端架构升级(二)：前后端分离篇》2、多端统一从 PC 浏览器，到移动端浏览器、到 App 内嵌，再到各个小程序，再到服务端、客户端。繁荣的生态，犹如百家争鸣，百花齐放。然而，繁荣的背后，对前端工程师的挑战，则与日俱增。我们承接的端越来越多，新的端不断的出现，如小程序、快应用等。前端工程师陷入了如下套娃陷阱：现有代码、新代码要适配新的端开发场景已经适配新的端开发场景的代码成为了现有代码现有代码、新代码要适配新的端开发场景循环...我们希望解决这种问题，希望做到一套技术架构方案【代码】，可以覆盖现在的端和未来的端。通俗点说，我们希望做到如下图所示的能力：在这种前端开发背景下，多端统一出现了。它是前端的一个未来趋势，它也是解决上面套娃陷阱的一剂良药。更多细节内容，请关注我们的系列第三篇《vivo商城前端架构升级(三)：多端实践篇》3、BFF业务现状随着端的增多，新的接口数量呈现爆发式增长，老的接口为了适配各端，也会增加了各种不同的字段，导致前后端适配多端的工作量越来越大。但是抽象来看，大部分端的变动都是UI层级的变动，很少有底层服务的改变，所以带来了一个问题接口究竟是面向UI，还是面向通用服务？为了解决这个问题，Sam Newman 发表了一篇文章，讲述了这种体验者专用 API 的方式，并将其称为 BFF（ Backends for Frontends ）模式。在 BFF 理念中，最重要的一点是：服务自治，谁使用谁开发。服务自治减少了沟通成本，带来了灵活和高效。关键技术商城前端积极适应前端技术的发展，为了提供一流的用户体验，积极推动BFF层在商城业务中的实现。直连Dubbo：Apache Dubbo 是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。我们使用了社区提供的 Dubbo2.js 进行 Dubbo 服务的调用，并且做了一些封装来优化发开体验。集成GraphQL网关：GraphQL 是一个开源的 API 数据查询和操作语言及实现为了实现上述操作的相应运行环境。相较于REST以及其他 web service架构提供了一种高效、强大和灵活的开发 web APIs的方式。（1）请求你所要的数据 不多不少（2）获取多个资源 只用一个请求（3）强大的API调试工具4、SSR自从前后端分离后，前端采用了 SPA 技术，走的都是 CSR（客户端渲染）的模式。使用 CSR 的优势在于节省后端资源、局部刷新等，但随着应用的日益复杂, 首屏渲染时间不断变长, 并且存在严重的 SEO 问题。所以为了解决 SPA 应用遇到的这些问题, 我们必须考虑 SSR。SSR 即服务端渲染，是指由服务器端完成页面的HTML 结构拼接，并且直接将拼接好的HTML发送到浏览器，然后为其绑定状态与事件，成为完全可交互页面的处理技术。主要优势在于：更好的 SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。更快的内容到达时间 (time-to-content)，特别是对于缓慢的网络情况或运行缓慢的设备。为了避免重复造轮子，我们使用了社区非常优秀的SSR框架 nuxt，通过一系列的优化，比如：页面缓存、组件缓存、API缓存、最小化渲染等方式，最终让我们页面在 500ms内就能全部展示，这是用户体验上的极大提升。二、应用级即应用外部的整体架构，如多个应用之间如何共享组件、如何通信、如何开发通用脚手架等。在应用级别的架构上面，我们主要沉淀了适用于商城的 UI库，为其他商城衍生项目提供基础组件支持。1、组件库移动端的设计千变万化，市场上非常流行的移动端的组件库比如 antd-mobile ， vant ，他们对于开发通用型的 App，非常高效且美观，然而大部分自主研发的 App都有自己的一套设计风格和理论。如果使用流行的组件库，就会出现频繁需要修改源码，以适应UI风格的变化。这样的工作量日积月累，就会变得越来越大。所以我们还是建议如果是做自己特色的App，还是要自建UI库。如果感觉自建 UI库难度较大，可以先 fork 一份流行的组件库，学习其中的各种实现，慢慢形成自己的 UI库。商城也实现了自己的 UI库，目前已经在商城、秒杀、vivo 内购、v客联盟等应用中广泛使用，极大的提高了开发效率。如下图：三、模块级应用内部的模块架构，如代码的模块化、数据和状态的管理等，在项目中比较典型的是我们设计了针对 Vue 的极致模块化方案，顶层 page 设计，数据自治等方面的工作。1、极致模块化我们的方案摈弃了官方推荐的按文件类型组织模块，而采用按照功能组织模块，这种"可插拔式"组件设计，让代码按照功能聚合。一个文件包里面包含该功能的所有实现，包括图片、样式、脚本、数据流、组件等等，这样另一个项目想要使用，直接迁移即可，极大地减少了迁移的成本，并且还有一个优势是，如果这个功能以后下架，直接删除即可，不必各个文件夹下找文件，极大地提升了代码的简洁性和可维护性。 confirm gitdev_abtest_gray) tree .├── api.js // 接口资源├── components // 内部组件│ ├── component1│ │ ├── images│ │ ├── index.scss│ │ └── index.vue│ ├── component2├── images // 图片资源├── index.scss // 样式资源├── index.vue // 逻辑实现├── module.js // 数据流└── trackData.js // 埋点2、顶层 page 设计所有的页面都会有很多通用的功能，比如加载前的骨架图、出错后的处理逻辑、数据采集逻辑、上拉刷新、下滑分页加载，全局 iOS 适配等等，这些功能在逻辑上是需要抽象的，避免各个页面多次实现，导致浪费开发资源和降低程序的可维护性。针对此我们实现了一个顶级 page 组件，所有的页面都继承于这个 page 。做到通用性的功能全局管理。顶级 page 的部分 API 使用如下：