如何在从单片架构到微服务架构的过渡之间管理多个登台环境

我的公司最近着手将平台架构从单片架构更改为微服务架构。整个迁移可能要花费数年，所以到现在为止，我们仍然需要维护当前的整体应用程序，同时缓慢地拆除该应用程序。

我们暂时通过面向服务的体系结构为某个模块（其中数据库仍连接到单体应用程序的数据库）拆除了单体应用程序，而另一些则直接过渡到微服务（如果适用，微服务拥有自己的数据库）。

我们会随时准备发布功能，而不是遵循发布窗口。每个团队都有自己的阶段来管理该阶段，因此我们有多个阶段环境（总共11个），每个阶段都有自己的一组遗留的整体应用程序。

在过渡到微服务架构时（虽然我了解到，当我们完全过渡到微服务架构时，整个公司只有1个阶段），我们将需要维护所有这些阶段，这意味着我们将需要拥有一个阶段的副本。每个登台环境中的微服务。

（并不是要在此解决方案的方向上指导答案。如果在其他方向上有任何答案，则更可取，因为我们可以有更多选择和变化来考虑利弊），我们的想法之一是针对每个问题在db中，我们还有另外一列来标记此数据行用于哪个阶段。因此，我们可以维护1个微服务的单个实例以进行多个阶段。问题在于，对于每个API调用，客户端都需要指定用于哪个阶段。这使每个服务的开发变得复杂（需要满足要筛选的登台数据库的需求），使端点更难以调用（因为您需要指定需要访问的登台数据库）），更重要的是，这些是多余的代码，这些代码在生产中应该没有。

我们面临的问题是，随着微服务数量的增长，这将占用大量服务器资源（我们决定使用本地服务器来托管我们的kubernetes和Proxmox VM来保留传统的整体组件）。是否有任何基础架构可以减少为此所需的资源？