下载掌阅APP，畅读海量书库
立即打开
微应用化的核心是把大型应用拆分成一个个微型应用，每个微型应用都可以独立开发、独立部署以及独立运行。其中，最关键的是大型应用的拆分与组合。
我们回想一下之前聊过的三种方案，每一个独立部署于服务器的应用，通过不同URL Path来区分子应用。那么，是否可以认为这也是一种微应用化方案？一个又一个的iframe组合到一起，是不是微应用化？在一个页面放置五六个Web Component，是不是也是一种微应用化？
答案是，不一定。因为微应用在实践中最关注的是把大型应用拆分并独立出去，或者在设计一个大型应用之初，就有一个主应用来聚合这些子应用。我们可以把这些子应用的软件包完全引入主应用中，并把所有父子项目打包成一个整体。注意，这个过程才是真正微应用化的含义。
这让笔者想起了儿时特别喜欢的一种玩具—汽车机器人，大致如图3-9所示。
图3-9 变形组合汽车人
这样的机器人每个部位都可以独立变成一辆车，同时，它们也可以组合在一起，呈现出最终的机器人形态。微应用的目的也是如此。
我们先来设想一下，一个单一的现代前端单页面应用需要什么。
首先，我们需要构建本地环境和生产环境，通常可以通过各种框架的脚手架完成绝大部分工作。
然后，我们需要关注路由和状态管理，如何配置前端路由，是使用hash还是history？应用哪种状态管理方案，或者并行使用多种方案？
最后，我们还需要关注组件化，这里指的仅仅是项目内的组件化。是否需要组件化，取决于你的项目是否足够大。
基于以上的简单思考，实现微应用其实并不复杂。每一个微应用与我们前面描述的内容毫无区别。关键的工作在于如何聚合这些微应用的主应用。
主应用的基础配置往往和其他微应用并没有差别，主应用甚至可以在一定程度上拥有自己的业务代码，一方面保持了自己的业务能力，另一方面还要具备组合其他微应用的能力。
那么，如何组合其他微应用呢？
简单来说，我们可以把微应用的代码全部复制到主应用的对应文件夹下，甚至可以通过Node.js来自动生成路由，并把状态管理的代码按照一定的规则编排，这里可能需要用到一些代码编译的逻辑。
当然，主应用不能照单全收所有的微应用代码，主应用只需要获取必要的部分即可。
这里还有个问题：这样的设计方案是否支持不同框架？一个微应用是Vue，一个微应用是Angular，还有一个微应用是React，这样是否行得通呢？