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

【问题标题】：Multiple microservices in one repository一个存储库中的多个微服务
【发布时间】：2020-03-05 07:16:46
【问题描述】：

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

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

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

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

【问题讨论】：

对于 Maven 项目，我会坚持以下规则：一个 Maven 项目，一个存储库。如果您的微服务是多模块项目的一部分，请将它们合二为一，否则使用单独的。
@JFMeier 如果只有 maven 项目，我们将使用多模块项目，如你所说，但是有 javascripts 应用程序，我猜这些不应该是 maven 项目
即使您决定在同一个 repo 中编写多个应用程序，也不要在应用程序表中使用外键关系。相反，每当您需要另一个应用程序的某个对象时，编写一个方法。将来，每当您决定将项目拆分为多个微服务时，您只需将此方法转换为 api 调用

标签： maven webpack architecture microservices

【解决方案1】：

一般来说，您可以将所有微服务放在一个存储库中，但我认为，虽然每个微服务的代码都在增长，但管理起来可能很困难。

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

开发人员纪律：小心代码的耦合。由于所有微服务的代码都在一个存储库中，因此它们之间没有真正的物理边界，因此开发人员可以只使用来自其他微服务的一些代码，例如添加引用或类似内容。将所有微服务放在一个存储库中需要一些纪律和规则，以使开发人员不要越界和滥用它们。
受到创建和滥用共享代码的诱惑。 如果您以适当且结构化的方式进行操作，这并不是一件坏事。这再次为错误的方式留下了很大的空间。如果人们只是开始使用相同的共享 jar 或类似的可能会导致很多问题。为了共享某些东西，它应该被隔离和打包，理想情况下应该有一些支持向后兼容性的版本控制。这样，当这个库更新时，每个微服务仍然有一个与以前版本的工作代码。在同一个存储库中仍然是可行的，但与上面的 1. 点一样，它需要规划和管理。
Git 注意事项：在一个存储库中管理大量拉取请求和分支可能具有挑战性，并可能导致以下情况：“我被其他人阻止了”。此外，由于可能会有更多的人参与该项目并将提交到您的源分支，您将不得不更频繁地执行 rebase 和/或将源分支合并到您的开发或功能分支（即使您不需要从其他服务）。为存储库配置的电子邮件通知可能会非常烦人，因为您将收到有关不在您的微服务代码中的内容的电子邮件。在这种情况下，您需要在您的电子邮件客户端中创建一些过滤器/规则，以避免您不感兴趣的电子邮件。
微服务的数量比最初的 10 到 15 个还要进一步增长。 这个数字还能增长吗？如果不是一切都很好，但如果在某个时候确实如此，您可能会考虑将每个微服务拆分到一个专用的存储库中。在您处于项目后期阶段的时候执行此操作可能具有挑战性，并且可能需要一些工作，在最坏的情况下，您会发现随着时间的推移人们会做出一些耦合，您必须在此阶段解决这些耦合。
CI 管道注意事项：如果您使用 Jenkins 之类的工具来构建、测试和/或部署您的代码您可能会遇到一些小的配置困难，例如 Jenkins 和 Github 之间的集成。如果有人针对该微服务创建合并/拉取请求，您将需要配置一个仅构建/测试代码的特定部分（或一个微服务）的管道。我从来没有尝试过做这样的事情，但我想你必须弄清楚如何去做（脚本和自动化）。我猜这是可行的，但需要一些工作才能实现。

结论

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

【讨论】：