在当前以人工智能为基础的数字化转型浪潮中，私有云IaaS软件扮演着越来越重要的角色。作为用户与复杂后端系统交互的桥梁，前端在私有云软件中占据了至关重要的位置。一个高效、可靠且易于使用的前端不仅能提升用户体验，还能显著提高工作效率，减少操作错误，并最大化私有云作为智能计算基础架构的价值。随着技术的快速发展，保持前端架构的现代化和高性能尤为重要。本文将详细说明我们如何探索由ZStack AIOS支持的渐进式前端架构升级解决方案，以满足日益增长的业务需求和技术挑战，从而为用户提供更出色的私有云软件体验。
当前挑战
开发体验差
我们的前端项目始于2019年，核心基于Umi 3和Qiankun的微前端架构。将主应用和子应用分开的理念可以大大缓解原始3.x版本的单体应用在开发中的热更新慢和打包时间长的问题。然而，随着业务的不断迭代，每个子应用都从一棵小树苗成长为参天大树。现在平均启动一个子应用的时间约为50秒+，热更新时间有时甚至需要20秒，这无疑是一个糟糕的开发体验。
打包速度慢
目前，构建系统中的流水线采用全量打包方法。平均一次完整的构建需要大约40分钟，非常漫长。相比之下，后端构建时间仅为20分钟左右。毫无疑问，构建速度存在显著的性能问题。
持续集成困难
Umi采用了硬编码所有依赖包版本的解决方案。这当然可以确保开发期间的稳定性，并确保项目能够快速交付，但不利于持续的产品打磨。因此，当我们的团队想要引入新技术或行业新解决方案时，我们需要考虑Umi的兼容性，有时甚至需要实现一些我们自己的插件。例如，Umi硬编码了React版本16，因此我们很难使用18的新特性；Umi硬编码的PostCSS 7不支持最新版本的Tailwind CSS。同时，我们在开发初期采用了AntD作为我们的基础组件库，以确保开发的速度和效果。然而，由于业务侧的定制需求，大量AntD自己的样式被覆盖，导致AntD版本也需要锁定。一旦升级，将对整个平台的样式产生很大的负面影响。
旧工具链
我们采用了基于yarn workspace的Monorepo开发模型。由于没有依赖缓存，项目需要在启动前完全本地构建依赖库，大约需要2分钟，浪费了大量的开发时间。Webpack 4也是一个相对较旧的版本。ESLint等Lint工具也存在一定的性能问题，这也在一定程度上拖慢了开发体验。
总结来说，我们当前的架构在2019年看似先进，但随着业务的不断迭代，带来了一系列问题。这些挑战不仅影响了开发团队的工作效率，也限制了产品的技术创新和性能优化。因此，迫切需要升级和优化前端架构，以提高开发效率，改善用户体验，并为未来的技术演进奠定基础。
我们做了什么
在分析了上述问题后，我们发现需要更新架构。为了解决上述问题，我们不可避免地需要解决Umi自身带来的问题。因此有两个解决方案。一个是尝试升级Umi 4，另一个是剥离Umi，尝试社区中其他优秀的架构解决方案。我们将尝试两条路线，并选择能够更快通过的那一个。
尝试升级Umi 4
Umi4将默认的React版本升级到18，React Router从v5升级到v6，并提供了对Mako的支持，这是一个用Rust编写的打包工具。理论上，它可以解决启动慢、热更新慢和打包慢的三个问题。因此，我选择了一个功能较少的子应用尝试升级。根据官方迁移教程，我们逐一进行更改。
升级依赖
这一步非常简单，只需修改umi的依赖版本。
升级插件
经过我们的研究，我们发现Umi 4的API与Umi 3插件的API非常不兼容。不幸的是，我们项目中的一些插件是基于Umi 3的API编写的，这意味着这些插件必须重写。我们先跳过这一步。只要项目能够运行，应该可以在Zhita AIOS的帮助下简单地重写插件。
修改配置
然后噩梦来临了。当我们尝试运行它时，报告了一系列非常奇怪的错误。原因很简单，也在官方文档中提到了。我们的配置和Umi 4之间一定有不兼容的地方。然后我们只能逐个检查配置项。然而，问题越来越多。我们更改的配置越多，运行项目就越困难。在花费了大约3个人日后，我们发现这件事可能是一个时间黑洞，没有胜利的希望。也许更可靠的解决方案是基于Umi 4从头开始一个新项目，然后慢慢将业务代码迁移过去。在进度的这一点上，我们决定暂时将其搁置，看看其他路线是否可行。
新解决方案
开源社区中有很多优秀的全栈框架，如Next.js、Remix等。打包工具行业的新来者包括Vite和RsBuild。因为我们需要考虑逐步升级的问题，单次修改的量越小越好。毕竟，一次性重新开始单体项目是不可能的。因此，当我们
