架构

say_it_again
243 阅读11分钟

前端基础架构


目录


  1. 综合部分
    1.1 中心思想
    1.2 切入层面
    1.3 其它
  2. 非业务层面设计
    2.1 前后端分离
    2.2 版本管理
    2.3 流程管理
    2.4 Jenkins
    2.5 前端部署
    2.6 脚手架统一
    2.7 模块级架构
    2.8 http安全
    2.9 静态eslint校验
    2.10 灰度测试
    2.11 埋点
    2.12 备份
  3. 业务层面设计
    3.1 SPA和MPA
    3.2 部署单位
    3.3 组件库的建设与维护
    3.4 兼容问题（pc和移动端）
    3.5 登陆模式

1、综合

前端技能

1.1 中心思想


* 【解决问题】：目的致力于解决已存在或者未来可能发生的技术问题，增加项目的可管理性、稳定性、可扩展性。

  • 【效率比】：对于需要额外开发工作量的事务，我们在决定去做时应该考虑到两个要素：第一个是花费的人力资源成本；第二个是未来可能节约的时间、金钱、项目风险、提高对业务的支撑能力，以此带来在业务上可衡量的更高的价值、以及其他价值。

  • 【量化与定性】：架构里设计的内容，一定要有是可量化的意义的，最好是可以量化出带来的节约的时间、减少风险等；至少是可以定性的，即虽然无法用数字阐述收益，但我们可以明确这个是有意义的，例如增加安全性降低风险。

  • 【数据】：当我们需要说服其他部门/上级管理者，来推动我们开发的内容时，只有数据，才是最有说服力的证明。（特别是和钱相关的数据）


1.1 切入层面


  • 【非业务层面】：非业务层面偏向基础建设，包含规范、打包等；

  • 【业务层面】：使应用更贴近用户，交互体验等，跟进迭代后更加用于解决某已问题


1.3 其它


由于提及架构，因此很多内容，并不仅仅只属于前端领域，有很多内容是包含复合领域（前端、后端、运维、测试）的部分知识。

2、非业务层面设计


2.1 前后端分离


前后端分离指的是在分配前后端管控的领域； 在远古时代提出了两种架构模式，C/S与B/S架构，相关可查阅资料； Browser/Server就是指通过浏览器访问，不用提前安装一个客户端； B/S架构，曾一度被认为是C/S架构的替代者，好处就是无须安装，简单方便，研发速度也快； 在那个时候，JSP，ASP，PHP还被称为三驾马车。 此时浏览器访问的是一个完整的Html网页，而这个网页呢，并不是一个静态的网页，写好在服务器上的，而是应用程序从数据库里取数据生成的，动态网页。这种做法会导致重复数据很多；

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<%! int day = 3; %> 
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<h3>IF...ELSE 实例</h3>
<% if (day == 1 | day == 7) { %>
      <p>今天是周末</p>
<% } else { %>
      <p>今天不是周末</p>
<% } %>
</body> 
</html>

而后便提出了前后端分离模式，前后端分离的提出使后端同学只需要做面向api编程；而缓存、跳转、交互、页面展示等等等等全部交由前端，这也是前端应该致力的方向； 分离后，前端相当于只控制静态资源，所有页面上动态的数据都是通过ajax调用后端api； 而资源文件就可以在浏览器初次加载页面时，就直接将serve端资源下载到客户端，大大减少了重复性资源。

意义：前后端各司其职，前端方面可以将全部精力放在页面交互体验、并发问题、性能优化等方面，将前端项目做到极致。 ####2.2 版本管理

  1. 发布后分支锁死，不可再更改：指当例如0.0.1版本成功发布后，不可再更改0.0.1分支上的代码，否则可能会导致版本管理混乱。
  2. 全自动流程发布；指应避免开发者提交后，手动编译打包等操作，换句话说，开发人员发布后，将自动发布到预发布/生产环境。开发人员不和相关环境直接接触。实现这个可使用自动部署工具，例jenkins。
  3. 多版本并存；指当例如发布0.0.2版本后，0.0.1版本的代码应仍保存在线上（例如CDN），这样当出现线上bug时，方便快速回滚到上一个版本。

意义：方便面对生产/线上的特殊情况，可及时修改/回滚。

2.3 流程管理

2.4 Jenkins

自动化部署工具，可私有化部署； 这个工具用于在代码发布后，执行一系列流程，可自动编译打包合并，然后再从Gitlab发布到CDN或者静态资源服务器。

意义：可以让一般研发人员不用考虑代码上传到git仓库后续的事情，与运维、环境脱离，更专心代码开发。

2.5 前端部署

前端部署分两步：

  1. 前端发布到生产环境：此时可以通过外网链接加正确的版本号访问到新版本的代码，但页面上的资源还是旧版本；
  2. 前端通过配置工具（或者是直接更新html文件），将html中引入的资源，改为新版本。

解决的问题：当前端需要发布新版本时，可以不依赖于后端（根据实际情况，也可以不依赖于运维）。单纯改个前端版本后就要后端发布一次，显然是一件非常麻烦的事情。

意义：开发环境可采取这种措施，正式环境还是要严谨对待。

2.6 脚手架统一

好处：可以减少开发人员配置脚手架带来的时间损耗；

统一项目结构，方便管理，也降低项目交接时带来的需要熟悉项目的时间；

方便统一技术栈，可以预先引入固定的组件库；

