大型项目前端架构浅谈

update：2019.06.17更新2.4文章连接css

目录：html

一、综合
1.一、使用场景
1.二、核心思想
1.三、切入角度
1.四、其余
二、基础层设计
2.一、自建Gitlab
2.二、版本管理
2.三、自动编译发布Jenkins
2.四、纯前端版本发布
2.五、统一脚手架
2.六、Node中间层
2.七、埋点系统
2.八、监控和报警系统
2.九、安全管理
2.十、Eslint
2.十一、灰度发布
2.十二、先后端分离
2.1三、Mock
2.1四、按期备份
三、应用层设计
3.一、多页和单页
3.二、以应用为单位划分前端项目
3.三、基础组件库的建设
3.四、技术栈统一
3.五、浏览器兼容
3.六、内容平_台建设
3.七、权限管理平_台
3.八、登陆系统设计（单点登陆）
3.九、CDN
3.十、负载均衡
3.十一、多端共用一套接口
四、总结

一、综合

我在2年以前，写过一篇中小型项目的前端架构浅谈。随着能力的上升，以及在阿里巴巴工做的经验，是时候写一篇大型项目的前端架构分析了。前端

本篇文章不会更多侧重于具体技术实现，而是尝试从更高角度出发，分析为何要这么作，这些设计能解决什么问题，成本和收益如何。vue

因为做者能力有限，可能会有所缺漏或者部分错误，欢迎读者指出。react

1.一、适用场景：

本篇文章，适用于单个/多个大型项目、拥有超过10个以上的前端开发的场景。git

前端项目的规模不一样，成本收益比也会有所差异。一般来讲，人员越多、项目复杂度越高，那么收益/成本的比值越大。web

对于人数较少、项目简单的开发团队，可能有部分措施不适用，所以应该根据具体状况来选用。面试

1.二、核心思想：

【1】解决问题：前端架构的设计，应是用于解决已存在或者将来可能发生的技术问题，增长项目的可管理性、稳定性、可扩展性。ajax

【2】人效比：对于须要额外开发工做量的事务（本文中存在一些须要必定开发量的内容），咱们在决定是否去作的时候，应该考虑到两个要素：第一个是花费的人力成本，第二个是将来可能节约的时间和金钱、避免的项目风险与资损、提升对业务的支撑能力以带来在业务上可衡量的更高的价值、以及其余价值。chrome

【3】定性和定量：架构里设计的内容，必定要有是可衡量的意义的，最好是能够定量的——便可以衡量带来的收益或减小的成本，至少是能够定性的——即虽然没法用数字阐述收益，但咱们能够明确这个是有意义的，例如增长安全性下降风险。

【4】数据敏感：专门写这一条强调数据做为依据的重要性。当咱们须要说服其余部门/上级管理者，以推进咱们设计的内容时，只有数据——特别是跟钱有关的数据，才是最有说服力的证实。

因为篇幅所限，本文很难直接给出定量的值，所以建议架构设计者，先确保项目中设计使用2.7里的埋点系统，根据埋点系统获取的数据，对项目效果进行定量分析，并以此写成PPT和其余部门/上级管理者进行协调。

1.三、切入角度：

分为基础层和应用层。

基础层偏基础设施建设，与业务相关性较低。

应用层更贴近用户，用于解决某一个问题。

部分两个都沾边的，根据经验划分到其中一个。

1.四、其余

因为已经谈到架构层级，所以不少内容，并不只仅只属于前端领域，有不少内容是复合领域（前端、后端、运维、测试），所以须要负责架构的人，技术栈足够全面，对将来发展有足够的前瞻性。

文章的内容结构为：【项目】—>【解决的问题和带来的好处】—>【项目的实际意义】

二、基础层设计

2.一、自建Gitlab

这个是基础的基础了。本不该该提的，不过考虑到我最近面试的几家公司，有的公司（人数并很多）并无使用Gitlab，所以专门提一下，而且使用这个的难度很是低。

强烈建议使用Gitlab进行版本管理，自建Gitlab难度并不大，方便管理，包括代码管理、权限管理、提交日志查询，以及联动一些第三方插件。

意义：

公司代码是公司的重要资产，使用自建Gitlab能够有效保护公司资产。

2.二、版本管理

版本管理的几个关键点：

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

意义：

提升项目的可控性。

2.三、自动编译发布Jenkins

这个工具用于在代码发布后，执行一系列流程，例如自动编译打包合并，而后再从Gitlab发布到CDN或者静态资源服务器。

