【架构拾集】 微前端：微应用化 - Phodal

微应用化即**在开发和运行时**，应用都是以单一、微小应用的形式存在。

微应用化与微前端架构相当的类似，它们在开发时都是独立应用，在构建时又可以 ... Blog search Search spann> HomeBlogCodeLiteratureMore数字技术战略 Blog PHODAL HomeBlogLiterature《自己动手设计物联网》《全栈应用开发：精益实践》《前端架构：从入门到微前端》 【架构拾集】微前端：微应用化 Postedby: PhodalHuang Aug.5,2018,3:34p.m. 【架构拾集】，是我（Phodal）用来记录项目实施过程中的优秀架构集。

微应用化即在开发和运行时，应用都是以单一、微小应用的形式存在。

微应用化与微前端架构相当的类似，它们在开发时都是独立应用，在构建时又可以按照需求单独加载。

如果以微前端的单独开发、单独部署、运行时聚合的基本思想来看，微应用化就是微前端的一种实践。

只是使用微应用化意味着：我们只能使用唯一的一种前端框架。

如果从框架不限的角度来定义，怕是离微前端有些远，不过大团队怕是不会想同时支持多个前端框架。

适用场景 为了方便后期我的查阅，我还是简单地写个相应架构的电梯演进。

关键因素 描述 对于 想拆解单体前端应用的团队 我们的架构 微应用化 是一个 类微前端架构 它可以 在开发环境将应用拆分成一个个的模块化应用，在构建时以单体的形式构建 但他不同于 微前端架构 它的优势是 实施成本低、技术难度小、维护成本低 技术远景 作为项目的技术负责人，我希望项目中的每个功能模块，都可以交由不同的团队独立开发。

方案对比 再次的，让我们和之前的不同方案进行对比： 方式 开发成本 维护成本 可行性 同一框架要求 实现难度 潜在风险 路由分发 低 低 高 否 ★ 这个方案太普通了 iFrame 低 低 高 否 ★ 这个方案太普通了 应用微服务化 高 低 中 否 ★★★★ 针对每个框架做定制及Hook 微件化 高 中 低 是 ★★★★★ 针对构建系统，如webpack进行hack 微应用化 中 中 高 是 ★★★ 统一不同应用的构建规范 纯WebComponents 高 低 高 否 ★★ 新技术，浏览器的兼容问题 结合WebComponents 高 低 高 否 ★★ 新技术，浏览器的兼容问题 微服务化，即每个前端应用一个独立的服务化前端应用，并配套一套统一的应用管理和启动机制，诸如微前端框架Single-SPA或者 mooa 。

微件化，即通过对构建系统的hack，使不同的前端应用可以使用同一套依赖。

它在应用微服务化的基本上，改进了重复加载依赖文件的问题。

架构设计方案 在刚结束的项目里，我们采用了这种架构方式来构建应用，我们将其称之为微应用。

原因主要有两个，一个是每个应用都是以功能模块划分的，一个则是应用最后仍然是以单体应用的形式存在的。

我们的方式就是在开发环境将单体应用拆分成一个个的模块应用，而在构建时是以单体应用的形式构建，而在运行时是以应用模块的形式存在。

状态 开发时 构建时 运行时 应用形式 微小应用 单体 微小模块 值得注意的是，我们能成功实施微应用化的一个关键因素是，前端框架本身是能支持功能模块的Lazyload。

不过，事实上支持Lazyload的另外一个关键因素是：webpack对于chunk的使用。

由于我懒，所以我直接从GitHub上扒一个LazyloadDemo来作为示例。

如下是一个Lazyload的路由示例： exportconstROUTES:Routes=[ {path:'',pathMatch:'full',redirectTo:'dashboard'}, {path:'dashboard',loadChildren:'../dashboard/dashboard.module#DashboardModule'}, {path:'settings',loadChildren:'../settings/settings.module#SettingsModule'}, {path:'reports',loadChildren:'../reports/reports.module#ReportsModule'} ]; 其对应的目标结构如下所示： ├──app │  ├──app.component.ts │  └──app.module.ts ├──dashboard │  ├──dashboard.component.ts │  └──dashboard.module.ts ├──main.ts ├──reports │  ├──reports.component.ts │  └──reports.module.ts └──settings ├──settings.component.ts └──settings.module.ts 上面的代码对应着对应的module。

只需要在使用的时候，Angular构建的时候会将module独立构建成*.chunk.js。

假设现在我们有dashboard、settings、reports三个应用，那么现在的工程里的三个应用都是以空白module形式而存在的。

它可以在其它module还未开发的时候，不影响系统的构建。

那么再加上主的功能，一共会有四个代码仓库： 主代码库。

只包含一个空白的框架式代码，它是一个单独的应用可以独立构建，构建完是带Lazyload的工程。

dashboard、settings、reports三个应用。

它们都是各自独立的应用，在构建时复制对应模块的代码到主工程。

当系统开始构建时，我们会从独立的dashboard应用中拷贝相应的module代码及依赖，拷贝到上述的这个工程里，然后替换。

而这个dashboard应用内，自己又是一个完整的Angular应用，它可以独立地开发运行。

持续集成设计 系统的持续集成的触发机制可以由这几部分集成： 功能模块（featuresmodule)代码更新，会触发对应的模块的持续构建 主的应用代码更新，会触发整个系统的持续构建 功能模块持续集成成功，触发整个系统的持续构建 如上一节中架构设计方案所述，主应用构建的工程中，我只需要复制对应的代码即可。

