本地开发微服务、方法和工具以有效工作

Question

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

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，但这可能是每个人都首先尝试的选项。