作者:零零水 https://juejin.cn/post/6952066955868110879
在阿里加班加腻了的我,遂选择国企,作为人生的下一站。
众所周知,当今中国,不考虑某些不和谐的东西,最赚钱的只有两个行业,那就是 IT,以及金融。
于是,聪明的我,既然已经干过 IT 了,那么接下来,当然要去干金融小……!——哦不,是在金融业干 IT。
于是,我回到了西安,选择了一家信托公司开始干前端组长(请不要理解错,不是那个干),这个还算有点前途的工作。
这是一家信托公司,也是一家国企。
众所周知,大部分国企的技术体系,很一般。不过还好的是,从上面的大领导,到部门领导,都很有能力,也很有魄力。这也是为什么我来这家公司的原因。毕竟,来国企虽然虽然为了稳定,但也不想混日子嘛。
在我刚刚来到这家公司时,面对的是前任留下的烂摊子。具体来说,有以下这些:
特别要说一下这个前端工程相关的问题:
基本上,只有烂摊子,没什么值得称道的地方。
唯一值得庆幸的是,领导的支持力度还可以,虽然只能招外包开发,但是招人的权利全权放给我,我说要,那就招。
19 年 5 月,我写过一篇 8000 字的《大型项目前端架构浅谈》,当时在掘金曾经最高升到历史总榜第三的位置(累计阅读接近 12w,点赞 3500+)。但又有一些人反馈,觉得说的有点浅,缺少具体实现方法。
但那篇,即使谈的比较浅,也已经 8000 字了,这篇相对上一篇博客,细化谈了几点,我在写这句话的时候算了一下,大概也已经有 8000 字了。
所以不是我不想谈深一点,是想写深一点,每一点都可能有 8000 字以上,尽力了。
在做事前,必须明确思路。几个原则:
结合以上情况,我判断:
虽然以上问题,我都可以一个人解决,并且做的很好,但是,我一个人写不完所有的项目。即使我能力再强,但随着团队扩大,边际效益必然越来越低。
所以我先单独约每位同学聊天,了解其为人想法,以及个人情况,为接下来的行动做准备。
谈话过程中,我先了解他们想法、个人情况,基于其个人意愿,为他们的未来提出设想,并给出具体可行的发展方向。
谈话结果总体还可以,起码大家表面上来看(防盗:作者:零零水),大家都是有想法有干劲的(最后验证,的确如此)。不用担心有人故意拖后腿。
【ok,人的问题解决】
对已有问题进行分析判断:
问题 | 严重程度 | 修复成本 |
---|---|---|
接口变更 | 高,严重影响进度 | 低,只要和后端协调好即可 |
缺少 CI/CD | 中 | 低,需要写个脚本自动从 gitlab 同步代码 |
脚手架质量低 | 中 | 中,对旧项目影响大 |
接口跨域 | 高 | 已有代码中,新工程低 |
组员代码不规范 | 高 | 高,需要时间 |
忘了列出来的 | * | * |
【现有问题明确】
前端架构师进行前端技术建设的核心目的,是为了提高开发效率,保证开发质量,为保障项目高质量按时交付。
同时兼顾考虑中长期研发实际情况,结合团队实际能力,为未来做技术储备,为业务发展提供更多的可能性。
于是,将自己的任务分为以下三类:
我要从以上三个角度切入,既能解决已有问题,又能为长期未来提供支持。
【方向明确】
于是,开始干活,用了 4 个月,做了以下工作。
基础架构的核心设计,是流程设计。好的流程可以高效率低成本的运行,同时可以通过流程化规避大量问题。
基本流程设计如下:
在这个流程中,代码被分成了三层:【个人代码——主分支代码——线上代码】,其中线上代码又分成了 dev、qa、pro 三个版本。
开发人员只对个人代码拥有可控权,而无法直接影响改变主分支代码,当需要提交到主分支时,需要发起 merge 请求,并经过管理员 review 代码后,将其代码合并到主分支。
而主分支代码又和线上代码进行隔离,(防盗:作者:零零水)由管理员将指定版本代码发布到指定环境。无论是哪个 dev、qa 还是 pro,都将直接从 gitlab 上拉取指定提交,然后打包发布。
通过这种二次隔离,导致代码环境可控、干净、稳定。因此,无论在哪个环境,代码的发布都是幂等的,换句话说,是稳定可控可预期的。
通过以上流程,前端代码能被保证以高质量高稳定性的状态,运行在服务器端。
传统前后端分离项目中,前端代码通常由前端自己独立部署,打包完成后,直接部署到指定目录下。但该流程有几个严重的问题:
因此,根据实际情况,使用自研的前端 pipline 管理。核心有以下几点:
在 nginx 层,html 做无缓存处理,每次加载都加载最新的。其他静态资源做 cache,过期时间 15 天,发布流程见上图。切换版本时,具体如下:
2.多版本共存:由于静态文件本身资源大小比较小(由于做了公共静态文件抽离,所以其实更小),(作者:零|零水)目前财富二期打包后只有 16 MB,未来二次优化后,将降低到 10 MB 左右。所以即使多版本同时放到服务器上,其占用也不多。
管控方法是作为入口的 html 文件是唯一的,通过修改 html 里,指向的静态资源文件的版本号,来指定用户当前访问的版本号。用户访问流程图如下:
可以从上图中看出,用户只会在第一次访问的时候,加载静态资源。其余时间访问的都是本地 cache,可以极大的提高用户访问速度和用户体验,降低服务器网络 IO 压力。
而 html 不做缓存处理,又可以避免在新版本发布后,用户访问到的是旧版本页面,而导致业务处理出现异常。
同时,因为每个版本号都是和 commit 强耦合的,所以无论哪个环境下,同一个版本号的代码,都必然是幂等相同的,不需要担心不同环境下代码表现不同的问题。
由于我们通常访问的是内网,因此,需要考虑以后内外网隔离的问题。因此,搭建私有 npm 源,提前从基础设计层面解决问题。私有源采用开源技术方案 Verdaccio。优势有以下几点:
通过以上三点组合,从架构层面上,解决了发布的线上代码不确定性问题,提高了前端代码的可靠性。
另外,我们前端组会将一些自己封装的 npm 包发布到自己的 npm 源,提供给不同工程使用,避免重复开发带来的研发浪费,以及开发人员能力不稳定带来的公共依赖不可靠的问题。
除了业务代码以外,前端还会有一些公共静态资源,例如 Vue 的 js 文件、ElementUI 的资源文件、Echarts 资源文件,以及一些图片文件等。
对于这些文件,是所有工程所共享的,假如这些文件分散在各个工程里,既没必要,也容易导致不同工程依赖文件不统一。另外,也会重复加载这些文件,浪费网络带宽和静态服务器存储空间,没有意义。
因此,设一个公共静态路径,通过在脚手架里进行配置,当需要加载这些资源时,直接去指定 nginx 静态服务器里加载,并做长时间 cache,可以提高访问效率和性能。
未来,将做一个专门的静态资源管理服务,用于将静态资源(主要是图片),传到静态资源服务,并进行 CDN 加速,然后前端工程通过直接引入图片 url 来使用这些资源。这样可以减轻自己的服务器的网络带宽消耗。
以上都是已实现的,其他还有一些,但过于琐碎——其实主要是我写不动了,就不写了。
为了低成本高效率的提高代码质量,基于公司实际情况,定制化开发了一个 webpack 脚手架,解决了以下问题:
我使用的脚手架,是自己基于 webpack5 配置的 vue 脚手架,包含各种各样的配置。
考虑到项目的页面里,有大量的表单内容。为了方便开发测试联调,避免每次都需要手动输入很多表单,因此集成了专门的调试控制台。通过特殊操作打开调试控制台后,页面上会出现一个小浮窗,浮窗上有一些预置按钮,点击可以执行一些预定行为(比如填写表单)。
如下图,点击 test 按钮,表单将被自动填满:
通过集成调试控制台,有以下好处:
针对公司实际业务需要——以工作台为核心平台,其他页面接入,并且后端是微服务设计。故设计思路为多工程多页面主从管理。具体来说,有以下几点:
通过这样的设计,将传统大型前端工程,拆分为类似后端微服务的微前端工程,提高开发效率,特别是并行开发效率。也增强了权限管理,确保了代码的安全性。
具体设计结构如下图:
他们之间的交互流程如下图
无论背后如何跳转,但因为是通过 nginx 转发的,所以表面上,用户访问的都是同一个网址,不影响用户认知。
这里的权限控制,主要是指代码权限控制,目的是确保代码安全,问题可控可避免可追溯。
具体管理举措有以下几条:
在去年十月十一月份时,前后端开发联调有一个严重问题,就是后端接口变动时,不会在事前事后通知相应前端开发、测试人员。开发效率非常低,并且会出现各种异常情况。
因此,通过梳理开发流程,强制要求后端提供接口文档前置,并且要求有一个可控稳定的接口文档,作为对接标准。
在十二月以后,因为接口临时变动带来的 bug 和开发、测试阻塞问题,粗略估计减少了 80%。
但实际情况中,还是会有一些接口文档和实际接口不符的情况发生,导致接口测试被迫重做,接下来需要设法减少此类问题。
工作都是人在做,所以相对来说,把好人员关,有时候比做事更重要。因此为了确保人员的可靠性、稳定性,从以下几个角度入手:
其实还做了一些其他的,但由于篇幅所限,就暂时不写了。(主要是写不动了,这些已经写了一周了啊~~)
目前是把图片打包到工程里,但这种缺点是工程太重,其次是 nginx 服务器压力大。所以未来需要考虑做一个专门的静态资源服务器,上传后,自动传到 cdn,并返回 cdn 上图片链接。然后在页面里直接引入图片链接即可;
这个是我未来核心工作重点。相对于目前的 nginx 渲染 html,更好的选择是 backend 渲染 html。好处有以下几点:
缺点是,需要 backend 层开发配合,可能需要改造代码。
相对于要求开发自己检测代码质量,即使继承了 eslint,效果也不是最好的。因此,最好的办法是将 eslint 集成到 CI/CD 中。在开发提交代码到 gitlab 时,自动执行 eslint 审查代码,如果审查失败,则自动打回;
我们常见问题是无法得知用户操作习惯,以及对报错情况无法捕获。因此,埋点系统是十分有必要的。嵌入埋点系统后,可以从数据层面统计系统的各方面信息,包括访问速度、访问时间段、访问人数、不同岗位人数访问的网页分布情况、
金融系统的安全性是非常重要的,除了常规的 防止 xss 注入之外,也需要防止 CSRF(跨站请求伪造)攻击。解决方法就是上 csrf-token 来避免。
终……
总的来说,前端相关的技术建设,已经做了一些,但未来还有更多需要去建设,特别是使其自动化、GUI 化、便利化、集中化。
例如自建 OA 系统,接入钉钉考勤,接入 gitlab,进行全流程自动化(一键发布、推送到服务器、检查可靠性、通知到相关负责人),线上出问题自动报警通知相关负责人。
而且我们最近 2 个月上了 k8s(本文是在开始之前写的,所以其实也只是截止于 k8s 之前的情况),更多东西,将在下面博客继续说吧(估计起码得鸽子半年)。
未来需要做的工作还很多,前端架构师的施展领域,其实也有很多。