我的公司最近开始了从单体架构到微服务架构的平台架构转变。整个迁移可能需要数年时间，因此到目前为止，我们仍然需要维护当前的单体应用程序，同时缓慢地拆除应用程序。
我们通过面向服务的架构临时为某些模块(其中数据库仍然连接到单体应用程序的数据库)拆除单体应用程序，而我们直接过渡到微服务(如果适用，微服务拥有自己的数据库)。
我们会在功能准备就绪时练习发布功能，而不是遵循发布窗口。每个团队都有自己的 staging 来管理这个，因此我们有多个 staging 环境(总共 11 个)，每个环境都有自己的一组遗留单体应用程序。
在过渡到微服务架构时(虽然我知道当我们完全过渡到微服务架构时，整个公司只会有 1 个阶段)，我们需要维护所有这些阶段，这意味着我们需要拥有一份每个暂存环境中的微服务。
(并不是要指导这个解决方案的方向的答案。如果有任何不同方向的答案最好，这样我们就可以有更多的选择和变化来考虑利弊)我们的想法之一是，对于每个 db，我们有一个额外的列来标记这行数据的暂存位置。因此，我们可以为多个阶段维护 1 个微服务实例。问题是对于每个 API 调用，客户端都需要指定它用于哪个阶段。它使每个服务的开发变得复杂(需要满足要过滤掉哪个暂存数据库)，使端点更难调用(因为您需要指定您需要访问哪个暂存数据库)，更重要的是这些是冗余代码不应该在生产中。
我们面临的问题是随着微服务数量的增长，这将占用大量服务器资源(我们决定使用本地服务器来托管我们的 kubernetes 和 Proxmox VM 以用于遗留单体)。是否有任何基础架构可以减少此 所需的资源？ ?
最佳答案
您可以通过为每个微服务保留相对较少的内存和 cpu 来使微服务的服务质量可突增。然后，您可以过度使用您的节点并依赖于并非所有暂存区域都需要同时以最佳性能运行的假设。
如果许多或所有微服务共享相同的数据库版本，也许您可以将它们托管在单个高可用性数据库部署上的单独数据库模式中，从而减少资源占用。
当然，这取决于暂存环境的计划使用情况。如果所有团队同时完成 sprint 演示，则集群可能会在此之前的高峰时间重载。
关于architecture - 如何在从单体架构过渡到微服务架构之间管理多个暂存环境，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54837671/