稿件来源：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、总结
文章插图
我在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、版本管理
版本管理的几个关键点：
