网页上的微服务—微前端架构实践

做者:郭凌波 恒生LIGHT云社区前端

1、什么是微前端?

“微前端”一词最先于2016年末在《ThoughtWorks Technology Radar》中提出,它将微服务的概念扩展到前端世界,目的是构建一个在微服务架构上功能丰富且强大的前端应用。git

大型组织的组织结构、软件架构在不断地发生变化。移动优先、App中台、中台战略等,各类口号在不断提出和演进。同时业务也在不断地发展,而现有 Web 应用不能很好的拓展和部署,随着时间的推移,各个项目变得愈来愈臃肿,web 应用变得愈来愈难以维护。github

微前端将微服务的理念应用于浏览器端,让Web应用由单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还能够独立运行、开发和部署。web

2、实施微前端的六种方式:

1 路由分发式

路由分发式微前端,即经过路由将不一样的业务分发到不一样独立前端应用上。其一般能够经过反向代理(Nginx/HSIAR)来实现,配合使用应用框架自带的路由管理。后端

就当前而言,经过路由分发式的微前端架构应该是采用最多、最易采用的 “微前端”方案。可是这种方式看上去更像是多个前端应用的聚合,即咱们只是将这些不一样的前端应用拼凑到一块儿,使他们看起来像是一个完整的总体。浏览器

系统总体结构如图:前端框架

1.png

2 iFrame前端容器化

iFrame 做为一个古老而普通的技术,但却一直很管用。采用 <iframe>标签将另外一个Web页嵌入到当前页面中来,使得多web应用能在一个web中打开。服务器

其能够建立一个全新独立的宿主环境,使不一样的前端应用之间能够相互独立运行,但会抛弃网站对SEO的支持、失去页面以前交互的能力。架构

在不少业务场景下,不免会遇到一些难以解决的问题,那么可使用iframe 来做为保底的手段。框架

3 前端微服务化

前端微服务化,是微服务架构在前端的实施。每一个前端应用技术栈、开发、部署、构建都是彻底独立自主运行的,最后经过模块化的方式组合成一个完整的应用。

采用这种方式意味着,一个页面上能够同时存在两个以上的前端应用在运行。

1.png

目前主流的框架有 Single-SPAqiankunMooa,后二者都是基于 Single-SPA 的封装。

4 微应用

微应用化是指在开发时应用都是以单1、微小应用的形式存在的,而在运行时,则是经过构建系统合并这些应用,并组合成一个新的应用。

微应用化大都是以软件工程的方式来完成前端应用的聚合,所以又能够称之为组合式集成。微应用化只能使用惟一的一种前端框架。

1.png

5 微件化

微件化(Widget)是一段能够直接嵌入应用上运行的代码,它由开发人员预先编译好,在加载时不须要再作任何修改或编译。微前端下的微件化是指,每一个业务团第编写本身的业务代码,并将编译好的代码部署到指定的服务器上,运行时只须要加载指定的代码便可。

1.png

6 Web Components

Web Components 是一套不一样的技术,容许开发者建立可重用的定制元素(它们的功能封装在代码以外)而且在您 Web 应用中使用它们。

在真正的项目上使用 Web Components 技术,离如今还有一些距离,结合 Web Components 来构建前端应用,是一种面向将来演进的架构。或者说在将来能够采用这种方式来构建应用。

1.png

微前端几种方式对比

1.png

3、真实的业务场景

在真实的业务场景中,每每是上面提到六种方式中的几种的结合使用,或者是某种方式的变种

假设现有三个内部系统,下面称之为 old-a、old-b 和 C,其中,old-a 和 old-b 是老旧的先后端未分离项目,C 为先后端分离的 SPA 应用(React+HUI),三个系统的架构图大体以下:

1.png

能够看到,old-a 运行在一台服务器 1 上,old-b 运行在服务器 2 上,C 系统的前端资源在服务器 2 上,而且 C 没有本身的域名。

三个系统均在后端同窗维护和开发,他们的需求以下:

一、统一的域名

二、统一的界面和交互

三、系统须要方便拓展

考虑开发同窗的需求和开发成本、维护成本、将来的可拓展性,系统改造关键点以下:

一、申请统一的域名(暂且称之为 crm.mi.com)

二、将 old-a 和old-b 两个老旧的系统样式调整,像系统 C 靠拢

三、三个系统使用统一的菜单和权限

四、三个系统使用统一的 SSO

五、C 系统和正在开发的N个系统使用CI/CD解决打包和手动复制的问题

对于上面几种方式,在具体的实施使用了路由分发、iFrame、应用微服务化、微应用化的融合方式。或者说是某种方案的变种,由于改造以后同时具有了这几种方案的特色。

对于 C 系统和正在开发的N个系统使用 single-spa 作改造,对于老旧的系统 old-a 和 old-b 使用iFrame接入。改造后以下图:1.png

此时,两个老系统分别部署在各自的服务器,C和将来的多个应用部署在同一台服务器。而后在 Nginx 层为老系统分配了两个路由,分别将请求打到各自的服务器,根路由打到C和XX应用的服务器。

使用 React 框架的C和XX应用基于single-spa改造后,那么老系统iFrame 如何接入?

在配置菜单时,老系统路由会被带上标识,统一交给其中一个应用以iFrame 的方式处理:

1.png

改造后微前端架构图:

1.png

4、总结

微前端不是一个框架或者工具,而是一套架构体系。这套体系除了微前端的基础设施外还须要具有微前端配置中心(版本管理、发布策略、动态构建、中心化管理)、微前端观察工具(应用状态可见、可控)等。

整个体系的搭建将是一个庞大的工程,目前大部分团队是在使用微前端的模式和思想来解决现有系统中的痛点。就像咱们的HUI前端框架,经历HUI1时的微应用模式到如今HUI2的微件化模式,结合恒生统一权限管控体系操做员中心和恒生统一网关服务HSIAR,在咱们统一运维监控平台天鉴管理下造成了一套完整的微前端方案,减小了业务部门和客户自研的开发工做。

相关文章
相关标签/搜索