千千梦丶琪 发表于 2024-8-25 06:04:26

微前端学习笔记(1):微前端总体架构概述,从微服务发微

从最初的CS架构,如MFC Java Swing 等,到BS架构,JSP PHP,再到前端后端分离,前端从jquery  GWT-Ext  到 Handlebars ,再到angularJS/Vue/React,反观java 世界,学好 Spring MyBatis ,一起无忧,哎……

微服务

为了解决巨大的一整块后端服务带来的变动与扩展方面的限定,出现了微服务架构(Microservices):
   微服务是面向服务架构(SOA)的一种变体,把应用程序设计成一系列松耦合的细粒度服务,并通过轻量级的通信协议组织起来
详细地,将应用构建成一组小型服务。这些服务都可以大概独立部署、独立扩展,每个服务都具有稳固的模块边界,乃至允许利用不同的编程语言来编写不同服务,也可以由不同的团队来管理
Micro frontends, An architectural style where independently deliverable frontend applications are composed into a greater whole.
微前端实际是一种思想,个人以为并不是新的黑科技,其关键点照旧解耦与分治。
   微前端是一种类似于微服务的架构,它将微服务的理念应用于浏览器端,即将单页眼前端应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。同时,它们也可以在共享组件的同时举行并行开发——这些组件可以通过 NPM 或者 Git Tag、Git Submodule 来管理。
犹如微服务一样,微前端就是把系统拆解,解耦,然后组合。犹如iphone的供应链管理。
https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=https%3A%2F%2Fwww.zhoulujun.cn%2Fuploadfile%2Fimages%2F2020%2F05%2F20200520192804647578181.jpg&pos_id=kNIFPu7E
微前端架构旨在解决单体应用在一个相对长的时间跨度下,由于参与的职员、团队的增多、变迁,从一个普通应用演变成一个巨石应用(Frontend Monolith)后,随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。

微前端

微前端是一种类似于微服务的架构,是一种由独立交付的多个前端应用组成整体的架构风格,将前端应用分解成一些更小、更简单的可以大概独立开发、测试、部署的应用,而在用户看来仍然是内聚的单个产品。
   Web 应用开发速度快、用完即走等特性,导致的一个最闭幕果就是「能用 Web 技术实现的应用,最终都会通过 Web 来实现」。在近几年涌现了一大批之前只能在传统 PC 软件中才能看到的优秀产品,比方:Photoshop、Web Office、Web IDE。只管随着 Web 标准的演进,前端工程化也在不停演变,从模块化到组件化在到如今的工程化,但在面对跨团队大规模开发、跨团队企业级应用协作,现有的分治设计模式仍然显得故意无力。
好比复杂的系统,由于整个系统涉及范围较广,在实际的研发过程中肯定会以功能或业务需求垂直的切分成更小的子系统,切分成各种小系统后只管由于分治的设计理念提升了开发者体验,但是肯定水平上降低了用户体验。那能否以一种新的架构模式,既保开发者体验,又能提升用户体验呢。
微前端紧张是用于解决:应用增量升级、多技术体系并存、构建大规模企业级 Web 应用而诞生的。
目前微前端紧张是采用应用分而治之 + 动态加载 + SPA 应用的模式来解决大规模应用带来的一系列问题。

为什么须要微前端?



[*] 遗留系统迁移。解决遗留系统,才是人们采用微前端方案最紧张的缘故原由。
[*] 聚合前端应用。微服务架构,可以解耦后端服务间依靠。而微前端,则关注于聚合前端应用。
[*] 热闹驱动开发。新的技术,既然很热闹,那么就学吧。
微前端的实现,意味着对前端应用的拆分。拆分应用的目标,并不但是为了架构上好看,还为了提升开发效率。
https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=https%3A%2F%2Fwww.zhoulujun.cn%2Fuploadfile%2Fimages%2F2020%2F05%2F20200520190348731384958.jpg&pos_id=tgHLz4CO
微前端优势:



[*] 应用自治。只须要遵照统一的接口规范或者框架,以便于系统集成到一起,相互之间是不存在依靠关系的。
[*] 单一职责。每个前端应用可以只关注于自己所须要完成的功能。
[*] 技术栈无关。主框架不限定接入应用的技术栈,子应用具备完全自主权。你可以利用 Angular 的同时,又可以利用 React 和 Vue。
[*] 项目独立:独立开发、独立部署 子应用堆栈独立,前后端可独立开发,部署完成后主框架自动完成同步更新
微前端缺点:



[*] 应用的拆分底子依靠于底子办法的构建,一旦大量应用依靠于同一底子办法,那么维护变成了一个挑衅。
[*] 拆分的粒度越小,便意味着架构变得复杂、维护本钱变高。
[*] 技术栈一旦多样化,便意味着技术栈杂乱。
前端微服务化

