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

Question

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

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

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

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

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

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

Answer 1

就您而言，本地 Kubernetes 可以成为您和您的团队的解决方案。
您可以为您的基础架构创建 2 个或更多集群。我的建议是至少2个集群。第一个用于开发、测试和登台，第二个用于生产环境。

现在您可能会混淆 2 个集群如何管理您的 11 个不同的临时环境。在 Kubernetes 环境中，您可以创建具有不同名称的命名空间，并且可以隔离这些命名空间。因此，在 1 个 Kubernetes 集群中，您可以拥有更多的暂存、测试或开发环境。

但坑洞很少，你需要担心。你可以搜一下，我可以给点建议。首先，始终有重新创建集群的备份计划。在一些非常不幸的情况下，一些硬件问题或网络情况，Kubernetes 无法连接到工作节点，在这种情况下，您应该准备在几分钟内从零开始创建集群。

关于你的单体应用，你的方法是最好的方法，慢慢拆解它。关于数据库方面，如果可能的话，保留整体数据库并为微服务创建新的数据库对未来会更好，因为您可以查看您的需求，并且可能添加一些额外的字段以用于微服务数据库的分析或指标。

在拆除单体应用程序之前，您甚至可以尝试使用 Istio 或 Linkerd 在单体应用程序和微服务之间导航流量。