| 组件化已经过时了吗？微前端架构介绍 | 您所在的位置：网站首页 › 前端模块化和组件化区别在哪 › 组件化已经过时了吗？微前端架构介绍 |
组件化已经过时了吗？微前端架构介绍
|
前言
前两年去面试的时候，面试官可能会问你，写过组件吗，父子组件组件之间是如何通信的？兄弟组件之间如何通信？有没有使用过状态管理工具？ 我最近经历过很多面试，有一个很明显的感触，就是大部分面试官都会问你，接触过微前端吗？知不知道qiankun？ 可能随着年龄的增长，薪资要求也会增长，给得起钱的公司，开发团队可能都具备一定的规模，那么在这种情境下，面试官问你微前端，就非常理所当然了。 由于公司采用了微前端架构，我最近也是在开始学习微前端相关的内容。买了微前端相关的书。接下来，我想给大家介绍一下什么是微前端。 声明：本文主要内容来自《前端架构 从入门到微前端》--黄峰达。 也有部分是自己的理解。 什么是微前端架构微前端是一种类似于后端微服务的架构，讲微服务的理念应用于浏览器端，即将多个单页面前端应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以单独开发、部署。 比如我们一个项目有10万行代码，拆分为10个项目，每个项目由1万行代码。要独立开发和维护每个项目就会容易的多。我们只需要独立开发和部署。 开发过程：而在开发过程中，如果是10万行代码，那么打包和编译的时间是很长的。 测试过程：如果每个项目单独发布，那么可以一定程度上减少测试的范围和工作量。 线上维护：如果线上单个应用宕机，我们只需要维护单个应用即可。无需把整个项目全部重新发布。大大减少维护成本。那么微前端架构有他自己的特点： 应用自治 多个应用可以交给不同的团队来开发，彼此之间解耦，在适当的时候，我们可以替换其中任意一个应用，而整体不受影响。 单一职责 微前端的架构理念应该满足单一职责的原则。但是要实现单一职责，又不是那么容易。 技术栈无关 在项目内部的不同应用之间，我们可以采用不同的技术栈，比如应用a可以采用vue，b采用react，c采用angular，d采用jquery等。 为什么要用到微前端架构1，遗留系统迁移 老旧系统，我们想合成到新系统里面，但是又不想重写老系统，我们可以采用微前端架构，把老系统嵌入到微前端项目。 2，后端解耦，前端聚合 很多时候，后端采用微服务架构，可以把不同业务之间进行解耦。 但是在前端，移动应用出现了一种趋势，一个大型的商业公司，可能拥有非常多的应用，而这么多应用，就会有很多入口。但是在用户看来，这些应用就是同一家公司的，只有一个入口就行了。这时候，可以采用微前端架构，将不同应用聚合。 前端的技术拆分方式 路由分发式直接通过不同的url来访问不同的应用，这种拆分方式下，同一个链接只对应一个微应用。不同的应用之间可以通过localstorage、cookie、indexedDB等方式共享数据，因为他们是处于同一个域名的。 前端微服务化 前端微服务化，就是每个应用都是完全独立的，拥有独立的技术栈、独立的开发、独立的部署、独立的构建，并且自主运行。最后通过模块化的方式组合出完整的前端应用。 同一个页面上可以存在多个微应用。但是在路由分发的情况下，同一个时间只有一个微应用在运行。 组合式集成：微应用化 微应用化，指的是开发时应用都是以单一、微小应用的形式存在的，运行时，则通过构建系统合并这些应用，并组合成一个新的应用。 微件化 微件，是一段可以直接嵌入应用上运行的代码，由开发人员预先编译好，在加载时不需要再做任何修改和编译。 而微前端下的微件化，指的是没给业务团队编写好自己的业务代码，并将编译好的业务代码部署到制定服务器。在运行时，我们只需要加载相应的业务模块即可。在更新代码的时候，我们只需要更新相应的模块即可。 前端容器：iframe iframe作为一个很古老的人人都觉得普通的技术，却一直很管用，可以有效的将一个页面嵌入到另一个页面，出去iframe父子组件通信的代码，其他部分代码完全隔离。 结合Web Components构建 web components 是一套不同的技术，允许开发者创建可重用的定制元素，并且在web应用中使用它们。 关于web components的详细内容可以自行查找。 微前端的业务拆分方式这里说的业务拆分方式，是从业务角度看待问题，区分于技术拆分方式。 按照业务拆分 比如一个电商系统，包含产品、订单、发票、物流、库存等业务模块，按照该方式进行拆分。 按照权限拆分 对于同一时间存在多种角色和多种不同权限的网站来说，可以采用按照权限的拆分方式。尤其是不同权限对应的功能上是分开的。 按照更新的频率拆分 系统里有些业务是迭代频繁的，有些事迭代缓慢的，按照这种拆分方式，哪些不经常迭代的部分就不会收到太大影响。 按照组织的结构拆分 不同团队之间的沟通存在一定的成本，跨团队的合作也存在一定的成本。如果项目由多个团队之间协同开发，可以考虑这种拆分形式。 跟随后端微服务拆分 其实后端的微服务拆分，和前端的项目组织形式没有必然联系，但是如果后端的微服务拆分方式下，对应的前端部分，也有可能是解耦的。 DDD与事件风暴 DDD 是指领域驱动事件，不做详细介绍。 微前端的架构模式 基座模式 这种模式的微前端架构中，基座承担了微前端应用的基础与核心技术。基座模式，是由一个主应用和一些列的子应用构成的系统，并由这个主应用来管理其他子应用，包括从子应用的生命周期到应用间的通信机制。 基座应用可以只是单纯的基座功能，也可以带有业务功能，但是业务功能指的是核心部分的业务功能。如图：作为应用的基础核心，它还要： 维护应用的注册表。 管理其他子应用。包括何时加载应用、核时卸载应用等。 要采用这中模式的微前端架构，只需要设计好对应的应用加载机制即可，因此在实施的时候也比较方便。 自组织模式 自组织，指的是系统内部各子系统之间能自行按照某种规则形成一定的机构或功能。采用这种模式可以使系统内的各种前端应用，各自拥有一个小型的基座管理功能，每个应用都可以是基座。 大多数时候，我们并不会采用自组织模式的微前端架构，因为它设计复杂，拥有大量的重复代码 书籍推荐感兴趣的同学可以看看这本书，讲得很系统。
|
【本文地址】