本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
服务发现
在开发、测试和交付微前端时，前端发现模式可以改善开发体验。该模式使用描述微前端入口点的可共享配置。可共享配置还包括其他元数据，这些元数据用于使用金丝雀版本在每个环境中进行安全部署。
现代前端开发需要在开发过程中使用各种各样的工具和库来支持模块化。传统上，此过程包括将代码捆绑到可以托管在 CDN 中的单个文件中，目标是在运行时将网络调用保持在最低限度，包括初始加载（当应用程序在浏览器中打开时）和使用情况（当客户执行诸如选择按钮或插入信息之类的操作时）。
拆分捆绑包
Micro-Frontend 架构解决了由于单独捆绑大量功能而生成的非常大的捆绑包所导致的性能问题。例如，可以将一个非常大的电子商务网站捆绑成一个 6 MB 的 JavaScript 文件。尽管进行了压缩，但该文件的大小可能会对用户加载应用程序和从边缘优化的 CDN 下载文件时的体验产生负面影响。
如果您将应用程序拆分为主页、产品详情和购物车微前端，则可以使用捆绑机制生成三个单独的 2 MB 捆绑包。当用户使用主页时，此更改可能会将首次加载的性能提高 300%。只有当用户访问某件商品的产品页面并决定购买时，才会异步加载产品或购物车微前端捆绑包。
许多框架和库都基于这种方法可用，这对客户和开发人员都有好处。要识别可能导致代码中依赖关系解耦的业务边界，您可以将不同的业务职能映射到多个团队。分布式所有权引入了独立性和敏捷性。
拆分构建包时，您可以使用配置来映射微前端并驱动初始加载和加载后导航的编排。然后，可以在运行时而不是在构建期间使用该配置。例如，客户端前端代码或服务器端后端代码可以对 API 进行初始网络调用，以动态获取微前端列表。它还会获取合成和集成所需的元数据。您可以配置故障转移策略和缓存以提高可靠性和性能。映射微前端有助于使先前部署的微前端能够被先前部署的、由 shell 应用程序编排的微前端发现。
Canary 发布
金丝雀版本是一种成熟且流行的微服务部署模式。Canary 版本将版本的目标用户分为多个组，发布会逐渐进行更改，而不是立即替换（也称为蓝/绿部署）。金丝雀发布策略的一个例子是向10％的目标用户推出新的更改，每分钟增加10％，总持续时间为10分钟才能达到100％。
金丝雀版本的目标是尽早获得有关变更的反馈，监控系统以减少任何问题的影响。实现自动化后，可以由内部系统监控业务或系统指标，该系统可以停止部署或开始回滚。
例如，更改可能会引入一个错误，该错误在发布的最初几分钟内会导致收入损失或性能下降。自动监控可以启动警报。使用服务发现模式，该警报可以停止部署并立即回滚，仅影响20％的用户，而不是100％的用户。企业受益于问题范围的缩小。
有关使用 DynamoDB 作为存储来实现 REST 管理 API 的架构示例，请参阅 AWS 上的前端服务发现解决方案
