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

Question

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

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

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

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

（不是要在此解决方案的方向上指导答案。最好是在不同方向上有任何答案，以便我们可以有更多选择和变化来考虑优缺点）< / em> 我们的想法之一是，对于每个数据库，我们都有一个附加列来标记此数据行用于哪个分段。因此，我们可以维护1个微服务的单个实例以进行多个阶段。问题在于，对于每个API调用，客户端都需要指定用于哪个阶段。这会使每个服务的开发变得复杂（来满足要筛选出哪个登台数据库的需要），使端点难以调用（，因为您需要指定需要访问的登台数据库< / em>），更重要的是，这些是多余的代码，应该不会在生产中出现。

我们面临的问题是，随着微服务数量的增长，这将占用大量服务器资源（我们决定在内部服务器上托管我们的kubernetes和Proxmox VM，以用于传统的整体式服务器< / em>）。是否有任何基础架构可以减少为此所需的资源？

Answer 1

通过为每个微服务保留相对少量的内存和cpu，可以使微服务的服务质量可突发。然后，您可以过度使用节点，并假设并非所有登台区域都需要同时以最高性能运行。

如果许多或所有微服务共享同一数据库版本，也许您可​​以在一个高可用性数据库部署中将它们托管在单独的数据库架构中，从而减少资源占用。

当然，这取决于暂存环境的计划使用情况。如果所有团队都在同一时间结束了sprint演示，则群集可能会在此之前的高峰时段过载。

Answer 2

我不完全理解您可能会遇到的所有可能的细节，但以下几点要点：

• 通过遵循诸如Strangler模式之类的方法迁移到新的微服务体系结构时，您必须确定谁/何处是数据真相的来源（不必对所有数据都相同）。
• 对于不更改数据状态的微服务（MS）（例如，新的搜索微服务），通常我将数据从真相源（例如，整体的RDS表）流式传输到其他更灵活/对微服务友好的介质（在我们的案例中，我们选择了Apache Kafka，而该媒体就是Kafka主题）。 MS从主题中读取事件并创建其内部世界视图（即搜索示例将事件流式传输到Elastic Search）。
• 对于那些也会改变真相来源状态的MS来说，情况更为复杂。我认为一种好方法是在新的微服务环境中保持“真相来源”状态（例如，在表示订单的主题中累积事件），然后异步流回到整体DB。
• 不同的团队（专注于不同的新微服务）将拥有自己的主题。

Answer 3

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

现在，您可以混淆2个群集如何管理11个不同的登台环境。在Kubernetes环境中，可以使用不同的名称创建名称空间，并且可以隔离这些名称空间。因此，在1个Kubernetes集群中，您可以拥有更多的登台，测试或开发环境。

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

关于您的整体应用程序，您的方法是最好的方法，请慢慢拆除它。在数据库方面，如果可能的话，保留单片数据库并为微服务创建新的DB对将来会更好，因为您可以查看需求，并可能添加一些额外的字段以用于微服务的DB进行分析或度量。

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

Answer 4

如果我正确理解您的担忧，那么您打算为基于微服务的部署图中的每个六角形，矩形和DB节点使用专用服务器。

好消息是，您可以将每个服务放在同一个物理设备中，而无需太多操作开销，同时又可以充分利用硬件资源。 Docker个容器就是答案。您可以创建可以共享相同硬件资源的轻型微型容器。当然，您需要考虑多个方面，以确保您不会过度使用资源。 Here是一个很好的解释，说明了什么会影响可在Docker主机上运行的最大容器数。您还将获得许多其他好处，例如易于部署新版本，回滚到旧版本，超快速的开发环境设置等。

使用Kubernetes或DC/OS之类的容器编排系统，即使在生产中，Docker部署也越来越普遍。