一个存储库中的多个微服务

Question

我对微服务和存储库有疑问。我们是一个小团队（5 人），我们在微服务中创建新项目。我们项目中预期的微服务应用在 10-15 之间。

我们正在考虑为所有微服务建立一个存储库，其结构如下：

-/
--/app1
--/app2
--/app3
-./script.sh
-./script.bat

你觉得这个设计怎么样？你能推荐一些更好的吗？我们认为，如果每个应用程序都有存储库，那么对于一个团队中的小项目来说，这将是矫枉过正。作为我们的应用程序，您可以想象有角度的 spring boot 或 spa 应用程序。谢谢指教。

Answer 1

一般而言，您可以将所有微服务放在一个存储库中，但我认为随着每个微服务的代码不断增长，管理起来可能很困难。

在决定将所有微服务放在一个存储库中之前，您可能需要考虑以下一些事项：

1. 开发人员纪律：小心代码耦合。由于所有微服务的代码都在一个存储库中，因此它们之间没有真正的物理边界，因此开发人员可以仅使用其他微服务中的一些代码，例如添加引用或类似内容。将所有微服务放在一个存储库中需要一些纪律和规则，以便开发人员不要跨越边界和滥用它们。

2. 受到创建和滥用共享代码的诱惑。 如果您以适当且结构化的方式进行操作，这并不是一件坏事。同样，这为以错误的方式进行操作留下了很大的空间。如果人们只是开始使用相同的共享 jar 或类似的东西，那可能会导致很多问题。为了共享一些东西，它应该被隔离和打包，理想情况下应该有一些支持向后兼容性的版本控制。这样，当此库更新时，每个微服务仍将具有与先前版本相同的工作代码。它仍然可以在同一个存储库中使用，但与上面的 1. 点一样，它需要规划和管理。

3. Git 注意事项：在一个存储库中管理大量拉取请求和分支可能具有挑战性，并可能导致以下情况：“我被其他人阻止了”。此外，由于可能会有更多人参与该项目并提交到您的源分支，您将不得不更频繁地执行 rebase 和/或合并源分支到您的开发或功能分支（即使您不需要从其他服务）。为存储库配置的电子邮件通知可能非常烦人，因为您将收到有关不在您的微服务代码中的内容的电子邮件。在这种情况下，您需要在您的电子邮件客户端中创建一些过滤器/规则，以避免您不感兴趣的电子邮件。

4. 微服务的数量比最初的 10-15 增长得更多。能增长多少？如果不是一切都很好，但如果在某个时候确实如此，您可能会考虑将每个微服务拆分到一个专用存储库中。在您处于项目后期阶段时执行此操作可能具有挑战性，并且可能需要一些工作，在最坏的情况下，您会发现人们随着时间的推移产生了一些耦合，您必须在此阶段解决这些耦合。

5. CI 管道注意事项：如果您使用 Jenkins 之类的东西来构建、测试和/或部署您的代码，您可能会遇到一些小的配置困难，例如 Jenkins 和 Github 之间的集成。如果有人针对该微服务创建合并/拉取请求，您将需要配置一个管道，该管道只会构建/测试代码的特定部分（或一个微服务）。我从来没有尝试过做这样的事情，但我想你必须弄清楚如何去做（脚本和自动化）。我想这是可行的，但需要一些工作才能实现。

结论

仍然可以通过一些额外的管理和配置来解决所有或大部分问题，但仍然值得了解您可能会遇到的额外工作。我想还有一些其他要点需要考虑，但我的一般建议是如果可以的话，为每个微服务使用单独的存储库（私有存储库定价和类似原因）。这是一个项目一个项目做出的决定。希望这篇笔记对你有帮助:)