我对微服务和存储库有疑问。我们是一个小团队（5 人），我们在微服务中创建新项目。我们项目中预期的微服务应用程序在 10-15 个之间。
我们正在考虑为所有微服务建立一个存储库，其结构如下：
-/
--/app1
--/app2
--/app3
-./script.sh
-./script.bat
你觉得这个设计怎么样？你能推荐更好的东西吗？我们认为，如果我们为每个应用程序都有存储库，那么对于一个团队中的小项目来说就太过分了。作为我们的应用程序，您可以想象 Angular 中的 Spring Boot 或 Spa 应用程序。谢谢你的建议。
一般来说，您可以将所有微服务放在一个存储库中，但我认为，虽然每个微服务的代码都在增长，但管理起来可能很困难。
在决定将所有微服务放入一个存储库之前，您可能需要考虑以下一些事项：
-
开发者纪律:
小心代码的耦合。由于所有微服务的代码都在一个存储库中，因此它们之间没有真正的物理边界，因此开发人员只需使用其他微服务中的一些代码，例如添加引用或类似的代码。将所有微服务放在一个存储库中将需要一些纪律和规则，以防止开发人员跨越边界和滥用它们。
-
受到创建和滥用共享代码的诱惑。如果您以正确且结构化的方式进行操作，这并不是一件坏事。这又为错误的做法留下了很大的空间。如果人们刚开始使用相同的共享罐子或类似的罐子，可能会导致很多问题。为了共享某些内容，应该将其隔离和打包，并且理想情况下应该具有一些支持向后兼容性的版本控制。这样，当该库更新时，每个微服务仍将具有先前版本的工作代码。在同一个存储库中仍然是可行的，但与上面的 1 点一样，它需要规划和管理。
-
Git 注意事项:
在一个存储库中管理大量拉取请求和分支可能具有挑战性，并可能导致以下情况：“我被其他人阻止了”。此外，可能会有更多的人参与该项目并提交到您的源分支，您将必须更频繁地进行变基和/或合并源分支到您的开发或功能分支（即使您不需要来自其他服务）。为存储库配置的电子邮件通知可能非常烦人，因为您将收到微服务代码中未包含的内容的电子邮件。在这种情况下，您需要在电子邮件客户端中创建一些过滤器/规则，以避免您不感兴趣的电子邮件。
-
微服务的数量比最初的 10-15 个增长得更多。数量还能增长吗？如果没有，一切都好。但如果确实如此，在某些时候您可能会考虑将每个微服务拆分到专用存储库中。在项目的后期阶段执行此操作可能具有挑战性，并且可能需要一些工作，在最坏的情况下，您会发现人们随着时间的推移产生了一些耦合，您必须在此阶段解决这些耦合。
-
CI 管道注意事项:
如果您使用 Jenkins 之类的工具来构建、测试和/或部署您的代码
您可能会遇到一些小的配置困难，例如 Jenkins 和 GitHub 之间的集成。您需要配置一个管道，如果有人针对该微服务创建合并/拉取请求，则该管道仅构建/测试代码的特定部分（或一个微服务）。我从未尝试过做这样的事情，但我想你必须弄清楚如何做到这一点（编写脚本并使其自动化）。我想这是可行的，但需要一些工作才能实现。
结论
尽管如此，所有或大部分问题都可以通过一些额外的管理和配置来解决，但仍然值得了解您可能会遇到哪些额外的工作。我想还需要考虑其他一些问题，但我的一般建议是，如果可以的话，为每个微服务使用单独的存储库（私有存储库定价和类似原因）。这是一个逐个项目做出的决定。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
