10.1 路由分发:
在一个单体前端、单体后端应用中，典型的特征即是路由是有框架来分发的，框架将路由指定到对应的组件或者内部中，微服务在这个过程做的事情是，将调用变成更细粒度的应用间组件调用，即原先我们只是将路由分发到应用的组件执行，现在则需要根据路由来找到对应的应用，再由应用分发到对应的组件上。 基于Nginx分发路由是最常见的微前端方案，看似是个前端应用的整合，即我们只是将这些不同的前端应用拼凑在一起，但是不是，用户每次a到b应用，都 会刷新界面
微前端路由分发测试 微前端路由分发测试主要分为：
- 单元测试： 验证生成的跳转URL是否符合我们创建的规则
- 集成测试：验证生成的url, 以及其最后（重定向）的地址是否符合要求
10.2 遗留系统微前端：使用iframe作为容器:
我们实现一个平台级应用时，会在系统集成第三方系统，典型的场景将传统的desktop 应用迁移到 web应用
采用iframe时我们需要做：
- 设计管理应用机制
- 设计应用通信机制
10.3 前端微服务化:
前端微服务化是指，在不同的框架之上设计通信、加载机制，以在一个页面内加载对应的应用，我们希望的前端微服务化是:
- 应用可以自动加载，运行，并能够与应用注册表联系
- 每个应用的开发时是完全隔离的，开发时互不影响，他可以介入某个框架，以更好的支持构建
有的项目知道了应用数量，可以使用配置文件来管理，有的不清楚数量是多少，则使用社区常用的single-spa微前端方案进行管理： 应用的挂载dom节点，应用的服务地址，应用的唯一标识符，应用的名称，应用所需要加载的脚本文件
从相关的前端微服务的服务化方案来看分为：
通用性的微前端设计方案：可以适配不同的前端框架，更适合迁移型的微前端项目 定制型的微前端设计方案：只适配一种前端框架，适合于从头开发的微前端项目
这两种方式，都是采用基座化的方式以来加载其他应用，基座化方式你可以支持加载各种不同的框架，以及基座绑定工程上绑定的业务逻辑，我们可以将基座分为：
- 瘦基座：只包含微前端方案的相关框架代码，而核心业务则是由基座加载过来
- 胖基座：前端方案相关的代码与业务逻辑包含在同一个代码库中
10.4 基座控制系统
其整体的工作流程如下所示:
(1)主工程在运行的时候，会去服务器获取最新的应用配置。 (2)主工程在获取配置后，将逐一创建应用，并为应用绑定生命周期。 (3)当主工程监测到路由变化的时候，将寻找是否有对应的路由匹配到应用。 (4)当匹配到对应的应用时，则加载相应的应用。
对于常规的项目而言，基座包含以下功能:
(1)管理其他子应用。
(2)负责应用间的通信。
(3)设计路由的响应机制。
(4)支嵌入常规及iframe模式。
通用性前端微服务化： single-spa 加深了解基座应用的配置以及单应有的加载处理逻辑
web components 使用这两种方式结合 web component来构建微前端应用 在web component 构建独立于构建的组件，并在对应的框架引入这些组件 在web component 引入现有的框架，类似于iframe形式