前端微服务化,是微服务架构在前端的实施,每个前端应用都是完全独立(技术栈、开发、部署、构建独立)、自主运行的,最后通过模块化的方式组合出完整的前端应用。其架构如下图所示:
https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=https%3A%2F%2Fwww.zhoulujun.cn%2Fuploadfile%2Fimages%2F2020%2F05%2F20200520191001533846436.jpg&pos_id=klmxSyFG
采用这种方式意味着,一个页面上同时存在二个及以上的前端应用在运行。而路由分发式方案,则是一个页面只有唯一一个应用。
如何去拆分应用

技术方式


[*] 路由分发式。通过路由将不同的业务分发到不同的、独立前端应用上。其通常可以通过 HTTP 服务器的反向代理来实现,又或者是应用框架自带的路由来解决。
[*] 前端微服务化。在不同的框架之上设计通讯、加载机制,通过模块的方式组合出完整的前端应用,以在一个页面内加载对应的应用。
[*] 微应用。通过软件工程的方式,在部署构建环境中,组合多个独立应用成一个单体应用。即在开发时,应用都是以单一、微小应用的形式存在,而在运行时,则通过构建系统合并这些应用,组合成一个新的应用。
[*] 微件化。开发一个新的构建系统,将部门业务功能构建成一个独立的 chunk 代码(或称SDK),利用时只须要远程加载即可,如网站加载第三方广告与统计。
[*] 前端容器化。通过将 iFrame 作为容器,来容纳其它前端应用。
[*] 应用组件化。借助于 Web Components 技术,来构建跨框架的前端应用。
[*] SSR服务端渲染合并。利用SSR服务,渲染不同的HTML片段,然后拼凑成完整的HTML文件,直出。
业务拆分



[*] 按照业务拆分。
[*] 按照权限拆分。
[*] 按照变动的频率拆分。
[*] 按照组织布局拆分。利用康威定律来进一步拆分前端应用。
[*] 跟随后端微服务划分。实践证实, DDD 与事件风暴是一种颇为有效的后端微前端拆分模式,对于前端来说,它也颇有有效——直接跟踪后端服务。

微前端的整体架构

https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=https%3A%2F%2Fwww.zhoulujun.cn%2Fuploadfile%2Fimages%2F2024%2F02%2F20240221172921392192410.png&pos_id=xmR0zt6y
 
https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=https%3A%2F%2Fwww.zhoulujun.cn%2Fuploadfile%2Fimages%2F2024%2F02%2F20240221172923700289449.png&pos_id=qo2ejxT7
微前端部署平台





目前较成熟的微前方案有 qiankun、micro-app、EMP 方案,但是它们与MF有着本质的不同,那就是对“微前端”的定义:
方案微的定义微前端的定义Module Federation模块由多个相互独立的模块聚合而成的应用qiankun/icestark等应用由多个相互独立的应用聚合而成的应用 定义上的不同决定了技术实现的不同:
方案技术实现Module Federation模块本质上是JS代码片段,这种代码片段一样平常称为chunk。因此,模块的聚合,实际上是chunk的聚合。qiankun/icestark等应用本质上是HTML,而在SPA中,HTML又是main.js举行填充的。因此,应用的聚合,实际上是main.js的聚合。 技术实现的不同又决定了利用场景的不同:

方案利用场景Module Federation是一种技术升级的创造性工作,有肯定本钱,目标是为了让系统具备更强盛的本领。qiankun/icestark等是一种维持现状的保守性工作,本钱极小,目标是为了让系统拥有更恒久的生命力。 MF的实现其实并没有魔法,仅仅是异步chunk罢了。即便在MF中,不管是共享模块照旧远端模块,其实照旧利用的require.ensure去加载一些异步chunk罢了。只不过稍有不同的是,因为牵扯到依靠共享的逻辑,会有一个shared-scope的概念,用来实现依靠共享的相关逻辑。

这整个过程跟webpack5是没有绑定关系的,也就是说MF并非webpack5的专属功能,Rollup和webpack4都可以实现MF。更多的保举查看:
   

[*] Module Federation 没有魔法仅仅是异步chunk https://zhuanlan.zhihu.com/p/352936804
[*] Webpack Module Federation 核心原理 https://juejin.cn/post/7045211570716016676




参考文章:
微前端在美团外卖的实践 微前端在美团外卖的实践 - 美团技术团队
微前端如何落地? 百度安全验证 
可能是你见过最完善的微前端解决方案 https://zhuanlan.zhihu.com/p/78362028


转载本站文章《微前端学习笔记(1):微前端总体架构概述,从微服务发微》,
请注明出处:微前端学习笔记(1):微前端总体架构概述,从微服务发微 - 前端架构设计 - 周陆军的个人网站

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页: [1]
查看完整版本: 微前端学习笔记(1):微前端总体架构概述,从微服务发微