使用这个工具，可让通常研发人员不关心代码传到Gitlab后会发生什么事情，只须要专心于开发就能够了。

意义：

让研发人员专心于研发，和环境、运维等事情脱钩。

2.四、纯前端版本发布

纯前端版本发布分为两步：

前端发布到生产环境——此时能够经过外网连接加正确的版本号访问到新版本的代码，但页面上的资源仍是旧版本；
前端经过配置工具（或者是直接更新html文件），将html中引入的资源，改成新版本。

解决的问题是：当前端须要发布新版本时，能够不依赖于后端（根据实际状况，也能够不依赖于运维）。毕竟有不少需求并不须要后端介入，单纯改个前端版本后就要后端发布一次，显然是一件很是麻烦的事情。

这个须要专门的工具，用于配置版本发布，我最近就在写这个。

意义：

提升发布效率，下降发布带来的人员时间损耗（这些都是钱），也能够在前端版本回滚的时候，速度更快。

文章连接：

juejin.cn/post/684490…

2.五、统一脚手架

适用场景：有比较多独立中小项目。好处：

能够减小开发人员配置脚手架带来的时间损耗（特殊功能能够fork脚手架后再自行定制）；
统一项目结构，方便管理，也下降项目交接时带来的须要熟悉项目的时间；
方便统一技术栈，能够预先引入固定的组件库；

意义：

提升开发人员在多个项目之间的快速切换能力，提升项目可维护性，统一公司技术栈，避免由于环境不一样致使奇怪的问题。

2.六、Node中间层

适用场景：须要SEO且前端使用React、vue，或前端介入后端逻辑，直接读取后端服务或者数据库的状况。

SEO：仁者见仁智者见智，虽然不少公司已经不作了，但一般认为，仍是有必定意义的（特别是须要搜索引擎引流的时候），所以React或者Vue的同构是必须的。而且同构还能够下降首页白屏时间；
前端读取后端服务/数据库：好处是提升前端的开发效率和对业务的支持能力，缺点是可能致使P0级故障。

意义：

让前端能够侵入后端领域，质的提高对业务的支持能力。

2.七、埋点系统

强烈推荐前端作本身的埋点系统。这个不一样于后端的日志系统。

前端埋点系统的好处：

记录每一个页面的访问量（日周月年的UV、PV）；
记录每一个功能的使用量；
捕捉报错状况；
图表化显示，方便给其余部门展现；

埋点系统是前端高度介入业务，把握业务发展状况的一把利剑，经过这个系统，咱们能够比后端更深入的把握用户的习惯，以及给产品经理、运营等人员提供准确的数据依据。当有了数据后，前端人员就能够针对性的优化功能、布局、页面交互逻辑、用户使用流程。

埋点系统应和业务解耦，开发人员使用时注册，而后在项目中引入。而后在埋点系统里查看相关数据（例如以小时、日、周、月、年为周期查看）[原创水印-做者：零零水(王冬)，微信：qq20004604]。

意义：

数据是money，数据是公司的生命线，数据是最好的武器。

2.八、监控和报警系统

监控和报警系统应基于埋点系统而创建，在如如下场景时[原创水印-做者：零零水(王冬)，微信：qq20004604]触发：

当访问量有比较大的变化（好比日PV/UV只有以前20%如下）时，自动触发报警，发送邮件到相关人员邮箱；
好比报错量大幅度上升（好比200%或更高），则触发报警；
当一段时间内没有任何访问量（不符合以前的状况），则触发报警；
每过一段时间，自动汇总访问者/报错触发者的相关信息（例如系统、浏览器版本等）；

建设这个系统的好处在于，提早发现一些不容易发现的bug（须要埋点作的比较扎实）。有一些线上bug，由于用户环境特殊，致使没法被开发人员和测试人员发现。但其中一部分bug又由于不涉及资金，并不会致使资损（所以也不会被后端的监控系统所发现），这样的bug很是容易影响项目里某个链路的正常使用。

意义：

提升项目的稳定性，提升对业务的把控能力。下降bug数，下降资损的可能性，提早发现某些功能的bug（在工单到来以前）。

2.九、安全管理

前端的安全管理，一般要依赖于后端，至于只跟单纯有关系的例如dom.innerHTML= 'xxx '这种太基础，就不提了。

安全管理的很难从架构设计上彻底避免，但仍是有必定解决方案的，常见安全问题以下：

XSS注入：对用户输入的内容，须要转码（大部分时候要server端来处理，偶尔也须要前端处理），禁止使用eval函数；
https：这个显然是必须的，好处很是多；
CSRF：要求server端加入CSRF的处理方法（至少在关键页面加入）；

