|
目前国内微前端方案大概分为：
-
基座模式：通过搭建基座、配置中心来管理子应用。如基于SIngle Spa的偏通用的乾坤方案，也有基于本身团队业务量身定制的方案。
-
自组织模式：通过约定进行互调，但会遇到处理第三方依赖等问题。
-
去中心模式：脱离基座模式，每个应用之间都可以彼此分享资源。如基于Webpack 5 Module Federation实现的EMP微前端方案，可以实现多个应用彼此共享资源分享。
其中，目前值得关注是去中心模式中的EMP微前端方案，既可以实现跨技术栈调用，又可以在相同技术栈的应用间深度定制共享资源，如果刚开始调研微前端的话，可以先尝试了解一下EMP微前端方案，或许会给你带来不错的使用体验。
与微服务一样，微前端的独立可部署性是关键。它减少了部署的范围，从而降低了相关风险。无论您的前端代码在何处托管，每个微前端都应该有自己的连续交付通道，该通道可以构建、测试并将其一直部署到生产环境中。我们应当能够在不考虑其他代码库或者是通道的情况下来部署每个微服务。做到即使原来的单体项目是固定的按照季度手动发布版本，或者其他团队提交了未完成的或者是有问题的代码到他们的主分支上，也不会对当前项目产生影响。如果一个微前端项目已准备好投入生产，它应该具备这种能力，而决定权就在构建并且维护它的团队手中。
由于历史包袱，有团队依旧存在使用着陈旧而庞大的前端单体模式，被过时的技术栈或赶工完成的代码质量死死拖住后腿，其程度严重到了让人想推翻重写。为了避免完全重写的风险，我们更加倾向于将旧的应用程序逐步地翻新，与此同时不受影响地继续为我们的客户提供新功能。
微前端能使我们更加自由地对产品的各个部分做出独立的决策，让团队能做到持续地增加新功能并且对原有的整体几乎不做修改，使我们的架构、依赖以及用户体验都能够增量升级。
另外，如果主框架中有一个非兼容性的重要更新，每个微前端可以选择在合适的时候更新，而不是被迫中止当前的开发并立即更新。如果我们想要尝试新的技术，或者是新的交互模式，对整体的影响也会更小。
同时仍然聚合为一个产品出现在客户面前。可以理解微前端是一种将多个可独立交付的小型前端应用聚合为一个整体的架构风格。
值得留意的几个点：
-
微前端不是一门具体的技术，而是整合了技术、策略和方法，可能会以脚手架、辅助插件和规范约束这种生态圈形式展示出来，是一种宏观上的架构。这种架构目前有多种方案，都有利弊之处，但只要适用当前业务场景的就是好方案。
-
微前端并没有技术栈的约束。每一套微前端方案的设计，都是基于实际需求出发。如果是多团队统一使用了react技术栈，可能对微前端方案的跨技术栈使用并没有要求;如果是多团队同时使用了react和vue技术栈，可能就对微前端的跨技术栈要求比较高。
-
（编辑：江门站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
