大型项目前端架构浅谈 _前端架构

稿件来源：https://juejin.im/post/5cea1f705188250640005472
目录：

1、综合
1.1、使用场景
1.2、核心思想
1.3、切入角度
1.4、其他
2、基础层设计
2.1、自建Gitlab
2.2、版本管理
2.3、自动编译发布Jenkins
2.4、纯前端版本发布
2.5、统一脚手架
2.6、Node中间层
2.7、埋点系统
2.8、监控和报警系统
2.9、安全管理
2.10、Eslint
2.11、灰度发布
2.12、前后端分离
2.13、Mock
2.14、定期备份
3、应用层设计
3.1、多页和单页
3.2、以应用为单位划分前端项目
3.3、基础组件库的建设
3.4、技术栈统一
3.5、浏览器兼容
3.6、内容平_台建设
3.7、权限管理平_台
3.8、登录系统设计（单点登录）
3.9、CDN
3.10、负载均衡
3.11、多端共用一套接口
4、总结

1、综合

文章插图

我在2年之前，写过一篇中小型项目的前端架构浅谈。随着能力的上升，以及在阿里巴巴工作的经验，是时候写一篇大型项目的前端架构分析了。
本篇文章不会更多侧重于具体技术实现，而是尝试从更高角度出发，分析为什么要这么做，这些设计能解决什么问题，成本和收益如何。
由于作者能力有限，可能会有所缺漏或者部分错误，欢迎读者指出。
1.1、适用场景：
本篇文章，适用于单个/多个大型项目、拥有超过10个以上的前端开发的场景。
前端项目的规模不同，成本收益比也会有所差别。通常来说，人员越多、项目复杂度越高，那么收益/成本的比值越大。
对于人数较少、项目简单的开发团队，可能有部分措施不适用，因此应该根据具体情况来选用。
1.2、核心思想：
【1】解决问题：前端架构的设计，应是用于解决已存在或者未来可能发生的技术问题，增加项目的可管理性、稳定性、可扩展性。
【2】人效比：对于需要额外开发工作量的事务（本文中存在一些需要一定开发量的内容），我们在决定是否去做的时候，应该考虑到两个要素：第一个是花费的人力成本，第二个是未来可能节约的时间和金钱、避免的项目风险与资损、提高对业务的支撑能力以带来在业务上可衡量的更高的价值、以及其他价值。
【3】定性和定量：架构里设计的内容，一定要有是可衡量的意义的，最好是可以定量的——即可以衡量带来的收益或减少的成本，至少是可以定性的——即虽然无法用数字阐述收益，但我们可以明确这个是有意义的，例如增加安全性降低风险。
【4】数据敏感：专门写这一条强调数据作为依据的重要性。当我们需要说服其他部门/上级管理者，以推动我们设计的内容时，只有数据——特别是跟钱有关的数据，才是最有说服力的证明。
由于篇幅所限，本文很难直接给出定量的值，因此建议架构设计者，先确保项目中设计使用2.7里的埋点系统，根据埋点系统获取的数据，对项目效果进行定量分析，并以此写成PPT和其他部门/上级管理者进行协调。
1.3、切入角度：
分为基础层和应用层。
基础层偏基础设施建设，与业务相关性较低。
应用层更贴近用户，用于解决某一个问题。
部分两个都沾边的，根据经验划分到其中一个。
1.4、其他
【大型项目前端架构浅谈】由于已经谈到架构层级，因此很多内容，并不仅仅只属于前端领域，有很多内容是复合领域（前端、后端、运维、测试），因此需要负责架构的人，技术栈足够全面，对未来发展有足够的前瞻性。
文章的内容结构为：【项目】—>【解决的问题和带来的好处】—>【项目的实际意义】
2、基础层设计
2.1、自建Gitlab
这个是基础的基础了。本不应该提的，不过考虑到我最近面试的几家公司，有的公司（人数并不少）并没有使用Gitlab，因此专门提一下，并且使用这个的难度非常低。
强烈建议使用Gitlab进行版本管理，自建Gitlab难度并不大，方便管理，包括代码管理、权限管理、提交日志查询，以及联动一些第三方插件。
意义：
公司代码是公司的重要资产，使用自建Gitlab可以有效保护公司资产。
2.2、版本管理
版本管理的几个关键点：