前言 这篇是真的对口味。介绍了中后台平台化的探索和演进过程，以及团队在统一后台业务入口、降低维护成本方面的目标规划。通过微前端技术选型和实践，实现了统一后台入口、降低重复建设成本等目标，并解决了接口跨域等问题。最终建立了源宇宙工作台，实现了多个第一方和第二方后台的统一管理和使用。今日前端早读课文章由 @顾闻佳、@韩阳、@孟真分享，公号：哔哩哔哩技术授权。 正文从这开始～～ 公司在经过多年的发展，部门架构的演进，产生了大量的管理后台，包括运营平台、技术后台等。有持续迭代的，有年久失修的，也存在大量无人认领和维护的。 从技术层面看，大量的后台都存在基础能力缺失，或者重复建设，同时技术架构也各不相同。 在我们团队维护的后台里，很容易总结出如下共性问题，“技术栈不统一、规范不统一、重复建设” 背景分析 目前我们维护着 B 端大约 30 多个管理后台，累计超过 300 个模块和 1400 个页面，随着业务的不断融合，和新业务场景的加入，平台数量还在逐步上升中，从工作过程中我们看到了如下问题： 1 系统重复建设、迭代和维护成本高 这里的重复建设不仅是业务功能模块的重复建设，在开发每个后台系统时，还存在大量的基础建设的开发，比如常见的身份鉴权和操作日志，这些都是重复建设和存在重复维护的 2 相互独立，难以技术演进 由于每个后台系统存在于不同仓库开发和维护，无法实现统一的技术改造和通用能力建设 3 用户体验不统一，使用成本高 太多的后台入口，各种不同的权限申请流程，我们的日常工作需要在多个后台间切换来完成 目标规划 针对以上的问题，我们从 2021 年开始着手如何统一后台业务入口，降低部门内后台的维护成本。当时事业部内后台数量大约 10 个左右，但是已经可以预见到的是每个团队都在构建不同场景的后台项目，为了解决业务口径和资源效率问题，减少将要发生的历史债务，我们启动了中后台整合的微前端项目，并规划了以下几个技术目标： 所有后台入口统一，体验统一 统一平台基础能力，减少重复建设 对全部业务的可观测能力建设，了解业务资产和债务 整体设计 为了完成以上 3 个技术目标，我们开始了微前端的技术调研工作 关于微前端 目前，业界已经有许多微前端的解决方案，我们前期主要调研了比较流行的 qiankun 和 micro-app，这里简单分享下我们使用下来在体感上的区别 【第1929期】目标是最完善的微前端解决方案 – qiankun 2.0 qiankun – 基于 single-spa，但提供了更多开箱即用的 API 样式隔离： ShadowDOM ⚠️ 在开启后，实际体验比较差，子应用的原本样式 引用官方原话，” 基于 ShadowDOM 的严格样式隔离并不是一个可以无脑使用的方案，大部分情况下都需要接入应用做一些适配后才能正常在 ShadowDOM 中运行起来” 所以官方后期还提供了第二种解决方案，为子应用样式增加特殊的选择器 // 假设应用名是 react16 .app-main { font-size: 14px; } // 开启隔离后 div[data-qiankun-react16] .app-main { font-size: 14px; } 子应用接入成本： 高，要求子应用修改渲染逻辑并暴露生命周期，和对打包配置要进行一些修改 【第3086期】微前端框架MicroApp 1.0正式发布 micro-app – 将子应用封装成一个类 WebComponent 组件 样式隔离： CSS Module 兼容性高，我们的一方应用（团队内后台）和部分二方应用（其他团队后台）都能在开启样式隔离后无缝接入 <span style="color: #6a9955;">// 开启前</span> <span style="color: #d4d4d4;">.</span>ant<span style="color: #d4d4d4;">-</span>table table <span style="color: #d4d4d4;">{</span> <span style="color: #9cdcfe;">width</span> <span…