意义：

减小安全漏洞，避免用户受到损失，避免遭遇恶意攻击，增长系统的稳定性和安全性。

2.十、Eslint

Eslint的好处不少，强烈推荐使用：

下降低级bug（例如拼写问题）出现的几率；
增长代码的可维护性，可阅读性；
硬性统一代码风格，团队协做起来时更轻松；

总的来讲，eslint推荐直接配置到脚手架之中，对咱们提升代码的可维护性的帮助会很大。能够考虑在上传到gitlab时，硬性要求eslint校验，经过的才容许上传。

意义：

提升代码的可维护性，下降团队协做的成本。

2.十一、灰度发布

灰度发布是大型项目在发布时的常见方法，指在发布版本时，初始状况下，只容许小比例（好比1~5%比例的用户使用），若出现问题时，能够快速回滚使用老版本，适用于主链路和访问量极大的页面。

好处有如下几点：

生产环境比开发环境复杂，灰度发布时能够在生产环境小范围尝试观察新版本是否能够正常运行，即便出问题，也能够控制损失。
对于大版本更新，能够先灰度一部分，观察埋点效果和用户反馈（即所谓的抢先试用版）。假如效果并很差，那么回滚到老版本也能够及时止损；
当咱们须要验证某些想法或问题的时候，能够先灰度一部分，快速验证效果如何，而后查漏补缺或者针对性优化；

灰度发布一般分为多个阶段：【1】1%；【2】5~~10%；【3】30~~50%；【4】全量推送（100%）。灰度发布必定要容许配置某些IP/帐号访问时，能够直接访问到灰度版本。

意义：

下降风险，提升发布灵活度。

2.十二、先后端分离

这个并非指常见的先后端分离，而是指在分配先后端管控的领域。

中小项目常见的状况是后端只提供接口和让某个url指向某个html，前端负责html、css、js等静态资源。

但大型项目并不建议这么作，建议前端负责除html之外的静态资源，而html交给后端处理，理由有不少：

后端进行渲染，方便统一插入一些代码和资源，例如埋点js，监控js，国际化文本资源，页面标识符等。这些一般是后端经过调用某些服务直接写入的；
当页面须要统一的头尾时（参考淘宝里个人淘宝页面），前端不该该关注这些跟当前页面无关的东西；
某些东西，若是经过html来管理，那么耦合度过高了，违背了解耦和分离的原则；
前端版本发布在后端引入某种功能模块后，能够从单独的页面控制前端发布内容，比更新html更方便，也利于灰度发布；

意义：

更规范的进行页面管理，下降页面和功能的耦合度，减小复杂页面的环境配置时间。

2.1三、Mock

Mock也是常见前端系统之一，用于解决在后端接口未好时，生成返回的数据。

我我的不太建议开发一个专门的系统来Mock，更好的Mock手法是直接嵌入到脚手架之中。思路以下：

当在开发环境下，访问连接一般是localhost:8000/index.html，此时加入后缀 ?debug=true；
封装好的异步请求在发现当前连接有以上标志时，认为是测试环境，访问/userinfo 时，不去读取线上的数据（由于也读取不到），去本地环境读取 src/test_ajax/userinfo.json，并将内容返回给用户；
异步请求正常拿到数据，在页面中显示[原创水印-做者：零零水(王冬)，微信：qq20004604]；
当线上接口能够获取到数据后，从network里找到返回的数据，放入/ src/test_ajax/userinfo.json中，此时再次本地调试的话，至关于使用的是线上的真实数据。
```
</li>
复制代码
```

这种处理，能够下降mock的复杂度，随时更改mock时返回的数据，比单独开发一个mock系统性价比更高。

意义：

在先后端并行开发时，下降沟通交流成本，方便开发完毕后直接对接。

2.1四、按期备份

备份是常被忽略的一件事情，但当咱们碰见毁灭性场景时，缺乏备份带来的损失是很是大的，常见场景：

服务器损坏，致使存在该服务器上的内容所有完蛋；
触发某致命bug或者错误操做（例如rm -f），致使文件和数据所有消失；
数据库出现错误操做或出现问题，致使用户数据、公司资产遭受严重损失；

总的来讲，没人想碰见这样的场景，但咱们必须考虑这种极端状况的发生，所以须要从架构层面解决这个问题。常见方法是按期备份、多机备份、容灾系统建设等。

意义：

避免在遭遇极端场景时，给公司带来不可估量的损失。

三、应用层设计

3.一、多页和单页

