vlambda博客
学习文章列表

团队在去年使用微前端架构重新构建了一个门户站点。通过引入微前端架构，解决了单体架构下、多团队协作所产生的相互影响，相互依赖的问题，使得团队更大程度的获得了自治权。本文选取业务模型，技术实践，服务资产管理三个视角，通过分析项目迭代开发存在的问题，尝试说明原有单体架构下的痛点，以及引入微前端如何解决痛点问题，从而改善各个团队工作方式。最后，我们将总结分享在对门户站点进行微前端改造过程中所汲取到的经验和教训。

早前，团队构建了一个一站式门户站点，需要集成多个系统，包括：订单系统，偏好推荐系统，产品系统等；历时半年，选择React & Redux作为前端开发框架和工具，使用Kotlin作为BFF开发语言，以单体应用的形式，团队将该门户站点发布到AWS中投入使用。此后的几个月，随着交付更迭，随着越来越多团队加入，我们遇到了一些团队协作的问题。业务模型 - 交付计划相互影响和高额的沟通成本以订单，偏好推荐和产品为例，下图描述了该站点上各个团队的业务模型：由图中灰框可知，项目分为前后端两部分：前端和相应的BFF，多个团队在相同的代码仓库中共享代码，共享环境，协同开发。这种模型存在的问题是：当某团队的一次更新影响范围较广时，很可能会影响到其他团队开发计划、发布计划。对于PM / BA而言，多团队协作项目中不必要的耦合会使交付变得不安全且不可预测。一个功能的诞生，从探索，评估，计划，到最终交付，需要跨团队大量沟通，包括业务之间的相互影响，技术决策，交付计划。为了使所有团队尽可能按计划交付，我们不得不增加协调成本并提前计划。不幸的是，通常问题不会在这一过程开始时发生，而是直到过程后期才被发现。它就像一枚复杂的炸弹，使估算无效，降低交付的稳定性和可预测性。技术实践 - 强制遵循相同的实践和技术栈下图展示技术实践具体情况：通过上图我们看出，多个贡献者团队以及一个管理团队共享代码库，共享流水线，共享环境。而作为一个交付团队，因为共享，不得不接受不熟悉的技术栈；被迫接受更多流水线运行时间以通过所有团队的测试用例；因为业务关联而被迫相互学习业务知识。而相互独立的代码库、熟悉的技术栈，轻量便捷的规范准则、合理而高效的流程，才是一个交付团队持续不断追求的理想状态。服务资产管理 - 框架或依赖升级带来的影响从服务、资产的角度来讲，受限于技术架构与实践，多个团队共用相同的工件与产品环境。为了能够让每一个团队都能正常工作，大家被迫妥协、接受满足所有团队的管理流程。而实际上各个团队产品迭代发布都是对工件和生产环境的更新，这种更新需要整体回归测试的保证。甚至线上产品事故支持时，我们需要解决当站点产生的事故，如何将错误准确导向特定的开发团队的问题。所有团队经过多次取舍与妥协后，失去了应有的自治权。一个重前端的项目中，整体式架构、多团队协作开发的模式为我们带来的思考是：业务如何做到独立交付？如何做到自主技术决策？如何保障团队对服务、产品的绝对控制权？微前端架构很好的回答了以上三个问题。

• 团队工作在基于业务领域划分的端到端项目，这使我们的交付更加稳定和可预测：团队可以更加关注领域内业务价值的实现以及对项目的迭代更新。业务迭代更新取决于团队自身。

• 能够充分进行自主技术决策，维护小而聚合的代码库及相关基础设施：团队拥有完全自主的决定权，定制更灵活地，符合团队自身和工作内容的技术实践。

• 独立进行测试与部署：更新、升级的影响范围被控制在每一个Micro App中，各团队只需负责开发、维护自己的Micro App即可。

此外，而上文提到的import-map组件，本质上是一种动态加载JS的机制实现，这种机制为吸引更多人、更多团队、乃至第三方成为所构建平台的贡献者提供了可能。

微前端架构给团队带来了极大的自治权，团队在领域内、在自己维护的Micro App中获得了极大的自主权，可以更加灵活的选择更合适的方式解决实际的业务问题。在认清这些红利外，微前端并不能解决所有问题，这种架构实践并非没有代价，主要表现在引入的性能问题，要求较高的DevOps以及管理复杂度。对此我们需要引入其他技术手段克服：

• 性能：引入微前端框架，浏览器加载页面时需要最先加载微前端框架代码，而后加载各个组件和MFA，这无疑加重了浏览器的加载负担。为了减少页面加载时间，一方面需要借助工件最小化，Tree shaking，以及在Cloudfront & 浏览器等层面上的缓存等手段加快每一个JS脚本文件的加载速度；另一方面需要在确保功能完整的情况下，尽可能提高JS脚本并行加载能力。

• DevOps：微前端架构实践对团队CD能力也有要求。可以说与CD实践相辅相成。通过流水线保持Micro App引用最新，这需要较高的自动化要求和高度Infrastructure as Code实践。而为了高度的自动化，也需要足够有信心的测试覆盖，如此才能保持业务的持续交付，持续集成。

• 管理复杂度：多个不同的Micro App组件同时加载，通过命名规范可以解决潜在的CSS/JS冲突问题；由于UI在前端被分割成了一个个边界清晰的Micro App，我们需要一定的设计规范，保持跨Micro App的设计一致性，如统一的配色样式，风格接近的操作方式，行为一致的错误处理等。我们相信，再追求高度自治的情况下，并不能以牺牲流畅统一的用户体验为前提。