🌞

记录一次借壳开发重构之旅

内部工具的一次重构，记录下重构过程遇到的坑背景内部使用的活动搭建平台，由于历史原因，组件模块开发体验比较差。开发入门门槛以及对整个项目结构的理解成本比较高，同时整体的开发效率比较低。搭建工具的工作原理
145 1 min

原文链接在语雀：https://www.yuque.com/wumingshi/rkh1qq/


内部工具的一次重构，记录下重构过程遇到的坑

背景

内部使用的活动搭建平台，由于历史原因，组件模块开发体验比较差。开发入门门槛以及对整个项目结构的理解成本比较高，同时整体的开发效率比较低。


搭建工具的工作原理比较常规，基于后台的配置文件，在渲染端（ssr）根据配置加载不同的组件，也就意味着组件的载入是一个异步的过程。


现状

活动工具的整体技术栈为：Regular.js + Node.js + SSR。


组件的目录结构：

image.png

开发组件跟着组件仓库，如上图中的只有packages内的内容是实际开发者需要关注的内容，其他的内容大部分都是和业务开发无关，开发工具通过Koa静态托管文件，本地起一个代理加载组件文件实现本地开发。

主要存在的问题：

  • 组件没办法和管理后台联动
  • 组件的容器非最新，线上线下显示不一致
  • 组件没有办法和其他组件共同联通，即多组件共同开发
  • 整体开发流程特别繁琐：npm link + npm run watch + npm run start。然后依然需要做各种 hack 工作
  • 开发工具的规范无法收敛
  • 项目结构混乱
  • ...


基于以上，最终是想通过借壳开发，保证线上线下无差别，并在开发过程中可以0感知把组件托管到本地。整体的工作思路比较简单，主要在于如何在历史深坑中，一个个去“补填”

重构后的架构

image.png


统一代理服务

本地启动一个代理服务，作为一个全局请求的统一入口，负责分发各个请求。

image.png

根据不同的类型，请求到不同的接口下。

本地组件静态服务

对于本地的组件，依赖webpack watch 打包出静态文件并监听，如有多个，则启动多个webpack watch进程；同时启动一个静态资源服务（port：8061）进行托管，

为什么选择webpack watch？

  1. 历史组件的构建方式都是webpack watch 可以比较好的兼容老的版本。
  2. 方便内容托管在同一端口下，方便多组件共同启动。

hot live 这里依赖webpack-plugin-serve

启动服务后，访问127.0.0.1:8001/activity

登录依赖第三方登录，活动工具后台的的服务端是一个node 服务，页面也是由服务端直出，登录的状态是依赖node-session通过第三方登录进行node登录。管理后台不是一个前后分离页面，访问该路由，直接重定向到管理后台，直出document，但是当前域名下并没有登录态。


而我们这里需要一个本地第三方登录。如何解决呢？

这里通过前端静态服务托管一个登陆服务页面（admin-login），通过第三方登录写入127.0.0.1 登录cookie，写入cookie后，重定向到node-server，通过重定向补齐session状态，完成 node 登录。

这里会有一个问题，即 node-server 未登录以及前端模拟登录完成重定向到node-server，都是未登录并返回302，那如何判断何时触发本地登录流程呢？

这里通过判断返回的 status code 为302，并重定向3次作为触发本地流程的起始条件

image.png

管理后台组件连接到本地开发环境

上文已经提到，本地组件已经被托管在8061端口下，那如何区分把本地的开发组件连接到真实环境中，组件的加载是一个异步过程，就是会单独通过 script 标签 加载组件的js/css。

在启动的时候，通过选择的开发组件，生成一个配置文件。通过此配置文件，对所有的组件资源进行筛选，如果是开发组件，则将资源重新链接到8061端口下的静态地址。这里并没有区分版本号，即只要本地有代理，则直接会覆盖线上的资源，从而达到本地调试的目的。

同理，对于启动开发的组件这里也需要动态插入到module list中，从而保证本地模块可以在页面编辑的时候被正确检索到。


用户端的组件连接到本地开发环境

活动工具搭建出的页面是通过ssr输出到用户。除了基本的容器及热区等，是通过ssr直出，而组件本身的内容其实是通过csr重新生成的。而组件的相关信息是通过直接注入到html中

<script>
 var __moduleJsUrl__ = ["/tms3/posterGenerate/posterGenerate/1.0.3/index.min.js"] 
 var __moduleCssUrl__ = ["/tms3/posterGenerate/posterGenerate/1.0.3/index.min.css"] 
</script>

容器的js会根据这个全局变量动态注入组件js。

那这里就是直接暴力拦截document内容，把其中的内容里追加本地调试的组件。


至此基本调试流程已完成。


新的组件项目的结构

image.png

项目中的包含的内容和开发高度相关，其他均收敛到一个脚手架中

// package.json

{
  "name": "xxx",
  "moduleType": "xxx",
  "title": "xxx",
  "version": "1.0.0",
  "icon": "th-large",
  "description": "",
  "base": "react",
  "tmsVersion": "3.0",
  "main": "src/main.js",
  "scripts": {
    "init": "tms3-cli init",
    "start": "tms3-cli watch",
    "build": "tms3-cli buildAll",
  },
  "keywords": [
    "activity",
    "tms3.0"
  ],
  "devDependencies": {
    "@music/tms3-cli": "x.x.x"
  },
  "dependencies": {
    ...
  }
}

对于组件本身的脚手架也有调整，主要是项目组织方式以及配置的优化，这里先跳过。


主要功能介绍：

tms3-cli init: 通过交互的方式生成组件的脚手架，组件的脚手架是包含完整的依赖，这里生成的时候回根据最外层的依赖，动态删除组件的依赖，一定程度提高开发及构建速度，防止包的冗余。毕竟一个项目的组件的数量可能达到几十个。

tms3-cli start：一键启动开发，启动各个服务

tms3-cli buildAll: 构建所有组件，这里增加了多进程构建，对于多组件的项目提升至少200%，

发布平台, process.NODE_ENV 默认为production，装依赖主要特别的把devDepencies装全。

tms3-cli us: 一键升级老的脚手架项目。

image.pngq


其他

  • 新版本检查

image.png

  • 组件脚手架及部分方法热更，在watch及init方法的前后会注入。用于在一些极端的情况做到及时触达，比如重要的通知，或者一些变更等。
  • 试水了wasm在node的运行，可以保存一些非明文的信息，对于这部分感兴趣的可以参考链接
  • 统计项目覆盖服务 based on gitlab api。


最后

本次重构是基于“历史包袱”，在不影响现有业务的开发前提下一次比较平滑的升级。值得肯定的是，没有耽误业务方的迭代，对于开发及构建有非常大的提升。




updatedupdated2024-10-122024-10-12