
微前端原则
|
17
2.3.7
高度可观察性
前端监控变得日益重要,
Sentry
和
LogRocket
这样的工具为每个开发人员提供了丰富的可
视化功能。使用这些工具对于了解应用在哪里失败以及为什么失败至关重要。就微服务而
言,故障随时随地都可能发生,能够快速解决问题远比预防问题更重要。这让我们迈向了
一种模式:投入更多资源准备随时解决系统故障,而非试图完全预防故障。与其他微服务
原则一样,这也适用于前端。
在认识到这些前端和后端的原则之后,我们终于找到了解决方案。它促使开发团队掌控整
个业务领域,以更简单的方式进行跨组织的劳动分工,也让系统更加敏捷地更新迭代。
在开始这段“微世界”之旅时,我们需要意识到微前端会增加项目复杂度,而这种复杂性
在其他项目中可能是不必要的。很多公司更偏向使用单体架构,因为微服务会带来内在的
复杂性。出于同样的原因,我们必须弄清何时以及如何正确使用微前端,因为并非所有项
目都适合采用这一架构。
2.4
微前端不是万能灵药
在工作中使用正确的工具非常重要。我经常看到由于错误的架构决策导致了项目失败或大
幅延期的情况。
由于微前端的本质特性,以及微前端可能会在技术及组织层面增加复杂性,
因此它并不适用于所有应用。
当软件需要不断迭代和长期维护时,当需要多个团队共同开发一个应用时,当我们想以迭
代的方式迁移一个旧项目时,微前端是一个明智的选择。但是,微前端对某些应用并不适
用,比如服务器端渲染、单页应用或者单
HTML
页面应用
。微前端有许多优点,但也有很
多缺点和问题。如果对于一个项目来说,其缺点多于优点 ...