语言 Chinese, Simplified

SEO Title

微服务架构的特点是独立服务，这些服务专注于特定的业务功能，并由小型、自包含的团队维护。微服务架构经常用于在 AWS 上开发的 Web 应用程序，这是有充分理由的。它们提供了许多众所周知的好处，例如开发敏捷性、技术自由、有针对性的部署等等。尽管微服务很受欢迎，但许多前端应用程序仍然以单体风格构建。例如，他们有一个与所有后端微服务交互的大型代码库，并由一大群开发人员维护。

Monolith Frontend

图 1. 带有单体前端的微服务后端

什么是微前端？

微前端架构将微服务开发原则引入前端应用程序。在微前端架构中，开发团队独立构建和部署“子”前端应用程序。这些应用程序由“父”前端应用程序组合而成，该前端应用程序充当容器来检索、显示和集成各种子应用程序。在此父/子模型中，用户与看似单个应用程序的交互。实际上，他们正在与由不同团队发布的多个独立应用程序进行交互。

Micro Frontend

图 2. 带有微前端的微服务后端

微前端的好处

与单体前端相比，微前端具有以下优势：

独立工件：微服务开发的核心原则是工件可以独立部署，这对于微前端仍然适用。在微前端架构中，团队应该能够独立部署他们的前端应用程序，而对其他服务的影响最小。这些更改将反映在父应用程序中。
自治团队：每个团队都是各自领域的专家。例如，计费服务团队成员具有专业知识。这包括与计费服务相关的数据模型、业务需求、API 调用和用户交互。与规模更大、专业性较低的团队相比，这些知识使团队能够更快地开发计费前端。
灵活的技术选择：自治允许每个团队做出独立于其他团队的技术选择。例如，计费服务团队可以使用 Vue.js 开发他们的微前端，而配置文件服务团队可以使用 Angular 开发他们的前端。
可扩展的开发：微前端开发团队更小，能够在不干扰其他团队的情况下进行操作。这使我们能够通过组建新团队以通过子应用程序提供额外的前端功能来快速扩展开发。
更容易维护：保持前端存储库小而专业，可以更容易地理解它们，这简化了长期维护和测试。例如，如果您想更改单体前端的交互，则必须在大型代码库的上下文中隔离功能的位置和依赖关系。在处理与微前端相关的较小代码库时，这种类型的操作会大大简化。

微前端挑战

相反，微前端提出了以下挑战：

父/子集成：微前端引入了确保父应用程序以与单体应用程序相同的一致性和性能显示子应用程序的任务。这一点将在下一节中进一步讨论。
运营开销：微前端应用程序不是管理单个前端应用程序，而是涉及为所有团队创建和管理单独的基础架构。
一致的用户体验：为了保持一致的用户体验，子应用程序必须使用相同的 UI 组件、CSS 库、交互、错误处理等。对于处于开发生命周期不同阶段的子应用程序，保持用户体验的一致性可能很困难。

构建微前端

微前端架构模式最困难的挑战是将子应用程序与父应用程序集成。优先考虑用户体验对于任何前端应用程序都至关重要。在微前端的上下文中，这意味着确保用户可以在父应用程序中从一个子应用程序无缝导航到另一个子应用程序。我们希望避免破坏性行为，例如页面刷新或多次登录。在最基本的定义中，父/子集成涉及父应用程序在加载父应用程序时动态检索和呈现子应用程序。渲染子应用程序取决于子应用程序的构建方式，这可以通过多种方式完成。两种最流行的父/子集成方法是：

将每个子应用程序构建为 Web 组件。

将每个子应用程序作为独立模块导入。这些模块要么声明一个函数来呈现自身，要么由父应用程序动态导入（例如使用模块联合）。

将子应用注册为 Web 组件：

<html>
    <head>
        <script src="https://shipping.example.com/shipping-service.js"></script>
        <script src="https://profile.example.com/profile-service.js"></script>
        <script src="https://billing.example.com/billing-service.js"></script>
        <title>Parent Application</title>
    </head>
    <body>
        <shipping-service />
        <profile-service />
        <billing-service />
    </body>
</html>

将子应用注册为模块：

<html>
    <head>
        <script src="https://shipping.example.com/shipping-service.js"></script>
        <script src="https://profile.example.com/profile-service.js"></script>
        <script src="https://billing.example.com/billing-service.js"></script>
     <title>Parent Application</title>
    </head>
    <body>
    </body>
    <script>
        // Load and render the child applications form their JS bundles.
    </script>
</html>

下图显示了一个基于 AWS 构建的示例微前端架构。

AWS Micro Frontend

Figure 3. Micro-frontend architecture on AWS

在此示例中，每个服务团队都在运行一个单独的、相同的堆栈来构建他们的应用程序。他们使用 AWS 开发人员工具并使用 Amazon CloudFront 将应用程序部署到 Amazon Simple Storage Service (S3)。 CI/CD 管道使用共享组件，例如 CSS 库、API 包装器或存储在 AWS CodeArtifact 中的自定义模块。这有助于提高父应用程序和子应用程序之间的一致性。

当您检索父应用程序时，它应该会提示您登录身份提供程序并检索 JWT。在此示例中，身份提供商是 Amazon Cognito 用户池。成功登录后，父应用程序从 CloudFront 检索子应用程序并将它们呈现在父应用程序中。或者，当您导航到特定路线时，父应用程序可以选择按需呈现子应用程序。子应用程序不应要求您再次登录到 Amazon Cognito 用户池。应将它们配置为使用父应用程序获取的 JWT，或者从 Amazon Cognito 静默检索新的 JWT。