背景最近在项目开发中使用qiankun框架做微前端。但是没有从0开始系统的了解和实战。所以希望通过几篇文章重新认识微前端的架构，主要从几个方面：它是什么，为什么有实现原理，以及主流框架项目实战在谈微前端之前，我们需要先了解一下后端微服务，因为微前端本身就是吸收了微服务的概念而产生的，所以我们先对微服务做一个简单的认识：在2014年，MartinFowler和JamesLewis共同提出了微服务的概念定义，微服务被定义为由单个应用程序组成的小型服务。他们有自己的流程和轻量级处理。服务按业务功能设计，全自动部署。他们将HTTPAPI与其他服务结合使用。沟通。同时，该服务将使用最小规模的集中管理（如Docker）能力，该服务可以用不同的编程语言和数据库——维基百科微服务等组件来实现。微服务架构通常与单体软件架构进行比较。单体软件存在以下问题：所有功能耦合在一起，相互影响，最终难以管理。哪怕只修改一行代码，整个软件都得重新构建和部署，成本非常高，不可能每个功能都独立开发测试，只能整体开发测试，这就导致需要采用瀑布式开发模式，所以开始把单体软件拆分成功能单元，服务+通信协议，这种叫做面向服务的架构（简称SOA），也是微服务的雏形。因此，微服务架构等同于面向服务的架构。它有多种实现方案，最佳实践是基于Docker容器。微服务的几大特点：敏捷、快速迭代弹性部署自身微服务、快速持续集成部署、服务独立性增加应用响应故障的灵活性、技术自由度、自由选择最佳工具解决自身问题problems具体问题Reusablecode，为一个功能写的服务可以作为另一个功能的积木好了，微服务理解到这里基本有个大概的了解，当然微服务不只是这些，还有一些其他的技术点，比如如：服务发现、事件传播等。微前端了解了微服务之后，为什么会想到微前端这个概念呢？微前端一词最早于2016年底在ThoughtWorksTechnologyRadar中被提出。这个概念将微服务这种在服务器端广泛使用的技术范式延伸到了前端领域。微前端是多个团队通过独立发布功能共同构建现代Web应用的技术手段和方法策略。——微前端完整介绍简单来说，微前端架构是微服务概念的延伸，一种适合前端的微服务架构。什么是微前端通过上面的开发过程，我们对微前端的架构和定义有了一个简单的了解。接下来，我们将通过不同类型的对比，对微前端有更深入的了解。SingleMonolithVSMicro-frontend对比monolithic单体架构和微前端架构可以更好的理解微前端架构，如下图所示：简单来说就是将原本耦合在一起的monolithic单体应用按照以某种原理拆分成各种微前端小应用。最简单的拆分方案就是和微服务做一对一的映射。组件VS微前端让我们换个角度来看微前端。如果我们把微前端看成一个组件，是不是比较好理解，但是这个组件有点大，功能比较齐全，没有对外提供参数配置。但是从两者的实际应用场景来看，还是有很多区别，如下：从应用场景来看，组件是不可运行的，被调用的是应用的一部分，而微前端是一个fullyrunnableone从技术角度来看，组件是基于一定的框架实现的，而微前端应用不依赖任何框架，但是微前端架构会依赖一定的框架来实现总结微前端架构，就是把复杂的问题简单化。每个微前端项目只需要关心自己的事务。因此，微前端架构的核心思想是：技术不可知，每个微前端都应该选择自己的技术栈和技术演进路线，而不是跟其他团队看齐。同时，架构师要考虑如何高效地提供可重用的WebComponent，将成为环境隔离的核心问题。微前端架构中的各个子项目不共享运行环境，即：不依赖共享状态或全局变量，也可以使用命名约定（如：前缀）或命名空间。首先隔离各个微前端应用的原生API，使用原生浏览器事件机制进行通信，而不是自己搭建一个PubSub系统独立，微前端架构中的每个子项目都是完整的，可以独立运行，独立开发，并独立部署高可用，微前端架构高可用，即使某个子应用出现异常，也不会影响其他子应用的访问。以上就是实现微前端架构需要考虑的点，也是架构中的核心思想。缺点微前端架构有上面介绍的很多优点，但是如果架构设计的不好，也可能会导致一些问题，所以我们需要提前了解微前端架构可能存在的缺陷：增加运维成本，因为本来只需要发布一个应用，但是需要发布N个应用。拆分的粒度越小，架构越复杂，开发和维护的成本就越高。微前端支持不同的技术栈，这也带来了不同的技术栈，给技术栈带来了混乱。风险，同时也增加了开发和维护成本微前端架构本身完全独立于项目，这可能会导致一些公共代码无法使用。还有一些其他的问题，比如：当使用某种类型的微前端框架会增加开发成本等。这些问题，在项目中是否需要使用微前端架构是需要考虑的，但是有也是可以提供给大家参考的一句话。工程是权衡的艺术，微服务（microframeworks）架构为你提供了一个权衡的维度。了解了它是什么之后，接下来就是要在项目中实现微前端架构时要做什么。Howtodo在项目中实现微前端架构，主要有几个工作项：首先，需要弄清楚如何将项目拆分成微前端子项；其次，选择类型和使用的微前端框架；最后，使用实施渐进的解决方案，而不是一次性全部切换。如果新项目直接采用微前端架构，那么推荐使用Monorepo大仓+微前端，这样会大大降低项目的管理成本。微前端架构如何拆分主要的工作就是拆分，那么问题来了，我们应该按照什么标准来拆分呢？我们一般可以考虑以下几点：第一，拆分条件，项目是否适合微前端架构第二，拆分原则，拆分项目时需要遵循的设计原则第三，拆分方式，项目拆分可以依据拆分拆分条件有哪些因素我们要设计项目的微前端架构时，应该从以下几个方面考虑是否合适：是否需要快速迭代，是否需要快速迭代，就是说业务需要快速响应，那么使用微前端架构来拆分，不仅支持快速迭代，还支持业务的快速试错。代码提交是否有很多冲突，如果有，说明代码管理成本高，微前端架构可以降低项目的管理成本小功能是否需要等待大版本场景，如果是，说明小功能会影响大版本功能。小，从而降低大版本延迟发布的风险从以上几个方面，我们可以明确判断当前项目是否需要调整微前端架构。只有这个时候，微前端的拆分才会有一定的好处。维护成本是值得的。拆分原则当我们需要拆分微前端时，可以参考以下原则：单一职责原则，每个微前端只需要关心自己的业务规则，保证职责单一，避免交叉职责服务自治原则，每一个微前端的开发都必须具备开发、测试、运维、部署等全过程，即应用可以独立运行，不依赖于其他应用不断进化的原则。在单体架构向微服务架构拆分的过程中，不能一蹴而就，应该逐步拆分细化，不断演进，避免微服务数量瞬间爆发式增长。依赖和循环依赖会导致微前端在迭代释放的时候不知道先释放哪个。拆分时需要考虑，为依赖部分下沉，拆分为公共模块。水平拆分的原则拆分微前端应该是按照依赖级别水平拆分，而不是垂直拆分，因为拆分越深，维护成本越高。以上两种拆分方法主要是基于拆分的假设。从这几个方面入手：根据业务领域，参考领域模型，将相似的业务划分到同一个微前端，按照职责单一和功能完整的原则进行拆分。根据组织架构，尽量避免对组织架构和团队进行调整。避免因为功能的重新划分而增加团队之间大量不必要的沟通成本把迭代频率高的放到一个微前端，把迭代频率低的放到另一个微前端。学习了拆分方法后，里面的优先级应该大致排序，业务领域>组织架构>技术栈>需求迭代频率，我推荐的方法是：先按照业务领域拆分，拆分的粒度不够了，然后按照组织架构拆分再往下走，也就是按照技术栈拆分再往下走，也就是迭代频率的需要微前端框架理解完如何拆分之后，下一步是选择微前端架构实现的框架。以下是从网上收集的目前市场上主流的几大微前端框架：spa，可以更轻松无痛无边界的搭建一个可用的微前端框架。基于iframe，micro-app，一个实现路由同步机制的微前端框架框架，借鉴了WebComponent的思想，结合自己定义的ShadowDom，将微前端封装成类WebComponent的微-frontendframeworkwebpackmodulefederation，在构建webpack时加载上面通过远程应用实现的微前端架构方案是目前实现微前端架构的主流框架。当然，每个框架都有自己的优点和缺点。是否有需要改造的项目，改造成本是多少，是否有学习成本，学习成本有多复杂？未来是否有足够的可扩展性？是否有熟悉并精通选拔团队的人？，问题是否有回应，迭代是否正常进行。到这里，微前端架构的介绍就基本结束了。虽然理论知识很多，但我们可以再回顾一下，总结一下要点：微前端架构源于微服务架构，两者主要是解决巨石应用的痛点，迭代缓慢，而开发复杂的微前端架构拆分需要注意几点：拆分条件，拆分原则，拆分方法微前端架构的主流框架：single-spa，qiankun，unbounded，micro-app，webpack模块联邦等。当然我不会只写理论知识点，后面我会针对每个框架写一篇深入实战的文章，一一描述其背后的原理和适用场景。建筑之路并不平坦。希望大家一起努力。其他概念领域驱动设计了解一个新事物，首先弄清楚它解决的是什么问题？领域驱动设计主要是为了解决：帮助团队更好地理解业务世界可以帮助开发和构建好的设计来降低业务逻辑和开发逻辑之间的耦合度，降低复杂度。那么现在，我们明白什么是领域驱动设计了吗？是一种强调商业概念和专业术语的开发设计理念。以下是官方的一些解释。前端架构系列后面会专门写一篇文章深入介绍：领域驱动设计（Domain-DrivenDesign，简称DDD）是一种强调业务概念、技术术语和原则的开发范式。在帮助用户、团队和软件开发人员解决复杂的信息系统和软件方面。它以图形模型为核心，其目标是使开发人员能够理解、分析和掌握业务概念，并将这些概念转化为可操作的软件。——【ChatGPT答】领域模型领域模型来源于领域驱动架构（DDD）中的一个概念，领域模型表达的是与业务相关的事实，它更关注业务知识，是否能够明确清晰地表达业务语义。参考资料模块联合在微前端架构中的实践什么是微服务？——阮一峰微前端完整介绍领域驱动架构（DDD）建模中的模型到底是什么？更多精彩内容，可以访问我的个人博客：【qborfy的个人博客】
