etcd终于解决冲突了

如题，etcd终于解决了一个老大难的问题，就是依赖问题，它简直不要让人再多痛苦了。

在新发布的etcd 3.5中，已经解决了对Go Module 的支持，并将之前大的 etcd 模块按功能进行了拆分，实现了 etcd 的模块化等，解决了各种 “go get fail”、依赖复杂、循环依赖、以及强制依赖过低的 gRPC 版本等问题，使用起来更简单了。

当然其还有其他各项改进，这里我并不关心。。。

如果你遇到过这样的问题：

go get go.etcd.io/etcd/
go get: github.com/coreos/bbolt@none updating to
 github.com/coreos/bbolt@v1.3.6: parsing go.mod:
 module declares its path as: go.etcd.io/bbolt
         but was required as: github.com/coreos/bbolt
go.etcd.io/etcd imports
 github.com/coreos/etcd/etcdmain imports
 github.com/coreos/etcd/proxy/grpcproxy imports
 google.golang.org/grpc/naming: cannot find module providing package google.golang.org/grpc/naming

或者还需要在go.mod中加入：

1	replace google.golang.org/grpc => google.golang.org/grpc v1.26.0

请直接出门使用v3.5.0这个千呼万唤始出来的版本。

在之前的使用中，由于遇到了太多这样的问题，所以我参照了k8s的go.mod，其是这样使用的：

1	go.etcd.io/etcd => go.etcd.io/etcd v0.5.0-alpha.5.0.20200910180754-dd1b699fc489 // ae9734ed278b is the SHA for git tag v3.4.13

但这样的版本定义也只是一个权宜之计，在我看到etcd更新的时候，我再去看k8s，其也已经替换掉了之前的这个定义，使用v3.5.0版本了，不可以说是非常的清爽了。

社区提出了模块化的解决方案，也就是将 etcd 整个大的模块，按角色与功能拆分成 client、server、raft、api、tests、etcdctl、etcdutl 相关的子模块，具体如下图。

实际导入代码使用时，引入的包是这样的：

1 2	go.etcd.io/etcd/api/v3 v3.5.0 go.etcd.io/etcd/client/v3 v3.5.0

也就是说需要使用哪个模块，go get哪个具体模块就行：

1	go get go.etcd.io/etcd/etcdctl/v3