接触到微前端的概念,有些蒙,觉得架构这种概念自己还是比较遥远的,认为自己还是大树底下好乘凉,小白式开发者一枚,不过还是找了些许书籍查阅一下,做个笔记方便回顾...
微前端架构
微前端像是一种微服务的架构,只不过是将微服务的理念应用与浏览器端,即将单页面前端应用由单一的单体应用转变为把多个小型前端应用聚合为一的应用.各个应用还可以独立开发,独立部署.同时也可以进行并行并发.主要还是前端的拆分,提高效率,比如10w行代码拆解成10个项目,每个项目1w行代码,维护起来相对就容易很多.
-
应用自治
微前端,是多个应用组件的统一应用,只要遵循统一的接口规范或者框架,集成到一起.会分出多个项目,各个项目可以使用各式各样的前端框架,不会受到影响,相互之间不存在依赖关系的.
-
单一职责
微前端,像微服务一样应该满足单一职责。前端需要保证用户体验的连续性.一旦在业务上关联密切,比如b页面依赖a页面,a页面在一定程度上依赖b页面,拆分开来就不容易了,但是如果业务关联少,使用不多,没有什么难度.
-
技术栈无关
后段的微服务的架构,技术栈无关是一个相当重要的特性.对于前端来说,虽然拥有一系列的JavaScript语言,但是前端框架是有限的,之间的差距并不大,基本上都能实现.相对来说技术栈无关还有一系列缺点 :
- 拆分依赖与基础设施的构建,大量应用依赖,维护就会变成一个挑战.
- 拆分的粒度越小,意味架构变得越复杂,维护成本越高.
- 技术栈多样化,意味技术栈是混乱的.
虽然大概了解一些微前端知识,懵懂一些思想, 但是到底应该在什么时候采用微前端架构呢?
为什么需要微前端
-
遗留系统迁移
过去那些使用Vue.js等框架编写的单页面应用,已经在线上稳定的运行了,也没有新的功能,对于这样的应用,没有理由浪费时间和精力重写旧的应用了.而那些旧的,不再维护的技术栈编写的,框架本身已经不更新了的,这应用因此称为遗留系统.既然应用可以使用,就不要花太多力气重写,而是直接整合到新的应用中去.
不重写原有系统,同时还可以开发新的业务,对于业务人员来说,相当又吸引力,对于技术人员来说,也是相当不错的事情.人生苦短,请尽量不要重写.
- 聚合前端应用
最近几年,移动应用出现一些趋势,即用户不想装那么多应用了,而一家大的商业公司,往往会提供一系列的应用.这些应用从某些程度上反映了这家公司的组织架构,然而在用户的眼里,他们就是一个公司,他们就应该有一个产品.聚合成为客户端的一个技术趋势,实现前端聚合的就是微前端架构
- 热闹驱动开发
“流行”就应该采用某个新的技术和架构,软件开发所做的软件架构或技术栈的决策,其中很多决策并没有经过踏实的研究和对目标成果的认真思考,而是不准确的意见,社交媒体的信息,或者就是‘热闹’的玩意.
