这是一段充满启发性但坎坷的旅程，所以在你决定微前端是否适合你之前，我想分享一些我的想法和想法。
什么是微前端？
Web 应用程序的复杂性最近呈爆炸式增长。 单一的方法不再能满足业务和开发速度的要求。 微服务架构已经将后端开发人员从这个负担中解脱出来，但许多前端人员仍然在为不断增长的单体代码库而苦苦挣扎。
最重要的是，前端生态系统也在迅速发展。 工具和框架不断变化。 受微服务架构成功的启发，前端工程师开始寻找拆分前端单体的方法。 这将改善开发人员的体验，同时为用户维护应用程序的完整性。
实现该目标的最清晰途径是微前端架构。 英国软件开发商 Martin Fowler 将微前端定义为“一种架构风格，其中可独立交付的前端应用程序组合成一个更大的整体。” 换句话说，我们将单体前端应用程序分解为更小的独立前端部分。 这些相互连接的部分构成了整个应用程序。
你需要微前端吗？
Dan Abramov，软件设计师 Facebook，可以帮助回答这个问题。 “问题 [micro frontends are] 应该解决我的声音，就像他们已经被一个好的组件模型解决了一样。 那么这是解决组织问题而不是技术问题吗？ 例如，如果两个团队无法就任何事情达成一致，甚至共享基础设施。”
前端开发人员必须定期区分业务逻辑、可视化组件、逻辑组件、实用程序等。这并不是什么新鲜事。 这种模块化为代码库带来了清晰性，并为 Web 应用程序带来了一定程度的可扩展性。
简单地选择现有的前端框架通常会预先确定架构和扩展方式。 对于许多项目来说，这个决定就足够了，应该是考虑微前端架构之前的第一步。 但是，当企业经历快速增长阶段时，需要额外的模块化。 成长中的企业需要快速更改更多动态代码部分并保持领先于竞争对手。 随着组织结构的复杂性增加，他们最终需要更多的工程团队。 在这种情况下，应用程序级别的模块化可能还不够。 微前端架构可能是造成差异的缺失组件。
与任何架构决策一样，微前端架构有助于解决技术和组织挑战。 Nord Security 也是如此：
- 我们的一些应用程序有太多不同的业务领域逻辑结构，它们是同一代码库的一部分，但在其他方面是不相关的；
- 我们需要在几个不同的相关 Web 应用程序中共享我们的逻辑和 UI 的一小部分；
- 我们的许多更改都是针对代码库的一小部分进行的。
分离应用程序并赋予团队对其代码库的完全所有权使我们能够更快地开发，仅部署那些已更改的代码部分，隔离任何导致错误的范围，当然，更快地测试更小的代码部分。 除了这些好处之外，我们还可以继续重新评估每个微前端，并在必要时进一步拆分。 很容易看出微前端架构是我们的正确选择。
除了上述好处外，微前端还可以实现逐步的技术迁移并允许技术独立。 为了 example，可以在同一个浏览器窗口中运行多个框架。 但是，此用例可能会给工程师带来性能和兼容性问题以及额外的认知负担。 这对于技术迁移或实验可能是一种有用的方法，但应谨慎使用。 这将我们引向我的下一点……
没有银弹
还必须考虑微前端架构的潜在缺点。 根据 Amazon Web Services 的解决方案架构师 Luca Mezzalira 的说法，微前端架构有四个基本支柱：
- 定义：我们定义了微前端的大小和范围；
- 作品：我们将在何处以及如何将我们的微应用程序、组件或小部件拼接在一起；
- 路由：我们为客户定义需要加载的内容；
- 沟通：我们的微前端应该如何以及何时相互通信。
每个决定都有其优点和缺点。 客户端组合可以节省大量公司资源并很好地横向扩展。 但是，如果 SEO 对业务至关重要，那么边缘端或服务器端的组合就是要走的路。 其他 example 是微前端拆分。 在组件级别进行拆分可能看起来非常有吸引力，但这可能会带来其他挑战，例如共享依赖版本控制和页面布局所有权。
最后，工程部门和团队需要确保他们都是同步的。 从长远来看，跨团队采用不同的方法只会引入额外的问题并减慢您的速度。 归根结底，所有微前端都是客户旅程的一部分，必须创造不间断且愉快的用户体验。 每个步骤之间的标准化通信对于开发人员和用户体验都至关重要。
在组织层面实施
由于微前端架构在行业中仍然是一种相当新的方法，因此对于具有决策和架构原则的板载工程师来说至关重要。 跳过这一步可能会导致很多误解，甚至是微前端的无政府状态。 实现此架构有多种不同的方法，因此您的所有工程师都应该了解您的公司计划如何实现它。
演讲、研讨会、公开讨论、分享专家的最新见解——这些都是有效的工具。 在 Nord Security，在编写任何代码之前，我们创建了多个关于微前端以及我们如何想象它们的演示文稿。 我们分享了来自其他公司和行业专家的见解和播客。 这使我们的工程师、质量保证人员和经理都在同一个页面上。 如果你有兴趣，我建议关注这些人：
- 乔尔·丹宁
- 卢卡·梅扎利拉
- 扎克杰克逊
- 迈克尔·吉尔斯
不要忘记组织的业务方面。 如果业务团队经常创建影响应用程序多个部分的任务，那么使用微前端可能会阻止他们发挥最大潜力。 与利益相关者讨论这种架构转变，以增加协作并打破孤岛。 最重要的是，就这个主题与业务人员合作可以为您的微前端应该如何分离提供很好的指导。
不要用鼹鼠山造山
在讨论架构返工时，许多工程师立即想到从头开始构建一些东西或重写大量代码。 有时，这可能是唯一的选择。 然而，Javascript 生态系统接受了微前端作为架构选择，并开始使用工具支持它。 Webpack 5 的发布引入了模块联合功能。 与此类似，我们有主动实现导入地图，这也是支持的 系统js. 最后，旧的和有争议的 iframe 也可以完成这项工作。
有了这些技术，向微前端的转变可以是渐进和平稳的。 测试和确定正确的微前端大小会更容易。 与单体前端的逐步代码分离也不会减损业务功能交付。
结论
对于某些项目，微前端架构可以成为将可扩展性、可测试性和开发人员体验提升到一个全新水平的好方法。 DAZN、Spotify 和宜家等玩家已经证实了这一点。 然而，在采用这种方法之前，他们每个人都经历了漫长的旅程。 每一次旅程都让该公司最好地满足其需求。 研究、迭代实验和组织层面的知识共享将为成功的微前端之旅铺平道路，并使公司能够充分利用它。
想阅读更多这样的内容吗？
获取最新消息和提示 NordVPN.
订阅订阅您已成功订阅我们的时事通讯！电子邮件无效订阅我们不会发送垃圾邮件，您将始终可以退订。
