前端微服务化：拆分大型 Angular 应用的四种策略
上一个月，我们花了大量的时间不熂设计方案来拆分一个大型的 Angular 应用。从使用 Angular 的 Lazyload 到前端微服务化，进行了一系列的讨论。最后，我们终于有了结果，采用的是 Lazyload 变体：构建时集成代码 的方式。
过去的几周里，作为一个 “专业” 的咨询师，一直忙于在为客户设计一个 Angular 拆分的服务化方案。主要是为了达成以下的设计目标：
简单地来说，就是要支持应用插件化开发，以及多团队并行开发。
应用插件化开发，其所要解决的主要问题是：臃肿的大型应用的拆分问题。大型前端应用，在开发的时候要面临大量的遗留代码、不同业务的代码耦合在一起，在线上的时候还要面临加载速度慢，运行效率低的问题。
最后就落在了两个方案上：路由懒加载及其变体与前端微服务化
前端微服务化：路由懒加载及其变体
路由懒加载，即通过不同的路由来将应用切成不同的代码快，当路由被访问的时候，才加载对应组件。在诸如 Angular、Vue 框架里都可以通过路由 + Webpack 打包的方式来实现。而，不可避免地就会需要一些问题：
难以多团队并行开发，路由拆分就意味着我们仍然是在一个源码库里工作的。也可以尝试拆分成不同的项目，再编译到一起。
每次发布需要重新编译，是的，当我们只是更新一个子模块的代码，我们要重新编译整个应用，再重新发布这个应用。而不能独立地去构建它，再发布它。
统一的 Vendor 版本，统一第三方依赖是一件好事。可问题的关键在于：每当我们添加一个新的依赖，我们可能就需要开会讨论一下。
然而，标准 Route Lazyload 最大的问题就是难以多团队并行开发，这里之所以说的是 “难以” 是因为，还是有办法解决这个问题。在日常的开发中，一个小的团队会一直在一个代码库里开发，而一个大的团队则应该是在不同的代码库里开发。
于是，我们在标准的路由懒加载之上做了一些尝试。
对于一个二三十人规模的团队来说，他们可能在业务上归属于不同的部门，技术上也有一些不一致的规范，如 4 个空格、2 个空格还是使用 Tab 的问题。特别是当它是不同的公司和团队时，他们可能要放弃测试、代码静态检测、代码风格统一等等的一系列问题。
微服务化方案：子应用模式
除了路由懒加载，我们还可以采用子应用模式，即每个应用都是相互独立地。即我们有一个基座工程，当用户点击相应的路由时，我们去加载这个独立 的 Angular 应用；如果是同一个应用下的路由，就不需要重复加载了。而且，这些都可以依赖于浏览器缓存来做。
除了路由懒加载，还可以采用的是类似于 Mooa 的应用嵌入方案。如下是基于 Mooa 框架 + Angular 开发而生成的 HTML 示例：
... Mooa 提供了两种模式，一种是基于 Single-SPA 的实验做的，在同一页面加载、渲染两个 Angular 应用；一种是基于 iFrame 来提供独立的应用容器。
解决了以下的问题：
但是，它仍然包含有以下的问题：
于是在总结了一系列的讨论之后，我们形成了一系列的对比方案：
方案对比
在这个过程中，我们做了大量的方案设计与对比，便想写一篇文章对比一下之前的结果。先看一下图：
表格对比：
详细的介绍如下：
标准 LazyLoad
开发流程：多个团队在同一个代码库里开发，构建时只需要拿这一份代码去部署。
行为：开发、构建、运行一体
适用场景：单一团队，依赖库少、业务单一
LazyLoad 变体 1：构建时集成
开发流程：多个团队在同不同的代码库里开发，在构建时将不同代码库的代码整合到一起，再去构建这个应用。
适用场景：多团队，依赖库少、业务单一
变体-构建时集成：开发分离，构建时集成，运行一体
LazyLoad 变体 2：构建后集成
开发流程：多个团队在同不同的代码库里开发，在构建时将编译成不同的几份代码，运行时会通过懒加载合并到一起。
适用场景：多团队，依赖库少、业务单一
变体-构建后集成：开发分离，构建分离，运行一体
前端微服务化
开发流程：多个团队在同不同的代码库里开发，在构建时将编译成不同的几个应用，运行时通过主工程加载。
适用场景：多团队，依赖库多、业务复杂
前端微服务化：开发、构建、运行分离
总对比
总体的对比如下表所示：
标签：
相关文章
-
无相关信息