技术架构

技术架构

根据上述的蜘点大平台架构图，我们对应划分为以下几大块进行详细描述

1. 协同工作

  1. 开发规范

为了低成本高效率的提高代码质量，基于公司实际情况，定制化开发了一个 webpack 脚手架，解决了以下问题：

避免了无限制引入第三方库：无限制引入第三方库，是一种常被忽略，但却很容易带来问题的行为（例如 vue+jquery 等）。因为开发人员通常并不会阅读第三方库的源代码，不能保证其是安全可靠的。而定制脚手架，提供了所有开发中需要的依赖，并严控新依赖的引入，则确保整个工程是安全的。
约束开发人员代码规范：开发最常见问题是代码规范混乱，各写各的，导致维护成本高企。而通过引入 eslint，强行规定代码风格，自动对不符合规范的代码报错，解决了这些问题。并且由于 IDE 支持通过应用 eslint 规则，自动格式化代码。也降低了对开发人员的约束成本，降低推行代码规范的难度。
方便提供给其他开发使用标准的脚手架，并提供技术支持（比如可以统一大前端的技术栈）。

  1. git分支管理、code review
    创建项目时，一般会针对不同的环境，来创建三个常设分支：
    1. develop：开发环境的稳定分支，公开开发环境基于该分支构建；
    2. pre-release：测试环境的稳定分支，测试环境基于该分支构建；
    3. master：生产环境的稳定分支，生产环境基于该分支构建，仅用来发布新版本，除了从pre-release或者生产环境Bug修复分支进行merge，不接受任何其他修改。
      平时开发工作中，会根据需要由开发人员创建两类临时分支：
    4. 功能(feature)分支：为了开发某个特定功能，从develop分支上面分出来的。开发完成后，要merge到develop分支。功能分支的命名，可以采用feature-*的形式命名，比如feature-供货订单-20210302；
    5. Bug修复(fixbug)分支：为了修复某个bug，从常设分支(上述3个分支)上分出来的。修复完成后，再merge到对应分支。Bug修复分支的命名，可以采用fixbug-*的形式命名，比如fixbug-供货订单-20210302;

正常开发流程
1. 从develop分支切出一个新的分支，根据是功能开发还是bug修复，进行命名为feature-*或fixbug-*；
2. 开发者完成开发，提交分支到远程仓库；
3. 开发者发起merge请求(可在gitlab页面发起”New merge request”)，将新分支请求merge到develop分支，并提醒code reviewr进行review;
4. 管理员code reviewer对代码review之后，若无问题，则接手merge请求，新分支merge到develop分支上，同时可删除新建的分支；若存在问题，则不进行merge，可close该请求，同时通知开发者在新分支上进行相应调整，调整完成后提交代码重复review流程；
5. 转测后，直接从当前develop分支merge到pre-release分支，重新构建测试环境完成转测；
6. 测试完成后，从pre-release分支merge到master分支，基于master分支构建生产环境完成上线。并对master分支打tag，tag命名可以为v1.0.0-20210301(即版本号-上线时间)
流程演示示意图如下：

正常开发流程

并行开发测试环境Bug修复流程
并行开发(即前一个版本已经转测但未上线，后一个版本又已在开发中并部分合并到了develop分支)过程中，转测后测试环境发现的bug需要修复，但是develop分支此时又有新的内容且该内容目前不计划转测，可以再pre-release切出一个bug修复分支。完成之后，需要同时merge到pre-release分支与develop分支。merge时参考“正常开发流程”。流程示意图如下：

并行开发测试环境bug修复流程

生产环境Bug修复流程
生产环境的Bug分为两种情况：
1. 紧急Bug：严重影响用户使用的为紧急Bug，需立即进行修复。比如关键业务流程存在问题，影响用户正常的业务行为；
2. 非紧急Bug或优化：非关键业务流程问题，仅影响用户使用体验，或出现频率较小等，为非紧急Bug，可规划到后续版本进行修复【参考正常开发流程】；
紧急Bug修复，需要从master分支中切出一个bug修复分支，完成之后，需要同时merge到master分支与develop分支(如果需要测试介入验证，则可先merge到pre-release分支，验证通过后再merge到master分支上线)。merge时参考“正常开发流程”，流程示意图如下：

