docker-compose - 本地开发微服务、方法和工具以高效工作

Question

我与团队成员一起开发微服务架构，但我的工作方式有问题。事实上，我有太多的微服务，当我在开发过程中运行它们时，即使有一个好的工作站，它也会消耗太多的内存。所以我使用 docker compose 来构建和执行我的 MSA，但这需要很长时间。人们经常听说如何在技术上构建 MSA，但从未听说过如何有效地构建它。在这种情况下你怎么办？你如何工作的 ？您是否使用工具或任何其他工具来改进和促进您的发展。我听说过 skaffold，但我看不出与 docker compose 或集群环境中的简单 ci/cd 有什么区别。随时提供提示和您的意见。谢谢

标签： docker-composemicroservicesdocker-swarmdevelopment-environmentskaffold

Answer 1

我在微服务和本地开发方面有相当多的经验，这里有一些我见过的方法：

1. 在 docker 或 k8 上本地运行所有东西。如果使用 k8，那么像 skaffolding 这样的工具可以更轻松地在 IDE 中本地运行和调试服务，但将其放入本地 k8 中，以便它可以与其他 k8 服务通信。它工作正常，但在 k8 或 docker 本地运行超过 4 或 5 个完整服务需要专用大量 CPU 和内存。
2. 构建所有服务的模拟版本。在本地和集成测试中使用它们。模拟服务故意更简单，因此更容易在本地运行大量服务。明显的缺点是您必须构建每个服务的模拟版本，并且您很容易错过由模拟服务的行为与真实服务不同引起的错误。像 Hoveryfly 这样的记录/回放工具可以帮助构建模拟服务。
3. 为每个开发人员提供自己的云环境。在云中运行大多数服务，但使用Telepresence之类的工具将本地运行的服务交换进出云集群。这消除了在单台机器上运行过多服务的问题，但为每个开发人员维护单独的云沙箱可能会很花钱。您还需要一个 DevOps 资源来帮助开发人员在他们的云沙箱出现问题时提供帮助。
4. 消除不必要的微服务复杂性并将所有服务整合到 1 或 2 个单体中。享受能够将所有内容作为一项服务在本地运行。接受这样一个事实，即微服务架构对大多数公司来说都是多余的。太多的人在需要之前就选择了微服务架构。或者他们这样做是因为担心他们将来会需要它。这不可避免地会导致人们猜测他们应该如何将系统分解为许多微服务，并弄错边界和合约，这使得与单体架构相比，未来修复起来同样困难或更难。而且他们在需要之前几年就已经承担了微服务的成本。从本地开发到部署，微服务让一切变得更加昂贵和痛苦。对于像 Netflix 和亚马逊这样的公司来说，这是必要的。

如果可能的话，我更喜欢选项 4。否则按该顺序选择选项 2 或 3。我认为应该避免选项 1，但它可能是每个人都首先尝试的选项。