如何管理从单片架构到微服务架构之间的多级环境

Question

我的公司最近开始了从单片架构到微服务架构的平台架构转变。整个迁移可能需要数年时间，所以到目前为止，我们仍然需要在缓慢地拆除应用程序的同时维护当前的整体应用程序。

对于某些模块（其中的数据库仍然连接到整体应用程序的数据库），我们通过面向服务的体系结构暂时拆除整体应用程序，而对于某些模块，我们直接转换到微服务（如果适用的话，微服务拥有自己的数据库）。

我们练习在特性准备就绪时发布它，而不是遵循发布窗口。每个团队都有自己的Staging来管理这一点，因此我们有多个Staging环境（总共11个），每个环境都有自己的一组遗留的整体应用程序。

（并不是要将答案引导到这个解决方案的方向上。如果有不同方向的答案，则更好，这样我们就可以有更多的选择和变化来考虑利弊）我们的一个想法是，对于每个db，我们有一个额外的列来标记这行数据是用于哪一个阶段的。因此，我们可以为多个分段维护微服务的单个html" target="_blank">实例。问题是，对于每个API调用，客户端都需要指定它是用于哪个阶段的。它使每个服务的开发变得复杂（需要满足筛选出哪个staging的数据库），使endpoint更难调用（因为您需要指定您需要访问哪个staging数据库），更重要的是，这些都是多余的代码，在生产中不应该存在。

我们面临的问题是，随着微服务数量的增加，这将占用大量的服务器资源（我们决定使用In premise server来承载我们的kubernetes和Proxmox VM作为遗留的整体）。是否有任何基础架构可以减少为此所需的资源？

Answer 1

您可以通过为每个微服务保留相对较低的内存和cpu来使微服务的服务质量稳定。然后，您可以过度提交节点，并依赖于这样的假设，即并非所有临时区域都需要同时以峰值性能运行。

如果许多或所有微服务共享相同的数据库版本，也许您可以将它们托管在单个高可用数据库部署上的单独数据库模式中，这也减少了资源占用。

当然，这取决于临时环境的计划使用情况。如果所有团队都在同一时间完成sprint演示，集群可能会在高峰时间过载。