实施微前端的六种方式，值得你看!
微前端架构是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。
10多年的都匀网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。营销型网站建设的优势是能够根据用户设备显示端的尺寸不同，自动调整都匀建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。成都创新互联从事“都匀网站设计”,“都匀网站推广”以来，每个客户项目都认真落实执行。
由此带来的变化是，这些前端应用可以独立运行、独立开发、独立部署。以及，它们应该可以在共享组件的同时进行并行开发——这些组件可以通过 NPM 或者 Git Tag、Git Submodule 来管理。
注意：这里的前端应用指的是前后端分离的单应用页面，在这基础才谈论微前端才有意义。
结合我最近半年在微前端方面的实践和研究来看，微前端架构一般可以由以下几种方式进行：
- 使用 HTTP 服务器的路由来重定向多个应用
- 在不同的框架之上设计通讯、加载机制，诸如 Mooa 和 Single-SPA
- 通过组合多个独立应用、组件来构建一个单体应用
- iFrame。使用 iFrame 及自定义消息传递机制
- 使用纯 Web Components 构建应用
- 结合 Web Components 构建
不同的方式适用于不同的使用场景，当然也可以组合一起使用。那么，就让我们来一一了解一下，为以后的架构演进做一些技术铺垫。
基础铺垫：应用分发路由 -> 路由分发应用
在一个单体前端、单体后端应用中，有一个典型的特征，即路由是由框架来分发的，框架将路由指定到对应的组件或者内部服务中。微服务在这个过程中做的事情是，将调用由函数调用变成了远程调用，诸如远程 HTTP 调用。而微前端呢，也是类似的，它是将应用内的组件调用变成了更细粒度的应用间组件调用，即原先我们只是将路由分发到应用的组件执行，现在则需要根据路由来找到对应的应用，再由应用分发到对应的组件上。
后端：函数调用 -> 远程调用
在大多数的 CRUD 类型的 Web 应用中，也都存在一些极为相似的模式，即：首页 -> 列表 -> 详情：
- 首页，用于面向用户展示特定的数据或页面。这些数据通常是有限个数的，并且是多种模型的。
- 列表，即数据模型的聚合，其典型特点是某一类数据的集合，可以看到尽可能多的数据概要（如 Google 只返回 100 页），典型见 Google、淘宝、京东的搜索结果页。
- 详情，展示一个数据的尽可能多的内容。
如下是一个 Spring 框架，用于返回首页的示例：
- @RequestMapping(value="/")
- public ModelAndView homePage(){
- return new ModelAndView("/WEB-INF/jsp/index.jsp");
- }
对于某个详情页面来说，它可能是这样的：
- @RequestMapping(value="/detail/{detailId}")
- public ModelAndView detail(HttpServletRequest request, ModelMap model){
- ....
- return new ModelAndView("/WEB-INF/jsp/detail.jsp", "detail", detail);
- }
那么，在微服务的情况下，它则会变成这样子：
- @RequestMapping("/name")
- public String name(){
- String name = restTemplate.getForObject("http://account/name", String.class);
- return Name" + name;
- }
而后端在这个过程中，多了一个服务发现的服务，来管理不同微服务的关系。
前端：组件调用 -> 应用调用
在形式上来说，单体前端框架的路由和单体后端应用，并没有太大的区别：依据不同的路由，来返回不同页面的模板。
- const appRoutes: Routes = [
- { path: 'index', component: IndexComponent },
- { path: 'detail/:id', component: DetailComponent },
- ];
而当我们将之微服务化后，则可能变成应用 A 的路由：
- const appRoutes: Routes = [
- { path: 'index', component: IndexComponent },
- ];
外加之应用 B 的路由：
- const appRoutes: Routes = [
- { path: 'detail/:id', component: DetailComponent },
- ];
而问题的关键就在于：怎么将路由分发到这些不同的应用中去。与此同时，还要负责管理不同的前端应用。
路由分发式微前端
路由分发式微前端，即通过路由将不同的业务分发到不同的、独立前端应用上。其通常可以通过 HTTP 服务器的反向代理来实现，又或者是应用框架自带的路由来解决。
就当前而言，通过路由分发式的微前端架构应该是采用最多、最易采用的 “微前端” 方案。但是这种方式看上去更像是多个前端应用的聚合，即我们只是将这些不同的前端应用拼凑到一起，使他们看起来像是一个完整的整体。但是它们并不是，每次用户从 A 应用到 B 应用的时候，往往需要刷新一下页面。
在几年前的一个项目里，我们当时正在进行遗留系统重写。我们制定了一个迁移计划：
- 首先，使用静态网站生成动态生成首页
- 其次，使用 React 计划栈重构详情页
- ***，替换搜索结果页
整个系统并不是一次性迁移过去，而是一步步往下进行。因此在完成不同的步骤时，我们就需要上线这个功能，于是就需要使用 Nginx 来进行路由分发。
如下是一个基于路由分发的 Nginx 配置示例：
- http {
- server {
- listen 80;
- server_name www.phodal.com;
- location /api/ {
- proxy_pass http://http://172.31.25.15:8000/api;
- }
- location /web/admin {
- proxy_pass http://172.31.25.29/web/admin;
- }
- location /web/notifications {
- proxy_pass http://172.31.25.27/web/notifications;
- }
- location / {
- proxy_pass /;
- }
- }
- }
在这个示例里，不同的页面的请求被分发到不同的服务器上。
随后，我们在别的项目上也使用了类似的方式，其主要原因是：跨团队的协作。当团队达到一定规模的时候，我们不得不面对这个问题。除此，还有 Angluar 跳崖式升级的问题。于是，在这种情况下，用户前台使用 Angular 重写，后台继续使用 Angular.js 等保持再有的技术栈。在不同的场景下，都有一些相似的技术决策。
因此在这种情况下，它适用于以下场景：
- 不同技术栈之间差异比较大，难以兼容、迁移、改造
- 项目不想花费大量的时间在这个系统的改造上
- 现有的系统在未来将会被取代
- 系统功能已经很完善，基本不会有新需求
而在满足上面场景的情况下，如果为了更好的用户体验，还可以采用 iframe 的方式来解决。
使用 iFrame 创建容器
iFrame 作为一个非常古老的，人人都觉得普通的技术，却一直很管用。
HTML 内联框架元素