除了特殊场景，一般推荐使用多页架构。理由以下：

多页项目，页面和页面之间是独立的，不存在交互，所以当一个页面须要单独重构时，不会影响其余页面，对于有长期历史的项目来讲，可维护性、可重构性要高不少；
多页项目的缺点是不一样页面切换时，会有一个白屏时间，但一般来讲，这个时间并不长，大部分现有大公司的线上网页，都是这样的，所以认为是能够接受的；
多页项目能够单次只更新一个页面的版本，而单页项目若是其中一个功能模块要更新（特别是公共组件更新），很容易让全部页面都须要更新版本；
多页项目的版本控制更简单，若是须要页面拆分，调整部分页面的使用流程，难度也会更低；
灰度发布更友好；

以前面试的一家，采用了单页的形式，以前由于种种缘由，同时采用了ng和react。因为项目历史也比较久（3年以上），结果致使目前继续维护更新的难度很大，即便想部分重构，也很麻烦。

意义：

下降长期项目迭代维护的难度，

3.二、以应用为单位划分前端项目

在项目比较大的时候，将全部页面的前端文件放入到同一个代码仓库里，我以前参与过一家企业的前端项目开发，发现其就是这么作的。根据使用经验来看[原创水印-做者：零零水(王冬)，微信：qq20004604]，存在不少问题：

会极大的增长代码的维护难度；
项目会变得很丑陋；
不方便权限管理，容易形成页面误更改或代码泄密；
任何人都有权利改任何他能看到的页面（在合并代码的时候，管理人员并不能肯定他本次修改的页面是不是需求里他应该改的页面）；
发布成本高，即便改一个页面，也须要发布全部资源；

所以，咱们应该避免这种现象的发生，我的推荐以应用为单位进行开发、发布。所谓应用即指一个业务涉及到的先后端代码，好处不少：

方便进行管理，当某个业务有需求变动时，能够只给研发人员该业务前端应用的developer权限；
在须要发布某业务时，只须要发布该业务的所属应用便可；

意义：

规范项目，增长代码的安全性，下降项目维护成本。

3.三、基础组件库的建设

这个蛮基础的，对于组件库的建设，不建议研发人员较少时去作这件事情，专职前端开发人数少于10人时，建议使用比较靠谱的第三方UI库，例如Antd，这样性价比更高。

设计基础组件库的前提，是要求统一技术栈，这样才能最大化基础组件库的效益。组件库建议以使用如下参考标准：

使用ts；
可扩展性强；
适用程度高；
文档清楚详细；
版本隔离，小版本优化加功能，大改须要大版本更新；
和UI协调统一，要求UI交互参与进来；

总的来讲，建设起来后，利大于弊，可是须要专人维护，所以仍是有必定成本的。

意义：

统一不一样/相同产品线之间的风格，给用户更好的体验，减小单次开发中写UI组件时浪费的时间和人力，提升开发效率。

3.四、技术栈统一

前端有三大主流框架，还有兼容性最强jQuery，以及各类第三方库，UI框架。所以项目需求若是复杂一些，很容易造成一个大杂烩。所以前端的技术栈必须统一，具体来讲，建议实现如下举措：

三大框架选型其一，团队水平通常推荐Vue、水平较好推荐React，对外项目选React或者ng；
须要兼容IE8或更老版本时，建议使用jQuery；
组件库自建或者统一选择一个固定的第三方；
一些特殊第三方库统一使用一个版本，例如须要使用地图时，固定使用高德或百度或腾讯地图；
基础设施建设应避免重复造轮子，全部团队尽可能共用，并有专门的前端平_台负责统一这些东西，对于特殊需求，能够新建，但应当有说服力；

总的来讲，技术栈统一的好处不少，能够有效提升开发效率，下降重复造轮子产生的成本。

意义：

方便招人，简化团队成员培养成本，以及提升项目的可持续性。

3.五、浏览器兼容

常见的问题是IE六、七、8，以及部分小众浏览器（PC和手机）产生的奇怪问题。所以应该考虑统一解决方案，避免bug的重复产生。常看法决方案有：

配置postcss，让某些css增长兼容性前缀；
写一个wepback的loader，处理某些特殊场景；
规范团队代码，使用更稳定的写法（例如移动端避免使用fixed进行布局）；
对常见问题、疑难问题，总结解决方案并团队共享；
建议或引导用户使用高版本浏览器（好比chrome）；

意义：

避免浏览器环境产生的bug，以及排查此类bug所浪费的大量时间。

3.六、内容平_台建设