测试策略 考虑到微前端架构在实施上的一些特殊性，我们有必要在传统的测试金字塔的基础上添加一些额外的测试： 依赖一致检测测试 功能模块生成测试 依赖一致性测试 由于不同的功能模块，需要保持一致的依赖版本。

因此有必要对依赖版本进行测试、对比，以避免在线上依赖并不一致的时候，出现一些意料之外的Bug。

对于前端项目来说，这个依赖管理配置文件就是package.json。

我们只需要从不同的项目中，读取这个文件，然后对比其中的版本即可。

使得每个工程的依赖可以尽可能地保持一致。

功能模块生成测试 由于项目加载模块的方式，是通过前端框架自带的的Lazyload功能来实现的。

理论上，我们就不需要测试lazyload的功能是否正确。

如果需要的话，我们只需要以下三部分其中的一个： 测试复制的模块能复制到对应的目录上 测试生成的模块代码大小是否正常 E2E测试 要对模块是否能正确复制进行测试，最简单的方式是编写脚本，在持续集成的过程中运行测试脚本，如果没有检测到则exit(-1)，持续集成构建失败。

测试模块代码大小是否合理的原因在于，我们可能没有正确的在对应的目测替换功能模块。

如下是一个生成的Lazyload模块示例，正常情况下每个chunk.js文件应该是要大于空白的模块的大小： Date:2018-08-05T06:31:39.188Z Hash:c1e57b16329e1ec9bb5e Time:44397ms chunk{0}0.bb599f286b4bd7a5671c.chunk.js(common)22.7kB[rendered] chunk{1}1.0124f60f4b26e51b6eac.chunk.js()22.9kB[rendered] chunk{2}2.563bd899f2d57f903f05.chunk.js()22.7kB[rendered] chunk{3}main.b812524b18403b7b0cc4.bundle.js(main)1.54MB[initial][rendered] chunk{4}polyfills.3b18b0b8f25d1038155d.bundle.js(polyfills)87kB[initial][rendered] chunk{5}styles.425af9d9b93b3ae95ff2.bundle.css(styles)22kB[initial][rendered] chunk{6}inline.a41bfd7c50df83afde20.bundle.js(inline)2.54kB[entry][rendered] 但是上述这部分的测试，其依赖于在构建的时候测试日志。

同样的需要在持续集成中编写脚本，并exit(-1)。

使用E2E测试对于微前端或者微服务化架构来说，是一种特别有效的方式。

唯一的问题可能是，它运行起来比较慢。

结论 微应用化，又可以称之为组合式集成，即通过软件工程的方式，在开发环境对单体应用进行拆分，在构建环境将应用组合在一起构建成一个应用。

或许您还需要下面的文章: 【架构拾集】基于混合应用架构的跨平台实时聊天应用 2019年（大）前端技术规划 【架构拾集】移动应用的自动化测试（BDD方式） 【架构拾集】简易的Android混合应用框架的插件架构设计 【架构拾集】WebView的JavaScriptBridge设计 "微"害架构 前端下半场：构建跨框架的UI库 React中引入Angular组件 微前端架构选型指南 【架构拾集】前后端分离演进：不能微服务，那就BFF隔离 【架构拾集】：移动应用架构设计 使用adr轻松创建“程序员友好”的轻量级架构决策记录 标签:microappmicrofrontend 关于我 Github:@phodal    微博:@phodal    知乎:@phodal    微信公众号(Phodal) 围观我的GithubIdea墙,也许，你会遇到心仪的项目 QQ技术交流群:321689806 comment Feeds RSS/ Atom 最近文章 组合架构：Arduino浅析 “分布式”开发规范治理 回到单体架构：一个开源项目的重构 遗留系统现代化工具集：Modernizing 数据处理的抽象：数据与知识处理的思考 领域元组件：领域特定的组件集合 2021节点：赶不上变化的计划 前端技术规划与战略：2022 Componentless:面向低代码时代的前端架构设计 Yiki：NanoComponent（草稿） 关于作者 PhodalHuang Developer,Consultant,Writer,Designer ThoughtWorks高级咨询师 工程师/咨询师/作家/设计学徒 开源深度爱好者 出版有《前端架构：从入门到微前端》、《自己动手设计物联网》、《全栈应用开发：精益实践》 联系我:[email protected] 微信公众号:与我沟通 Github:@phodal 微博:@phodal 知乎:@phodal SegmentFault:@phodal 标签 opensuse (10) django (41) arduino (10) thoughtworks (18) centos (9) nginx (18) java (10) SEO (9) iot (47) iotsystem (12) RESTful (23) refactor (17) python (47) mezzanine (15) test (11) design (15) linux (14) tdd (12) ruby (14) github (24) git (10) javascript (52) android (35) jquery (18) rework (13) markdown (10) nodejs (24) google (8) code (8) macos (9) node (11) think (8) beageek (8) underscore (14) ux (8) microservices (10) rethink (9) architecture (26) backbone (19) mustache (9) requirejs (11) CoAP (21) aws (10) dsl (9) ionic (25) Cordova (21) angular (16) react (14) ddd (9) summary (9) growth (10) frontend (14) reactnative (8) serverless (32) rust (8)