最近在做公司的微前端，整理了一份微前端搭建清单。如果你在考虑要不要做微前端，不妨做个参考。需求分析技术解决方案分析拆分解决方案分析部署过程分析需求分析第一步，我们需要进行需求分析，以便真正了解我们需要解决什么问题。比如：产品需要添加业务模块，产品需要修改项目样式，产品反馈项目启动太慢，产品反馈页面跳转刷新很不友好。前两个需求是典型的业务需求，其核心是解决公司的业务问题。对于这类需求，通常技术难度并不大，开发者只需要根据原型图编写相应的页面即可。后两个需求是典型的技术需求，其核心在于解决技术问题。一般来说，技术需求与用户体验相关，但不会影响项目功能，所以一般产品很少提及技术需求，都是由开发同学主导。目前很多企业对技术要求不太重视，主要是因为与公司业务无关，不能带来实实在在的、看得见的收益。事实上，一些技术需求往往能产生巨大的成本效益，所以我们在做技术需求的时候，首先需要公司的支持。为什么选择微前端来解决一个技术需求，方法有很多种，为什么选择微前端？我们看过微前端的发展史，就会明白它并不是凭空出现的，而是在项目不断发展过程中形成的解决项目臃肿的技术方案。项目刚成立时，体量不大，但随着项目的不断壮大，可能会出现以下问题：项目膨胀、分支混乱、代码冲突、打包麻烦、维护困难。对于这些问题，很难找到完美的解决方案，于是微前端诞生了。有了微前端，我们可以把一个大项目拆分成多个小项目，这样每个小项目都非常容易优化。把所有的小项目都优化好之后，我们就可以把这些小项目组合起来，组成一个完美的大项目。在实际项目中，如果遇到以下问题，可以考虑使用微前端：项目太大，变成典型的单体应用，打包速度很慢。项目开发人员过多，多个同学开发同一套代码，经常会导致代码冲突或者修改公共组件导致的bug。项目太老，有遗留模块，为了兼容，限制了整个项目的发展。项目技术栈不统一，使用了多种不同的框架，每个框架多个版本并存。项目由多个团队共同开发，一个功能需要其他团队共同开发才能开发。该项目的每个版本都是完整版本。即使启动了一个小模块，也可能导致整个项目挂掉。项目由多个系统组成，完成一个功能需要连续跳转多个系统页面。项目开发人员流动性大，一些祖传代码难以维护，普通人很难更改。该项目需要一些实验领域的计划，即需要在某些模块上进行一些新技术的尝试和框架的升级。...另外，还有很多实际情况没有列举出来，不过没关系，只要了解微前端的特点，我们就可以判断任何情况。微前端特性微前端的核心是解决单体应用，它有这些特点：简单、松散耦合的代码库微前端架构倾向于编写和维护更小、更简单、更易于开发的项目。技术栈无关，每个项目可以使用不同的技术栈。增量升级支持逐步重构，先让新旧代码和谐共存，然后逐步改造旧代码，直到整个重构完成。独立部署每个子应用都具有独立开发、持续部署、独立运行的能力。团队自治的子项目之间不存在依赖关系，保持隔离。职责单一，每个子项目只做与自身相关的业务工作。此外，微前端提供了一个新的生态系统。它通过拆分小项目生成大量的微应用。试想一下，如果每个人都把微应用上传到云端，那么就会建立一个非常强大的微应用云生态。以后我们做需求的时候，可能就选择各种合适的微应用，然后把它们拼接起来，就完事了。敬请期待。微前端的缺点当然，微前端也不是万能的，它也存在以下问题：拆分的粒度越小，架构越复杂，维护成本越高。技术栈一旦多样化，就意味着技术栈混乱了。管理版本复杂，依赖复杂。开发体验不是很友好，开发时可能需要同时启动多个项目。这些问题大多是项目拆分成多个项目后的沟通协作问题造成的。在技??术方案研究的第二步，我们需要确定微前端的具体实现方式。微前端的实现方式有很多种：路由分发利用http服务器的反向代理功能将请求路由到相应的应用。该方法在路由层面看起来只是一个item，但实际上只是通过a标签将多个item连接起来。前端容器化使用iframe作为容器。SEO不友好。需要考虑同源策略cookie管理。需要建立一套应用管理和应用通信机制。弹出窗口不友好。浏览器后退按钮对用户不友好。前端微服务在不同的框架上设计通信和加载机制，在一个页面加载相应的应用。常用的框架：qiankun和single-spa都是这样做的。最常用的方案，适合快速上手。Widgets封装了可以直接嵌入到页面运行的代码。可能是一段js，使用的时候直接导入即可。需要实现一套widget管理机制，成本太高。微应用通过软件工程在部署搭建环境中通过webpack进行打包，将多个独立的应用组合成一个单一的应用。多个项目需要打包成一个，所以技术栈需要统一。应用组件化将子项目打包成webComponents，组合到主项目中。需要考虑webComponent的兼容性。下图展示了各种方案的优缺点：这么多的方案各有优缺点，我们应该如何选择呢？如果你只是想快速简单地分离，而不考虑seo，你可以使用iframe。如果想在做分离的同时保持良好的单页体验，可以考虑single-spa和qiankun框架。如果公司技术能力强，再考虑自主研发或其他方案。有了这个技术方案，微前端之路就可以走通了。此外，还需要考虑过渡计划。过渡方案过渡方案是指如何让微前端顺利上线。试想一下，如果项目在微前端改造过程中有新需求怎么办？对于这个问题，建议在做微前端改造的时候，最好快速上线：首先把整个原项目当成一个大的子项目，进行微前端改造。主项目快速搭建路由和子应用管理，然后马上上线。路由管理处理子项时，如果是原始页面，先通过a标签跳转，如果是新页面，则使用前端路由控制跳转。后续子项目会逐步拆分。如果拆分出一个新的子项目，只需要将a标签改成跳转到前端router控件即可。完成前两步后，我们的架构就变成了微前端架构。拆分计划研究的第三步，我们需要思考一下我们要如何拆分我们的项目？常见的拆分方案如下：按业务拆分如：一个电商后台，包括商品管理、商户管理、物流管理等。将各个业务项目分开，可以使整个项目结构清晰。按权限拆分例如：一个操作后台，管理员看到的页面和普通操作是不一样的。将不同的权限项分开，突出每一项的使用范围。按照变更频率拆分，比如：一个项目包括很少变更的祖传项目和变更频繁的业务项目。独立隔离经常变动的项目，可以避免频繁更新可能导致整个项目挂掉的风险。很少改变的独立项目使我们能够在核心业务中大显身手。根据组织结构，比如：一个项目背景，功能复杂，由多个团队共同开发。将不同团队的项目分开，避免出现开发冲突、部署冲突等问题。跟随后端微服务的拆分，例如：后端已经将微服务拆分成不同的模块，前端可以直接跟随后端。这种方式有利于保持前后端的统一。至此，我们完成了微前端的拆分，但是拆分之后还没有结束。我们也考虑了分裂后的一些问题。比如：主项目和子项目的样式是否需要复用？项目权限是分离的还是统一管理的？应用程序如何相互通信？这些问题往往与业务有关，我们在改造过程中可以自己判断。部署过程回顾作为最后一步，我们需要考虑部署过程。当微前端开发完成后，我们的项目从1变成了1+n（子项目），部署方式势必发生变化。传统的部署方式如下：微前端项目的部署方式如下：可以看出项目最终的结构是完全不同的，开发、测试、部署过程也需要变了。开发环境的部署测试环境的部署线上环境的部署开发环境的部署开发环境的部署其实不需要部署。通常，前端会启动一个localhost页面来调整后端开发接口。需要注意的是：子项目需要支持独立启动，而不是开发时启动所有项目，只启动与业务相关的子项目。子项目需要支持独立部署。开发完成后，只需要部署与业务相关的子项目即可。测试环境的部署测试环境的部署变化较大，涉及跨部门沟通，需谨慎对待。以往的测试部署流程是这样的：前端只需要提供一个打包文件，测试解压文件后，放到指定的静态资源目录下。微前端后部署流程：前端需要提供主项目及相关子项目的打包文件，测试需要在测试前将多个项目分别发布。这样一改之后，测试的工作量变大了，对手动部署的测试确实影响很大。为了减少测试的工作量，我们可以辅助测试构建一套自动化部署工具。很多大厂都有自己的内部云服务平台，就像阿里云的k8sconsole。测试时，可以在控制台选择需要部署的前后端分支，点击一键部署即可完成测试。线上环境部署线上环境，一个主项目和n个子项目运行，每个项目独立部署，相互独立，非常适合容器化部署，即每个项目部署到一个在docker中，它们通过主项目相互关联。如图所示，所有的子项目都由主项目管理。如果持续部署在内部完成，部署会更容易。思考与总结本文从需求分析入手，一步步理清微前端需要注意的各种问题，以及一些解决方案。希望对微前端感兴趣的小伙伴有所收获。其实微前端并没有想象中那么难。如果使用qiankun、single-spa等现成的框架，学习成本非常低。向上。最后，如果你对此有什么想法，欢迎留言评论！