为了提升公司内部的沟通效率，总结经验，以及保密缘由。应建设一个内部论坛+博客站点。其具有的好处以下：

能够记录公司的历史；
研发同窗之间分享经验；
总结转载一些外界比较精品的文章，提升你们的眼界；
增长公司内部同窗的交流，有利于公司的团队和文化建设；
对某些技术问题能够进行讨论，减小因没有达成共识带来的沟通损耗；

众所周知，大型互联网公司一般都有这样一个内部论坛和博客站点。其下降了公司的沟通和交流成本，也增长了公司的技术积累。

意义：

博客加强技术积累，论坛加强公司内部沟通能力。

3.七、权限管理平_台

当公司内部人员较多时，应有一个专门的平_台，来管理、规范用户的权限以及可访问内容[原创水印-做者：零零水(王冬)，微信：qq20004604]。权限管理平_台有几个特色：

必然和Server端自然高耦合度，所以须要有专门的控制模块负责处理权限问题（负责Server端开发处理，或者前端经过中间层例如Node层介入处理）；
自动化流程控制，即用户建立、申请、审批、离职自动删除，都应该是由系统推动并提醒相关人士，必要时应能触发报警；
权限应有时效性，减小永久性权限的产生；
审批流程应清晰可见，每一阶段流程应具体明确；
应与公司流程紧密结合，而且提升可修改性，方便公司后期进行流程优化；

意义：

使得公司内部流程正规化、信息化。

3.八、登陆系统设计（单点登陆）

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

加强用户体验；
打通了不一样业务系统之间的用户数据；
方便统一管理用户；
有利于引流；
下降开发系统的成本（不须要每一个业务都开发一次登陆系统和用户状态控制）；

总的来讲，大中型web应用，SSO能够带来不少好处，缺点却不多。

意义：

用户体验加强，打通不一样业务之间的间隔，下降开发成本和用户管理成本。

3.九、CDN

前端资源的加载速度是衡量用户体验的重要指标之一。而现实中，由于种种因素，用户在加载页面资源时，会受到不少限制。所以上CDN是很是有意义的，好处以下：

用户来自不一样地区，加入CDN可使用户访问资源时，访问离本身比较近的CDN服务器，下降访问延迟；
下降服务器带宽使用成本；
支持视频、静态资源、大文件、小文件、直播等多种业务场景；
消除跨运营商形成的网络速度较慢的问题；
下降DDOS攻击形成的对网站的影响；

CDN是一种比较成熟的技术，各大云平_台都有提供CDN服务，价格也不贵，所以CDN的性价比很高。

意义：

增长用户访问速度，下降网络延迟，带宽优化，减小服务器负载，加强对攻击的抵抗能力。

3.十、负载均衡

目前来看，负载均衡一般使用Nginx比较多，之前也有使用Apache。当碰见大型项目的时候，负载均衡和分布式几乎是必须的。负载均衡有如下好处：

下降单台server的压力，提升业务承载能力；
方便应对峰值流量，扩容方便（如举办某些活动时）；
加强业务的可用性、扩展性、稳定性；

负载均衡已是蛮常见的技术了，好处不用多说，很容易理解。

意义：

加强业务的可用性、扩展性、稳定性，能够支持更多用户的访问。

3.十一、多端共用一套接口

目前常见场景是一个业务，同时有PC页面和H5页面，因为业务是同样的，所以应避免同一个业务有多套接口分别适用于PC和H5端。[原创の水印-做者：零零水(王冬)，QQ：20004604]所以解决方案以下：

后端提供的接口，应该同时包含PC和H5的数据（即单独对一个存在亢余数据）；
接口应当稳定，即当业务变动时，应尽可能采起追加数据的形式；
只有在单独一端须要特殊业务流程时，设计单端独有接口；

多端共用接口，是减小开发工做量，而且提升业务可维护性的重要解决方案。

意义：

下降开发工做量，加强可维护性。

四、总结

因为各个公司具体状况不一样，项目也具备特殊性，所以以上设计不可强行套入，应根据本身公司规模、项目进展、人员数量等，先添加比较重要的功能和设计。并须要考虑到长期项目的可维护性和发展须要，对部分基础设施进行提早研发设计。

篇幅所限，所以没法面面俱到，只提了一些我认为比较重要的架构层面须要考虑的内容，欢迎你们补充。你们若是有本身的见解，欢迎回复，或者添加个人微信 qq20004604（昵称：零零水）进行讨论。

最后问一下，西安有没有不加班，而且须要前端架构师的公司，请联系我。

大型项目前端架构浅谈（8000字原创）