MFE聚合层-网关聚合分析

网关聚合

网关聚合式的微前端方案根据路由将不同业务分发到不同的、独立的前端应用上，通常又称为路由分发式微前端。

实现方式有：

1. nginx反向代理
2. 微服务网关如Zuul或者SpringCloud Gateway
3. K8S Ingress
4. 自建网关，如Nodejs搭建的网关层等

根据团队技术栈和生产环境的不同，不同团队采用方案也有区别，在超大型的SaaS平台中，网关甚至是多级结构。因此，路由分发式的微前端架构是采用最多、实现成本最低的 “微前端” 方案。

与其说是微前端，更像是多个前端应用的聚合，将多个不同应用拼凑在一起。

采用网关聚合的优点有：

• 分散的应用进行了同一聚合
• 避免了前端的跨域问题
• 避免老旧项目的迁移、改造问题
• 升级改造将只会对部分应用造成影响，不再影响整个平台

当然，采用单一的网关聚合也有一些缺点：

• 不同应用间跳转会刷新页面
• 前端状态数据跨应用时无法保存
• 老旧应用需进行一定的平台化改造，如顶部和侧边菜单

运行模式：

1. 首次加载

   根据路径直接通过网关路由到对应子应用，子应用加载后接管路由响应

2. 路由变更

   此时子应用已经接管路由，对于匹配的路由由子应用处理。不匹配路由将通过网关路由到其他子系统或404。子系统前端路由不应该处理404。

3. 刷新页面

   同首次加载逻辑

iframe

​ 在Web平台场景下，一般都有统一的头部菜单或左侧菜单，中间才是各子应用加载的部分。这时，平台的入口就是一个菜单路由分发系统，根据不用的菜单，在iframe中加载不同的子应用。

​ 虽然iframe有众所周知的一些问题，但在网关聚合的场景下，却可以解决需要对老旧应用进行平台化改造的问题，其中的取舍就看各位的了。

​ 有人觉得使用iframe完全可以不使用网关聚合了啊。其实不然，网关聚合还有其他的作用：

• SSO拦截
• 统一鉴权
• 灰度路由等

当然，使用iframe之后需要考虑应用的加载卸载，以及应用间通信和内外路由同步的问题。

总结来说，iframe在用户体验上并不太友好，但作为一个完全独立的环境，有优势也有劣势。从微前端趋势来说并不是一个太好的选择，只是一个方向。

运行模式：

1. 首次加载

   路由响应为菜单容器系统页面=>容器系统加载完成=>容器系统接管前端路由=>由容器系统根据路径在iframe中加载对应子应用

2. 路由变更

   此时会区分是容器系统的路由变更还是子应用的路由变更。如果是容器系统路由变更，将由容器系统负责在iframe中加载新的子应用；如果是子应用自己的路由变更，由于是在iframe的独立运行环境，由子应用自己处理路由。

   这里需要考虑的内外路由同步的问题，如果子应用路由不同步到容器系统的话，刷新页面将丢失子应用路由信息(将会一直是首次加载时的url)。

3. 刷新页面

   同首次加载逻辑。路由是否丢失取决于容器系统和子应用之间是否有路由同步机制。