本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 了解和实现微前端 AWS
<a name="introduction"></a>

*Amazon Web Services*（[贡献者](contributors.md)）

*2024 年 7 月*（[文档历史记录](doc-history.md)）

随着组织追求敏捷性和可扩展性，传统的整体架构往往成为瓶颈，阻碍了快速开发和部署。Micro-Frontends 通过将复杂的用户界面分解为可以自主开发、测试和部署的更小、独立的组件来缓解这种情况。这种方法提高了开发团队的效率，促进了后端和前端之间的协作，从而促进了分布式系统的 end-to-end协调。

本规范性指南专为帮助不同专业领域的 IT 负责人、产品负责人和架构师了解微前端架构和在 Amazon Web Services 上构建微前端应用程序 () 而量身定制。AWS

## 概述
<a name="overview"></a>

微前端是一种架构，其基础是将应用程序前端分解为独立开发和部署的工件。当您将大型前端拆分为自主软件工件时，您可以封装业务逻辑并减少依赖关系。这支持更快、更频繁地交付产品增量。

*微前端与微服务类似。*实际上，微前端一词源自微服务一词，它旨在传达微服务作为前端的概念。虽然微服务架构通常将后端的分布式系统与单片前端结合在一起，但微前端是独立的分布式前端服务。可以通过两种方式设置这些服务：
+ 仅限前端，与在后面运行微服务架构的共享 API 层集成
+ 全栈，这意味着每个微前端都有自己的后端实现。

下图显示了传统的微服务架构，其前端整体结构使用 API 网关连接到后端微服务。



![连接到服务器端微服务的客户端前端单体。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/micro-frontends-aws/images/traditional-webarch.png)


下图显示了具有不同微服务实现方式的微前端架构。



![客户端集成层前端模块和服务器端微服务。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/micro-frontends-aws/images/mfe-architectures.png)


如上图所示，您可以将微前端与客户端渲染或服务器端渲染架构配合使用：
+ 客户端渲染的微前端可以直接使用集中式 API Gateway APIs 公开的内容。
+ 团队可以在有界的上下文中创建一个 backend-for-frontend（BFF），以减少前端朝向的闲聊感。 APIs
+ 在服务器端，微前端可以通过使用一种叫做水化的技术在客户端增强服务器端的方法来表达。当浏览器渲染页面时，关联的页面会 JavaScript 被水合以允许与用户界面元素进行交互，例如单击按钮。
+ 微前端可以在后端进行渲染，并使用超链接路由到网站的新部分。

微前端非常适合想要执行以下操作的组织：
+ 通过多个团队在同一个项目上进行扩展。
+ 拥抱决策的去中心化，使开发人员能够在已确定的系统边界内进行创新。

这种方法大大减轻了团队的认知负担，因为他们负责系统的特定部分。它提高了业务灵活性，因为可以在不中断其余部分的情况下对系统的一部分进行修改。

微前端是一种独特的架构方法。尽管有不同的方法可以构建微前端，但它们都有共同的特征：
+ 微前端架构由多个独立元素组成。其结构类似于后端微服务所采用的模块化。
+ 微前端完全负责前端在其有限环境中的实现，其中包括以下内容：
  + 用户界面
  + 数据
  + 状态或会话
  + 业务逻辑
  + 流

有界上下文是一个内部一致的系统，其边界经过精心设计，可以调解可以进入和退出的内容。微前端应尽可能少地与其他微前端共享业务逻辑和数据。无论何时需要共享，都通过明确定义的接口（例如自定义事件或响应式流）进行。但是，当涉及到一些跨领域问题（例如设计系统或日志库）时，欢迎有意共享。

推荐的模式是使用跨职能团队来构建微前端。这意味着每个微前端都是由从后端到前端工作的同一个团队开发的。从编码到系统在生产中的运营，团队所有权至关重要。

本指南无意推荐一种特定的方法。相反，它讨论了不同的模式、最佳实践、权衡取舍，以及架构和组织方面的考虑因素。