本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 将微前端与替代架构进行比较
与所有架构策略一样，采用微前端的决定必须基于以组织原则为指导的评估标准。微前端各有优缺点。如果您的组织决定使用微前端，则必须制定策略来应对分布式系统的挑战
在选择应用程序架构时，最受欢迎的微前端替代方案是单体结构、n 层应用程序以及与单页应用程序 (SPA) 前端相结合的微服务。这些都是有效的方法，每种方法都有优点和缺点。
## 巨石
不需要频繁更改的小型应用程序可以作为整体快速交付。即使在预计会有显著增长的情况下，巨石也是自然而然的第一步。稍后，可以将巨石淘汰或重构为更灵活的结构。从一块巨石开始，您的组织可以更快地进入市场、获得客户反馈并改进产品。
但是，如果不谨慎维护或代码库随着时间的推移而扩大，单片应用程序往往会降级。当多个团队为同一个代码库做出重大贡献时，他们很少都为其维护和运营做出贡献。这会导致责任失衡，从而影响速度并导致效率低下。同时，随着代码库的发展，整体模块之间的无意耦合会导致意想不到的副作用。这些副作用可能导致故障和中断。
## N 层应用程序
具有相对静态发展速度的更复杂的应用程序可以构建为三层架构（演示、应用程序、数据），在前端和后端之间有一个 REST 或 GraphQL 层。这要灵活得多，不同级别的团队可以在一定程度上独立发展。n 层应用程序的缺点是部署功能要困难得多。前端和后端通过 API 合约分离，因此重大更改必须一起部署，或者必须对 API 进行版本控制。
考虑以下常见场景：如果发布新功能需要更改数据架构，则产品负责人可能需要几天时间才能与前端团队就一组功能达成一致。然后，前端团队将要求后端团队自行开发和发布功能。后端团队将与数据所有者合作发布数据库架构更新。接下来，后端团队将发布新版本的 API，以便前端团队可以开发和发布他们的更改。在这种情况下，将所有更改传播到生产环境可能需要数周甚至数月的时间，因为每个团队在开发、测试和发布更改方面都有自己的待办事项、优先事项和机制。
## 微服务
在微服务架构中，后端被分解为小型服务，每个服务都在有限的环境中解决特定的业务问题。通过公开明确定义的接口合约，每个微服务还与其他服务实现了高度的分离。
值得一提的是，有限的上下文和接口合约也应该存在于精心制作的巨体和 n 层架构中。但是，在微服务架构中，通信通过网络（通常是 HTTP 协议）进行，并且服务具有专用的运行时基础架构。这支持每项后端服务的独立开发、交付和操作。
## 根据您的要求选择方法
Monoliths 和 n 层架构将多个领域问题捆绑到一个技术工件中。这使得依赖关系和内部数据流等方面易于管理，但却使新功能的交付变得更加困难。为了维护连贯的代码库，团队经常在重构和解耦上投入时间，因为他们必须处理庞大的代码库。
由几个团队开发的应用程序可能不需要迁移到微前端所带来的额外复杂性。如果团队没有为发布变更付出高耦合度和长交货时间的罚款，则尤其如此。
总而言之，对于复杂且快速发展的应用程序，更复杂的分布式架构通常是正确的选择。对于中小型应用程序，分布式架构不一定优于单片架构，尤其是在应用程序不会在短时间内显著演变的情况下。