意义：在多项目情况中，前端开发小伙伴可以不会存在脚手架差异问题。

2.7 模块级架构

2.8 http安全

前端的安全管理，通常要依赖于后端；

安全管理的很难从架构设计上完全避免，但还是有一定解决方案的，常见安全问题如下：

  1. XSS注入：对用户输入的内容，需要转码（大部分时候要server端来处理，偶尔也需要前端处理），禁止使用eval函数；
  2. https：http加密协议，大大提升安全性；
  3. CSRF：要求server端加入CSRF的处理方法（至少在关键页面加入）；

意义：减少安全漏洞，避免遭遇恶意攻击，增加系统的稳定性和安全性

2.9 静态eslint校验

eslint.org/docs/rules/ eslint官方提供可校验规则 好处： 降低低级bug（例如拼写问题）出现的概率； 增加代码的可维护性，可阅读性； 硬性统一代码风格，团队协作起来时更轻松； eslint推荐直接配置到脚手架之中，对我们提高代码的可维护性的帮助会很大。可以考虑在上传到gitlab时，硬性要求eslint校验，通过的才允许上传。

意义：静态方面进行eslint校验，可防止低级错误打包不通过等多种问题。作为公共资源维护到git仓库

2.10 灰度

灰度发布是大型项目在发布时的常见方法，指在发布版本时，初始情况下，只允许小比例（比如1~5%比例的用户使用），若出现问题时，可以快速回滚使用老版本。

优点

  1. 生产环境比开发环境复杂，灰度发布时可以在生产环境小范围尝试观察新版本是否可以正常运行，即使出问题，也可以控制损失。
  2. 对于大版本更新，可以先灰度一部分，观察埋点效果和用户反馈（也就是所谓的抢先试用版）。假如效果并不好，那么可以回滚到老版本；
  3. 当我们需要验证某些想法或问题的时候，可以先灰度一部分，快速验证效果如何，然后及时调整以及性能优化； 灰度发布通常分为多个阶段：【1】1%；【2】5-10%；【3】30-50%；【4】全量推送（100%）

意义：降低发布风险，大幅度提高发布灵活性

2.11 埋点

前端埋点好处：

  1. 记录单页访问量；
  2. 记录功能使用量；
  3. 捕捉报错情况及频率，并进行数据统计；

通过这个系统，我们可以更深刻的把握用户的习惯，以及给产品经理、运营等人员提供准确的数据依据。当有了数据后，前端人员就可以针对性的优化功能、布局、页面交互逻辑、用户使用流程。 埋点系统应和业务解耦，开发人员使用时注册，然后在项目中引入。

意义：数据就是money，数据也是最可以直观告诉我们问题以及效益

2.12 备份

备份是常被忽略的一件事情，但当我们遇见毁灭性场景时，缺少备份带来的损失是非常大的； 数据库方面服务器损坏，就会导致当前服务器上的内容全部丢失； 错误操作（例如rm -f）以及一些致命bug也会导致文件和数据全部消失； 总的来说，工作多年也从没遇见过这种情况，但我们必须考虑这种极端情况的发生，因此需要从架构层面解决这个问题。常见方法是定期备份、多机备份等。

意义：防止出现极端情况导致数据丢失。

3、业务层面设计

3.1 SPA和MPA

意义：降低长期项目迭代维护的难度，

3.2 部署单位

在项目比较大的时候，将所有页面的前端文件放入到同一个代码仓库里，这样做存在很多问题：

  1. 极大增加代码维护难度;
  2. 代码项目十分丑陋;
  3. 任何人都有权利改任何他能看到的页面（在合并代码的时候，管理人员并不能确定他本次修改的页面是否是需求里他应该改的页面）;
  4. 发布成本高，即使改一个页面，也需要发布所有资源;

因此建议以应用为单位进行部署发布，或以模块化方式进行部署发布；

意义：方便进行管理，当需要更改某需求时，只需要对应更改研发人员该需求对应的权限就好；发布时，也可直接对应应用/模块化进行局部部署。

3.3 组件库的建设与维护

对于组件库的建设，建议使用比较靠谱的第三方UI库，例如Antd，这样时间等成本与效益性价比更高。 需遵循宗旨：

  1. 可扩展性强；
  2. 适用程度高；
  3. 文档描述清晰；
  4. 版本控制（如小版本进行优化及修复，大版本增加功能）
  5. 细节交互等需要UI提供帮助

意义：利大于弊，需要花费时间精力维护，但统一性十分好。

3.4 兼容问题（pc和移动端）

pc: IE6、7、8 移动端：安卓、ios以及小众手机差异性 多数出现2C或医院政府等国有企业项目，若出现需要兼容低版本浏览器项目，则需要在项目初始开始制定前端要求，例css兼容前缀，webpack的loader等；

3.5 登陆模式

SSO单点登陆： 当公司内部业务线比较复杂但相互之间的耦合度比较高时，我们应该考虑设计添加单点登录。具体来说，用户在一处登录，即可以在任何页面访问，登出时，也同样在任何页面都失去登录状态。

  1. 增强用户体验；
  2. 打通了不同业务系统之间的用户数据；
  3. 方便统一管理用户；
  4. 有利于引流；
  5. 降低开发系统的成本（不需要每个业务都开发一次登录系统和用户状态控制）；

意义：用户体验增强，打通不同业务之间的间隔，降低开发成本和用户管理成本。

avatar
文章
阅读
粉丝