依赖管理：Golang 子项目或子模块

在 Go 中管理依赖项子模块的最佳实践是尽可能坚持单一存储库和模块，因为将代码库拆分会导致版本依赖关系复杂性。对于要求客户端和服务器分开的特定场景，可以将它们放置在同一存储库或不同存储库中的单独模块中。公共代码应位于其自己的模块中，例如 common，而客户端模块只依赖 client 和 common，而无需依赖 server。

golang 中下载依赖项子模块的推荐方法是什么？我认为通过例子可以最好地描述我的问题。

示例#1：

我有一个客户端和一个服务器。我的服务器是一个 api，并且有许多其他依赖项，例如数据库、消息队列、consul 等。我希望我的客户端是一个轻量级包，用户只需下载所需的少量依赖项客户端。

您可以说客户端和服务器可以位于不同的存储库上。然而，它们之间也可能有一些共同的代码，如果我们遵循这种模式，它们将再次成为另一个存储库。

我正在考虑一些如下所示的结构：

service/
---> common/
------> redis.go
------> kafka.go
---> client/
------> client.go
---> server/
------> database/
------> swagger/
------> producer/
------> etc/

示例#2：

项目共享模型是很常见的。如果我们有通过具有通用模型的消息代理进行通信的微服务，我们可能需要这样的结构。

service/
---> model/
------> message.go
---> service1/
---> service2/

与其他语言的比较

我有 scala/java 背景，开始使用 golang 还不到一个月。与 scala 相比，我可以通过两种方式处理这个问题。让我们来看示例#2

1. 将模型发布为自己的 jar 并在每个服务中导入 model.jar
2. 在 sbt 中使用多项目设置：https://www.scala-sbt.org/1.x/docs/multi-project.html。

我在 go 中探索的一些事情

1. https://blog.gopheracademy.com/advent-2015/vendor-folder/
2. https://github.com/golang/go/wiki/modules#faqs--multi-module-repositories

但到目前为止他们似乎没有解决我的问题

最后一个问题

golang 中解决我在示例中提到的问题的推荐方法是什么？

感谢您的帮助！

解决方案

一般来说，尝试尽可能坚持一个存储库和一个模块。将代码库拆分为多个存储库和/或多个模块会产生随着时间的推移而增加的成本。您需要在自己的模块之间定义清晰的版本依赖关系，仔细进行分阶段升级等。特别是对于中小型项目，一个存储库和一个模块是最好的方法。

关于示例 1 中的具体要求，如果“客户端”的用户不提取“服务器”代码至关重要，那么客户端和服务器必须位于单独的模块中。这些模块可以位于同一个存储库中，也可以位于不同的存储库中 - 这对 go 来说没有区别。公共代码必须位于其自己的模块中，例如：

github.com/user/myrepo/
  client/
    go.mod
  server/
    go.mod
  common/
    go.mod

然后，使用您的客户端的模块将在其 go.mod 中包含：

require github.com/user/myrepo/client <version>

这将引入 client 和 common，但不会引入 server。

如果服务器可以依赖客户端，则您可以将 common 设为 client 的一部分，尽管我不确定这会节省多少。

对于示例 2，其想法是相似的 - 公共代码可以进入其自己的模块。

强烈建议您阅读Using Go Modules上的官方博文。

有关包含模块的简单 go 项目布局，请参阅 this post

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《依赖管理：Golang 子项目或子模块》文章吧，也可关注golang学习网公众号了解相关技术文章。