共计 2880 个字符，预计需要花费 8 分钟才能阅读完成。
前端架构概览
思考：咱们有什么，咱们缺什么？
前端架构分为很多局部，在每个不同的我的项目里都会有各自的特点。所以，当咱们想优化一个大型项目的时候，能够从一个概览图来动手剖析，比方下图：
从我本人的我的项目特点来剖析，咱们的基础设施比拟齐备，一些公共的根底服务都能够尝试接入， 唯独业务代码异样凌乱。
起因：因为业务迭代频繁，接手的人多，导致组件标准不好、公共办法没有抽离。而且各个业务之间代码耦合性很强，看似没关联的业务，外部代码之间却相互调用。长此以往，这个我的项目必然难以保护，新的需要迭代只会越做越慢，最初无人违心接手。
那我的切入点就先从这代码构造开始，vuejs 框架既然这么自在，那么咱们就能发明更多的属于本人业务特点的货色。
革新一，面向服务设计
前端如何有服务？
定义
所谓服务，是指软件性能的独立单元，其设计用意是实现特定的工作。其中蕴含了执行残缺、离散的业务性能所需的代码和数据集成，并且能够近程拜访、进行交互或独立更新。
以往痛点
前端的公共代码往往最多放在一个公共目录，甚至有些还扩散在不同业务页面里，一直的被复制、粘贴，导致代码复用率很低。并且没有版本能够追踪批改历史，导致产生潜在的全局影响。
借鉴点
Chrome 团队的面向服务架构设计 (SOA)。
原来的各种模块会被重形成独立的服务（Service），每个服务（Service）都能够在独立的过程中运行，拜访服务（Service）必须应用定义好的接口，通过 IPC 来通信，从而构建一个更内聚、松耦合、易于保护和扩大的零碎，更好实现 Chrome 简略、稳固、高速、平安的指标!
示意图：
结合点
前端的独立模块能够用 npm 包来实现，每个 npm 包负责一个独立的公共性能，自带版本治理和独立更新。package.json 定义进口文件 index.js，其中定义此模块提供的性能接口和代码文件。接口调用通过 export、import 形式实现，能够全局或按需加载。
示意图：
革新二，业务模块化
前端如何有模块？
定义
模块化是指解决一个简单问题时自顶向下逐层把零碎划分成若干模块的过程。每个模块实现一个特定的子性能，所有的模块按某种形式组装起来，成为一个整体，实现整个零碎所要求的性能。
以往痛点
前端的业务代码很容易造成低内聚、高耦合的交叉模式，难以保护，可读性差。加上 vuejs 选项式开发导致逻辑关注点的碎片化，以及 mixin 导致的办法名、变量名在子组件中的混同。随着我的项目规模变大，几年之后就会呈现难以保护，无人敢碰，只能重构的场面。
借鉴点
Symfony 的 bundle 零碎（一套可复用的 PHP 组件）。
bundle 相似于其他软件中的插件，但却更好。要害区别在于：Symfony 中的每一样货色都是 bundle，包含框架外围性能，以及你编写的程序代码。bundle 是 Symfony 体系中的一等公民。一个 bundle，就是一组结构化的文件，存于一个“用于实现某个独立性能”的目录中。每个目录都蕴含着关乎那个性能的所有货色，包含 php 文件，模板，css，js 文件，tests，以及其余。
示意图：
结合点
基于 vue 的 multi-page 模式，每个 page 是一个齐全独立的业务模块（App），独立编译部署。每个业务模块中再细分子业务模块 subApp，每个 subApp 自带 vuejs 框架的 store、router、mixins 等关乎这个业务的所有货色。 编译时将 subApp 等子模块组装到一起，从而实现一个独立的业务性能。 这样就能实现业务代码的解耦，让各个子模块性能更内聚，更易于保护和扩大。
示意图：
subApps 的聚合和相互调用
// index.js，subApp 的进口文件
import {HcSubApp} from 'hc-micro-pages';
import store from './store';
import routes from './routes';
import {jump2IsvPage, jump2CreateCard} from './libs/utils';
const subApp = new HcSubApp();
subApp.store = store; // vuex 数据注册
subApp.routes = routes; // vue router 路由注册
subApp.routePrefix = 'inquiry'; // 命名空间隔离
subApp.storeModule = 'inquiry'; // 命名空间隔离
// 输入 subApp 对象，供交融应用
export default subApp;
// 输入对外接口，供其余 subApp 调用
export {jump2IsvPage, jump2CreateCard};革新三，多包管理模式
为什么还波及到多包？公共服务包 + 业务模块 =？
新问题
npm 包的模式并不适宜批改频繁的我的项目，总要公布新版本，会升高开发效率。而且包的代码还要和业务代码拆散，同时操作两个我的项目去写同一个业务感觉很决裂，也不利于调试。同时业务模块也短少一个模块该有的个性： 版本、批改历史、发版的 tag。这样对灰度公布、版本回滚、问题追溯都不敌对。
借鉴点
lerna，名字来源于希腊神话九头蛇海德拉（Lernaean Hydra）。形象的阐明它是一个用来治理多包我的项目的工具（monorepos），多包指的是一个我的项目内蕴含多个 git、npm 包。曾经采纳 lerna 治理的库有很多，比方：Babel、React、Jest、Taro 等。
结合点
将服务包和业务模块合并成一个我的项目，服务包放到 packages 目录，业务模块放到 pages 目录，每个子目录都初始化成 npm 包模式，用于版本治理。
并且搭配 yarn 的 workspace 个性，每个包、模块都有本人的版本依赖。
当用 lerna 初始化我的项目时，它会将对每个包、模块的援用改成软链接的模式（如果没有指定版本；或者指定的版本与本地包的版本统一也会造成软连贯），这样每次批改都会对其余包实时失效，大大提高开发、调试效率。一旦开发、调试实现，就能够指定具体的包版本并且公布到 npm 源，以保障代码稳固。
而且打包部署时，能够对每个包、模块依据版本打一个 tag（例如：hc-utils@1.0.1），并生成 changelog 文件，不便代码回滚和追溯问题。
最终后果及将来
将来的拓展在哪里？
最终成果，逻辑图：
毛病
包的权限问题
因为是 monorepos 我的项目，意味着你能够批改所有代码，在理论开发中就会带来一些麻烦。比方某些成员不小心批改了其余包的代码，而咱们对这些批改可能检测不到。
好在咱们在发版时会对所有包在 master 分支上进行打 tag，如果发现以后 MR 的需要并不波及某些改变的包，那咱们能够 lerna diff 一下，看看是不是错误代码。
瞻望
subApp 子模块不应该仅仅局限于子页面领域，它就像页面的积木，应该提供更多的能力，只不过基于以后的业务特点，首要解决了页面多而杂的问题。
其余的可能性就是提供逻辑性能的能力，比方用户登录模块（监听 token 过期主动拦挡路由跳转）。还有页面部分功能块的能力，比方广告位（依据地位 id，申请数据后主动渲染）。
