下载掌阅APP，畅读海量书库
立即打开
微前端原则需要基于微服务的概念进行探讨。然而，微服务原则是否完全适用于微前端，在《微服务设计》
一书中，作者总结了微服务的相关原则，如图2-1所示。
图2-1 微服务原则脑图
独立部署的意义在于降低发布时的容错率。对于传统的单体应用而言，即便是一次小小的代码改动，都可能导致整个系统崩溃。在前端领域，独立部署意味着各个团队不再互相依赖，每个前端团队可以完全掌控自己领域内的项目。在其负责的项目范围内，团队可以自主安排开发和发布计划，而无须关注上下游的依赖。
故障隔离意味着“微”项目的错误不会影响父项目或兄弟项目，它可以在自身内部处理错误。例如，因网络问题导致的页面不存在或子系统代码运行时错误等。
在服务器领域，可观察性指的是拥有完善、灵活的监控和日志系统。类比到微前端领域，高度可观察性意味着能否准确定位和响应微前端中各个子系统及其关联关系中的错误。在微前端中，监控至关重要，通过使用现成工具可以快速发现并解决问题。
围绕业务领域建模是指根据领域驱动设计的思路，通过业务视角的划分来拆分系统。微前端的拆分通常不是单一维度的。也就是说，微前端设计要结合软件系统架构，涉及产品、UI、服务器设计、业务设计，甚至交互设计和测试等多个方面，需要与上下游部门协同，统筹规划微前端的拆分方案。
当然，如果将所有背景因素都纳入规划，最终的微前端方案可能会非常复杂。笔者认为，在大多数情况下，按照业务领域划分，并结合后端微服务架构的拆分方案，足以合理设计微前端的子系统。
自动意味着减少了人工手动处理可能带来的意外错误。乌龙指问题并非夸张，频繁的手动发布和部署，尤其是在依赖复杂的微前端系统中，会显著增加出错的风险。对于如此庞大的项目，一次发布错误可能导致大量用户流失，这无论从哪个角度看，都是我们不希望看到的结果。
因此，在微前端环境下，自动化部署和持续集成成为必然的发展趋势。自动化部署可以让项目以可靠、快速、安全的方式持续推进。
在整个系统架构中，拆分出来的子系统并不意味着完全独立。在大多数情况下，这些子系统可能需要进行父子通信，甚至兄弟通信。
在第1章中，我们讨论了编程和模块化的目的，其中最为核心的部分是函数的输入与输出。通过函数的入参作为输入内容，并通过函数的返回值暴露必要的接口，从而达到隐藏函数内部逻辑细节的目的。
在微前端通信时，我们也需要类似的思路，让团队专注于自身的实现细节，而不干扰其他团队的工作。每个团队无须依赖外部，可以根据自己的节奏安排开发计划，创建更高效的集成。
分布式是指多个系统协同合作来完成特定任务。在微前端领域，分布式意味着我们可以把一个庞大且复杂的项目拆分为各个独立的子系统，按照业务领域划分子项目，最终通过协同组合，形成一个与原系统功能无异的完整项目。