生产环境Bug修复流程

  1. npm私服

由于我们通常访问的是内网，因此，需要考虑以后内外网隔离的问题。因此，搭建私有 npm 源，提前从基础设计层面解决问题。
私有源采用开源技术方案verdaccio。优势有以下几点：

  1. 轻量：verdaccio基于 Node.js 开发，占用资源少，运行速度快，配置简便，适合我们公司实际情况；
  2. 配置难度低：可以快速配置用户组、权限、运行端口、存放地址等，足以满足一般场景；
  3. 保证依赖版本稳定：相对于将依赖放到第三方远程源，放本地更稳定，一方面可以提高下载速度（因为部分第三方依赖连外网不稳定），另一方面，可以确保依赖始终存在（被缓存到本地私有 npm 源）；

通过以上三点组合，从架构层面上，解决了发布的线上代码不确定性问题，提高了前端代码的可靠性。
另外，我们前端组会将一些自己封装的 npm 包发布到自己的 npm 源，提供给不同工程使用，避免重复开发带来的研发浪费，以及开发人员能力不稳定带来的公共依赖不可靠的问题。

2. 环境部署

  1. node+k8s+docker部署
  2. nginx配置

3. 日志监控

  1. 错误监控
  2. 数据埋点

4. 项目业务开发

4.1 核心库
  1. Vue2.0全家桶
    考虑到公司和部门的主流技术栈，我们选择的主要前端技术栈是Vue，这也是目前公司这边在多个项目实战中获得的积累，接下来需要针对该技术栈，来选出子技术栈。

为了快速构建项目，我们将会使用蜘点内部的web前端中后台脚手架来快速创建项目，该脚手架集成了Vue全家桶等框架，可进行快速开发中后台前端项目，以下是对应的图例描述该技术栈：

项目技术栈

  1. iViewUI库https://www.iviewui.com/

  2. VueSSR

基于目前大平台上将会使用广告推广的方式，因此需要针对专门的模块进行SSR，由服务器端来渲染，并返回html，让搜索引擎爬虫工具爬取页面上的内容，同时可以加快首屏的呈现速度。

SSR的本质就是服务器端返回渲染好的html文档，我们需要在根项目中启动一服务器，然后返回一个html文档，这里我们使用express作为服务端框架

具体的流程见下方，这里贴上官方的一个渲染流程：

服务端渲染流程

  1. qiankun微前端

qiankun微前端架构

微前端可以解决SPA项目的一些存在的缺点，也可以将原本多个不同的语言实现的SPA拆分为一个个的项目，每个项目即可以单独运行，也可以统一的放到大平台中来运行。

qiankun主应用与子应用架构

  • 主应用：管理各个子应用，即合并结果页面，负责子应用的注册、路由分发。
  • 子应用：各个SPA应用，可以理解为SPA里的页面组件，负责暴露一些函数，对接主应用
4.2 应用层
  1. 蜘点内部脚手架
    通过脚手架，我们可以快速初始化一个项目，无需自己从0开始一步一步配置，提高开发效率，针对不同的子应用提供统一的一套基础项目框架风格，通过脚手架我们可以：
    • 减少重复性的工作，不需要复制其他项目再删除无关代码，或者从零创建一个项目和文件；
    • 可以根据交互动态生成项目目录和配置文件
    • 多人协作更为方便，不需要把文件传来传去
  2. 蜘点组件库
    虽然我们采用的iView作为我们的项目的UI框架，但有时需要针对这个库提供的开源组件进行二次开发，因此需要沉淀团队小组中的项目组件库，供后续其他团队其他项目使用