黄峰达：如何设计微前端架构？
极客时间编辑部
讲述：杜力大小：2.05M时长：04:28
此前，卡姆·杰克逊（Cam Jackson）所写的微前端文章一经发布，就在技术圈引起了广泛讨论，近日，微前端专家黄峰达在 InfoQ 上发文探讨了他对于微前端落地的看法。以下为具体内容。
微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署，同时，它们也可以在共享组件的同时进行并行开发。
微前端的实现，意味着对前端应用的拆分。拆分应用的目的，并不只是为了架构上好看，还为了提升开发效率。为此，微前端带来这么一系列的好处：
应用自治。只需要遵循统一的接口规范或者框架，以便于系统集成到一起，相互之间是不存在依赖关系的。
单一职责。每个前端应用可以只关注于自己所需要完成的功能。
技术栈无关。你可以使用 Angular 的同时，又可以使用 React 和 Vue。
除此，它也有一系列的缺点：
应用的拆分基础依赖于基础设施的构建，一旦大量应用依赖于同一基础设施，那么维护变成了一个挑战。
拆分的粒度越小，便意味着架构变得复杂、维护成本变高。
技术栈一旦多样化，便意味着技术栈混乱。
毕竟微前端不是银弹，它和微服务一样会带来大量的挑战。
就当前而言，要设计出一个微前端应用不是一件容易的事，主要原因在于还没有最佳实践。在不同的落地案例里，使用的都是不同的方案。出现这种情况的主要原因是，每个项目所面临的情况、所使用的技术都不尽相同。为此，我们需要了解一些基础的微前端模式。
微前端应用间的关系来看，主要分为两种：基座模式（管理式）、自组织式。分别也对应了两者不同的架构模式：
基座模式。通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。
自组织模式。应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。
就当前而言，基座模式实施起来比较方便，方案上便也是蛮多的。
而不论哪种方式，都需要提供一个查找应用的机制，在微前端中称为服务的注册表模式。和微服务架构相似，不论是哪种微前端方式，也都需要有一个应用注册表的服务，它可以是一个固定值的配置文件，如 JSON 文件，又或者是一个可动态更新的配置，又或者是一种动态的服务。它主要做这么一些内容：
应用发现。让主应用可以寻找到其它应用。
应用注册。即提供新的微前端应用，向应用注册表注册的功能。
第三方应用注册。即让第三方应用，可以接入到系统中。
访问权限等相关配置。
应用在部署的时候，便可以在注册表服务中注册。如果是基于注册表来管理应用，那么使用基座模式来开发比较方便。
另外，在实践微前端的过程中，还有以下几点是我们在设计的过程中，需要关注的内容：
中心化：应用注册表。这个应用注册表拥有每个应用及对应的入口。在前端领域里，入口的直接表现形式可以是路由，又或者对应的应用映射。
标识化应用。我们需要一个标识符来标识不同的应用，以便于在安装、卸载的时候，能寻找到指定的应用。一个简单的模式，就是通过康威定律来命名应用。
应用生命周期管理。
高内聚，低耦合。
前端微架构与后端微架构的最大不同之处，也在于生命周期。微前端应用作为一个客户端应用，每个应用都拥有自己的生命周期。这也是微前端的一个难点所在，如何以合适的方式来加载应用——毕竟每个前端框架都各自不同，其所需要的加载方式也是不同的。当我们决定支持多个框架的时候，便需要在这一部分进入更细致的研究。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论