在自治与协调之间取得平衡

微前端架构强烈偏向于团队自主权。但是，重要的是要区分能够支持灵活性和多种方法来解决问题的领域，以及需要标准化才能实现一致的领域。高级领导和架构师必须尽早确定这些领域并确定投资的优先顺序，以平衡微前端的安全性、性能、卓越运营和可靠性。找到这种平衡涉及以下方面：微前端的创建、测试、发布和记录、监控和警报。

创建微前端

理想情况下，所有团队都要紧密合作，以最大限度地提高最终用户性能。实际上，这可能很难，而且可能需要付出更多的努力。我们建议从一些书面指导方针开始，多个团队可以通过公开透明的辩论为之做出贡献。然后，团队可以逐步采用 Cookiecutter 软件模式，该模式支持创建工具，为项目搭建提供统一的脚手架方式。

使用这种方法，你可以提出意见和约束。缺点是，这些工具需要大量投资来创建和维护，并确保在不影响开发人员工作效率的情况下快速解决障碍。

End-to-end 测试微前端

单元测试可以留给所有者。我们建议尽早实施策略，对在独特 shell 上运行的微前端进行交叉测试。该策略包括能够在生产版本之前和之后测试应用程序。我们建议为技术和非技术人员开发流程和文档，以便他们手动测试关键功能。

重要的是要确保更改不会降低功能性或非功能性的客户体验。理想的策略是逐步投资于自动测试，包括关键功能和安全性和性能等架构特征。

发布微前端

每个团队可能都有自己的方式来部署代码、发表意见和自己的基础架构。维护此类系统的复杂性通常会起到威慑作用。相反，我们建议尽早进行投资，以实施可通过共享工具强制执行的共享策略。

使用所选的 CI/CD 平台开发模板。然后，团队可以使用预先批准的模板和共享基础架构来发布对生产环境的更改。您可以尽早开始投资这项开发工作，因为经过最初的测试和整合后，这些系统很少需要重大更新。

日志记录和监控

每个团队可以有不同的业务和系统指标，他们想要跟踪这些指标以用于运营或分析目的。Cookiecutter 软件模式也可以在这里应用。事件的交付可以抽象出来，并作为一个库提供，供多个微前端使用。为了平衡灵活性和提供自主权，请开发用于记录自定义指标和创建自定义仪表板或报告的工具。该报告促进了与产品负责人的密切合作，减少了最终客户的反馈循环。

通过标准化交付，多个团队可以协作跟踪指标。例如，电子商务网站可以跟踪用户旅程，从 “产品详情” 微前端到 “购物车” 微前端，再到 “购买” 微前端，以衡量参与度、流失率和问题。如果每个微前端都使用单个库来记录事件，则可以整体使用这些数据，对其进行全面探索，并确定有洞察力的趋势。

警报

与日志和监控类似，警报也受益于标准化以及一定程度的灵活性。不同的团队对功能警报和非功能警报的反应可能有所不同。但是，如果所有团队都有一种统一的方法来根据在共享平台上收集和分析的指标来启动警报，那么企业就可以识别跨团队的问题。此功能在事件管理事件期间非常有用。例如，可以通过以下方式启动警报：

• 特定浏览器版本的 JavaScript 客户端异常数量增加

• 在给定阈值内，渲染时间明显降低

• 使用特定 API 时增加了 5xx 状态码的数量

根据系统的成熟度，您可以平衡基础架构不同部分的工作，如下表所示。

收养	研究和开发	Ascent	成熟度
创建微前端。	实验、记录和分享学习成果。	投资购买工具来搭建新的微前端。宣传收养。	整合脚手架工具。推动采用。
端到端测试微前端。	实现手动测试所有相关微前端的机制。	投资购买用于自动安全和性能测试的工具。调查功能标志和服务发现。	整合用于服务发现、生产环境测试和自动 end-to-end测试的工具。
发布微前端。	投资共享的 CI/CD 基础架构和自动化的多环境发布。宣传收养。	整合 CI/CD 基础架构的工具实施手动回滚机制。推动采用。	创建机制，根据系统和业务指标及警报启动自动回滚。
观察微前端性能。	投资共享的监控基础设施和库，以实现系统和业务事件的持续记录。	整合用于监控和警报的工具。实施跨团队仪表板，以监控总体运行状况并改善事件管理。	标准化日志架构。针对成本进行优化。根据复杂的业务指标实施警报。