下载掌阅APP，畅读海量书库
立即打开
毫不夸张地说，路由式微前端方案可以被认为是所有微前端方案中最简单、最容易实现的一种。然而，从本质上来看，路由式微前端并不完全符合微前端方案的定义。它更像是由多个独立项目拼凑而成的集合体，而不是通过精心组合各个部件形成的统一整体。
当然，从广义的角度来看，路由式微前端确实可以被视为一种微前端架构。设想这样一个场景：你的公司有许多最初由外包或第三方团队开发的内部系统。现在，公司决定建立自己的技术团队，并希望将这些分散的项目整合到一个统一的平台。在这种情况下，路由式微前端无疑是最直接、最简便，也是最易于实践微前端理念的解决方案。
正因如此，路由式微前端特别适合整合那些老旧的系统，让它们在外观上呈现出一个统一的整体，同时保持各自的独立性。在此基础上，我们还可以逐步引入最新的项目，享受新技术栈带来的创新乐趣，而不必面对庞大笨重的旧系统而感到无从下手。
路由式微前端在实现上不需要依赖过多复杂的技巧，其核心理念主要是借助HTTP服务器的反向代理功能来完成，这正是我们所熟悉的Nginx所擅长的。至于不同项目间的用户登录状态，可以通过Cookie进行共享。
现在，我们已经熟悉了路由式微前端的应用场景及其特性，接下来，让我们动手实现一个路由式微前端的小型示例。
在搭建一个基础的路由式微前端项目时，我们可以从一个简单的起点出发：在同一个文件夹内创建两个基本的HTML页面。每个页面实际上代表了一个使用脚手架工具生成的单页面应用。这种做法旨在阐明微前端架构的核心思想和功能。鉴于我们的目的是创建一个精简版的微前端范例，我们将重点放在展示其核心逻辑上。项目目录结构如图3-1所示。
图3-1 路由式微前端示例项目的目录结构
index.js的内容实际上是通过express创建一个简单的文件读取和服务器输出页面，核心代码如下：
至此，我们的核心内容基本上已经完成。通过Node.js启动index.js文件，我们就可以在浏览器中通过网址http://localhost:4000/index1和http://localhost:4000/index2来访问页面，如图3-2所示。
图3-2 本地Node服务静态页面的示例
然而，我们所访问的localhost仅仅是一个本地IP地址的别名，并非真实的域名。为了让示例更加贴近实际，我们希望本地服务器能够通过一个“真实”的域名来访问。那么，我们应该如何实现这一目标呢？
首先，需要修改一下自己计算机的hosts文件，把本地的IP映射成想要的域名。笔者在本次示例中所修改的hosts内容如图3-3所示。
图3-3 本地hosts文件的修改内容
这里的意图是将本地的IP地址127.0.0.1映射到自定义的域名www.zakingwong.com。但仅仅这样设置还不够，我们还需要安装Nginx作为反向代理服务器，以便将这个域名指向你在本地运行的服务。
Nginx的安装需要HomeBrew，在Mac计算机上可以这样安装HomeBrew和Nginx：
安装Nginx之后，我们就可以通过修改Nginx的配置文件（也就是ngixn.conf）来配置映射逻辑：
然后，启动Nginx：
# 启动Nginx，需要输入本机密码
sudo nginx
# 重启Nginx
sudo nginx -s reload
# 检查Nginx配置文件语法是否有问题
sudo nginx -t
# 查看Nginx进程是否正在运行
ps aux | grep nginx
# 停止所有运行中的Nginx进程
sudo nginx -s stop
# 强制停止Nginx进程
sudo pkill nginx
完成这些操作后，就可以在浏览器中通过域名查看页面内容，如图3-4所示。
图3-4 通过本地Nginx代理到虚拟域名
至此，整个路由式微前端的实现例子就基本完成了。回顾一下前面所做的事情，其实从本质上来说，这不就是早期前端三大件直接放到服务器上的多页应用的设置吗？没错。这与那个时期前端发布到服务器上的过程及实现没有任何区别。而路由式微前端在切换应用时，实际上就是通过URL来访问服务器上对应的Web应用。当路径发生变化时，浏览器会发起一个GET请求，请求服务器重新加载整个应用所需的所有静态资源。如果变化的是应用内部的前端路由，那么可以通过URL中的hash值在应用内部进行无刷新切换。例如，从www.a.com/a跳转到www.a.com/b，浏览器将触发一个GET请求以从服务器获取新资源。而如果是从www.a.com/a/#/m导航至www.a.com/a/#/n，这只是应用内部URL hash的变化，允许应用在不重新加载页面的情况下自主切换视图。此外，如果你认为hash模式不够美观，采用history模式同样是一个可行的选择。