删除 '_posts/go-2.md'

_posts/go-2.md

@@ -1,469 +0,0 @@
----
-title: Golang高阶：Golang1.5到Golang1.12包管理
-date: 2020-06-29 12:19:08
-tags: Golang
-cover: https://static.jqwei.com/blog/img/IMG_3459.PNG
-categories: 编程语言
----
-`Golang` 是一门到如今有十年的静态高级语言了，2009年的时候算是正式推出了，然后到最近的一两年，2017-2018年的时候，突然直线上升，爆火了，得益于容器化运维/直播/短视频/区块链...
-
-`Golang` 语法简单，简单即是复杂，软件构建的核心在于将复杂的东西简单化，处理好复杂度。
-
-作为一个 `gopher`，我们要知道他的包管理，这样才能合理化代码结构，做好工程管理。（ `gopher`：地鼠）
-
-`Golang` 的包管理一直让人口病，一开始它用 `GOPATH` 来进行依赖库管理，特别简单粗暴。
-
-如果环境变量：
-
-```
-export GOROOT=/home/love/go
-export GOPATH=/home/love/code
-export GOBIN=$GOROOT/bin
-```
-
-上面 `GOROOT` 是指 `Golang编译器以及其工具链，基础源码库`所在的目录， `GOPATH` 是用户自定义的代码所在位置。
-
-以下 `GOPATH` 的结构如下：
-
-```
-├── src
-    └── github.com
-        └── hunterhug
-            └── rabbit
-                └── a
-                    └── a.go
-                └── main.go
-├── bin
-├── pkg 
-```
-
-我们写的开发包有简单易懂的路径之分，比如我的包叫 `github/hunterhug/rabbit`，那么结构如上面一样。
-
-我们进入到 `rabbit` 目录， `main.go` 代码：
-
-```
-package main
-import "github/hunterhug/rabbit/a"
-
-func main(){
-  ...
-
-}
-```
-
-然后 `go build` 的话，找包时，就会从 `GOPATH src` 下面开始找，比如 `rabbit` 包下的 `main.go` 依赖了 `github/hunterhug/rabbit/a`，那么它首先从 `src` 下面按路径往下拼接查找，然后就找到了，最后生成和包名 `github/hunterhug/rabbit` 一样的一个叫 `rabit` 的二进制。
-
-如果我们 `go install`的话，这个二进制就会保存在 `GOBIN` 下（如果不存在 `GOBIN`，会保存在 `GOPATH bin` 下）。如果我们要编译时，缺少包，那么 `go get -v` 将会下载依赖包源码到 `GOPATH src` 下，然后在 `GOPATH pkg` 目录下生成该包的静态库（下次用就不用再从源码编译了，算缓存）。
-
-但是我们包找不到时：
-
-```
-love@love:~/code/src/github.com/hunterhug/fafacms$ go build
-core/server/server.go:4:2: cannot find package "github.com/gin-contrib/cors" in any of:
-        /home/love/go/src/github.com/gin-contrib/cors (from $GOROOT)
-        /home/love/code/src/github.com/gin-contrib/cors (from $GOPATH)
-```
-
-我们发现，原来，其实是先去 `GOROOT` 下找包，找不到包，再去 `GOPATH` 找，流下了感动的泪水！比如我们的 `GOPATH` 下建了一个 `fmt` 包：
-
-```
-package fmt
-
-func PPrintln() {
-    print("i am diy fmt")
-}
-
-```
-
-但是我们想引用这个库， `main.go` 使用：
-
-```
-package main
-import fmt
-func main(){
-  fmt.PPrintln()
-}
-```
-
-发现引用不了，2333！ 所以， `GOPATH` 下的包最好不要和 `GOROOT` 下的标准库重名！
-
-你再看下 `GOROOT` 的结构:
-
-```
-├── src
-    └── time
-    └── fmt
-├── bin
-├── pkg 
-```
-
-这不和我们的 `GOPATH` 很像吗，对，现在的 `Golang编译器` 是自编译的，就是用 `Golang` 来写 `Golang编译器`，它的编译器及中间产物，基础库等，保持和 `GOPATH` 一毛一样，无缝衔接。
-
-但是不同依赖包是有版本的，版本变了怎么办？这就需要人工管理了。
-
-自己管理库版本，想想都不太可能，毕竟 `Java` 有 `maven`, `Python` 有 `pip`, `PHP` 有 `compose`， `NodeJs` 有 `npm`。
-
-于是从 `Golang1.5` 开始推出 `vendor` 文件夹机制（ `vendor`：供应商/小贩）。
-
-从 `Golang1.6` 正式开启这个功能。
-
-比如我们的包叫 `awesomeProject`，在 `GOPATH` 下结构：
-
-```
-├── src
-    └── awesomeProject
-        └── vendor
-            └── fmt
-                └── fmt.go
-        └── main.go
-├── pkg 
-```
-
-其中 `main.go`：
-
-```
-package main
-
-import "fmt"
-
-func main() {
-    fmt.PPrintln()
-}
-```
-
-我们进入 `awesomeProject` 目录，并且 `go build`， 偶也成功。
-
-这下子不会像上面没 `vendor` 时直接引用 `GOROOT` 的标准包了，我们终于可以用和标准包重名的包了，那就是放在和 `main.go` 同目录的 `vendor` 下面！
-
-这下子，我们 `import` 的包会先在同级 `vendor` 下找，找不到再按照以前的方式。
-
-如果我们将 `main` 改成引用一个不存在的包 `b`:
-
-```
-package main
-
-import (
-    "b"
-)
-
-func main() {
-    b.P()
-}
-```
-
-然后 `go build` 提示：
-
-```
-main.go:4:2: cannot find package "b" in any of:
-        /home/love/code/src/awesomeProject/vendor/b (vendor tree)
-        /home/love/go/src/b (from $GOROOT)
-        /home/love/code/src/b (from $GOPATH)
-```
-
-如果此时我们再任性一点，在 `GOPATH src` 下建立一个空的 `vendor` 文件夹，则会提示：
-
-```
-main.go:4:2: cannot find package "b" in any of:
-        /home/love/code/src/awesomeProject/vendor/b (vendor tree)
-        /home/love/code/src/vendor/b
-        /home/love/go/src/b (from $GOROOT)
-        /home/love/code/src/b (from $GOPATH)
-```
-
-好了，我们发现现在的加载方式是:
-
-```
-包同目录下的vendor
-GOPATH src 下的vendor
-GOROOT src
-GOPATH src
-```
-
-如果在 `GOROOT` 和 `GOPATH` 下建 `vendor` 会怎么样？我们就不止疼了，233。。
-
-好了，现在问题就是 `vendor` 是怎么冒泡的，如果我 `main.go` 引用了 `vendor/b`，而 `b` 包里面引用了一个 `c` 包。此时 `vendor/b` 会怎么找库？
-
-```
-├── src
-    └── awesomeProject
-        └── vendor
-            └── b
-                └── b.go
-        └── main.go
-├── pkg 
-```
-
-现在 `vendor/b/b.go` 的内容：
-
-```
-package b
-
-import "c"
-
-func P() {
-    print(" i am vendor b\n")
-    c.P()
-}
-```
-
-我们进入 `awesomeProject` 项目 `go build`，出现：
-
-```
-vendor/b/b.go:3:8: cannot find package "c" in any of:
-    /home/love/code/src/awesomeProject/vendor/c (vendor tree)
-    /home/love/code/src/vendor/c
-    /home/love/go/src/c (from $GOROOT)
-    /home/love/code/src/c (from $GOPATH)
-```
-
-现在加载流程是：
-
-```
-包同目录的包（即b包同目录看看有没有c包）
-GOPATH src 下的vendor
-GOROOT src
-GOPATH src
-```
-
-此时我们在 `vendor/b` 下建一个空 `vendor`：
-
-```
-├── src
-    └── awesomeProject
-        └── vendor
-            └── b
-                └── vendor
-                └── b.go
-        └── main.go
-├── pkg 
-```
-
-进入 `awesomeProject` 项目再 `go build` 会出现：
-
-```
-vendor/b/b.go:3:8: cannot find package "c" in any of:
-    /home/love/code/src/awesomeProject/vendor/b/vendor/c (vendor tree)
-    /home/love/code/src/awesomeProject/vendor/c
-    /home/love/code/src/vendor/c
-    /home/love/go/src/c (from $GOROOT)
-    /home/love/code/src/c (from $GOPATH)
-```
-
-如果我们再满足上面的 `c` 包，同理在 `c` 包建一个空 `vendor` ：
-
-```
-├── src
-    └── awesomeProject
-        └── vendor
-            └── b
-                └── vendor
-                    └── c
-                        └── vendor
-                        └── c.go
-                └── b.go
-        └── main.go
-├── pkg 
-```
-
-但 `c` 包 `c.go` 引用了不存在的 `d` 包：
-
-```
-package c
-
-import "d"
-
-func P() {
-    d.P()
-}
-
-```
-
-进入 `awesomeProject` 项目再 `go build` 会出现：
-
-```
-vendor/b/vendor/c/c.go:3:8: cannot find package "d" in any of:
-    /home/love/code/src/awesomeProject/vendor/b/vendor/c/vendor/d (vendor tree)
-    /home/love/code/src/awesomeProject/vendor/b/vendor/d
-    /home/love/code/src/awesomeProject/vendor/d
-    /home/love/code/src/vendor/d
-    /home/love/go/src/d (from $GOROOT)
-    /home/love/code/src/d (from $GOPATH)
-```
-
-发现， 查找包 `vendor` 是往上冒泡的， 一个包引用另一个包，先看看 同目录 `vendor` 下有没有这个包， 没有的话一直追溯到上一层 `vendor` 看有没有，没有的话再上一层<br> `vendor`，直到 `GOPATH src/vendor`。
-
-所以现在的加载流程是：
-
-```
-包同目录下的vendor
-包目录向上的最近的一个vendor
-...
-GOPATH src 下的vendor
-GOROOT src
-GOPATH src
-```
-
-总结： `vendor` 向上冒泡！！！！
-
-这样的话， 我们可以把包的依赖都放在 `vendor` 下，然后提交到仓库，这样可以省却拉取包的时间，并且相对自由，你想怎么改都可以，你可以放一个已经被人删掉的 `github` 包在 `vendor` 下。这样，依然手动，没法管理依赖版本。
-
-所以很多第三方，比如 `glide` , `godep`, `govendor` 工具出现了， 使用这些工具， 依赖包必须有完整的 `git` 版本， 然后会将所有依赖的版本写在一个配置文件中。
-
-比如 `godep` ：
-
-```
-go get -v github.com/tools/godep
-```
-
-在包下执行
-
-```
-godep save
-```
-
-会生成 `Godeps/Godep.json`记录依赖版本，并且将包收集于 当前 `vendor`下。
-
-`Golang 1.11` 开始， 实验性出现了可以不用定义 `GOPATH` 的功能，且官方有 `go mod` 支持。 `Golang 1.12` 更是将此特征正式化。
-
-现在用 `Golang1.12` 进行：
-
-```
-go mod init
-go: modules disabled inside GOPATH/src by GO111MODULE=auto; see 'go help modules'
-```
-
-其中 `GO111MODULE=auto` 是一个开关，开启或关闭模块支持，它有三个可选值： `off`/ `on`/ `auto`，默认值是 `auto`。
-
-在使用模块的时候， `GOPATH` 是无意义的，不过它还是会把下载的依赖储存在 `GOPATH/src/mod` 中，也会把 `go install` 的结果放在 `GOPATH/bin`（如果 `GOBIN` 不存在的话）
-
-我们将项目移出 `GOPATH`，然后:
-
-```
-go mod init
-```
-
-出现：
-
-```
-go: cannot determine module path for source directory /home/love/awesomeProject (outside GOPATH, no import comments)
-```
-
-现在 `main.go` 改为：
-
-```
-package main // import "github.com/hunterhug/hello"
-
-import (
-    "b"
-)
-
-func main() {
-    b.P()
-}
-```
-
-将会生成 `go.mod`:
-
-```
-module github.com/hunterhug/hello
-
-go 1.12
-```
-
-此时我们：
-
-```
-go build
-build github.com/hunterhug/hello: cannot load b: cannot find module providing package b
-```
-
-这下没法查找 `vendor` 了，我们加上参数再来：
-
-```
-go build -mod=vendor
-build github.com/hunterhug/hello: cannot load c: open /home/love/awesomeProject/vendor/c: no such file or directory
-```
-
-流下了感动的泪水， `vendor` 冒泡呢？原来启用了 `go.mod`， `vendor` 下的包 `b` 无法找到 `b/vendor` 下的包 `c`，只能找到一级，2333333，这是好还是坏？
-
-一般情况下， `vendor` 下面有 `vendor` 是不科学的， `godep` 等工具会将依赖理顺，确保只有一个 `vendor`。
-
-那么 `go.mod` 导致 `vendor` 无法冒泡产生的影响，一点都不大，流下感动的泪水。
-
-现在我们来正确使用 `go mod`， 一般情况下：
-
-```
-省略N步
-```
-
-到了这里，我们很遗憾的说再见了，现在 `go mod` 刚出来， 可能还会再更新，您可以谷歌或者其他方式搜索这方面的文章，或者：
-
-```
-go help modules
-```
-
-这一部分可能隔一段时间再细写。
-
-目前生产环境用 `go mod` 还不太现实， 我还是先推荐定义 `GOPATH` 和 `vendor` 用法。
-
-装环境太难， 我的天啊， 我每次都要装环境， 我们可以用下面的方法 `So easy` 随时切换 `Golang` 版本。
-
-如果你的 `Golang` 项目依赖存于 `vendor` 下，那么我们可以使用多阶段构建并打包成容器镜像， `Dockefile` 如下：
-
-```
-FROM golang:1.12-alpine AS go-build
-
-WORKDIR /go/src/github.com/hunterhug/fafacms
-
-COPY core /go/src/github.com/hunterhug/fafacms/core
-COPY vendor /go/src/github.com/hunterhug/fafacms/vendor
-COPY main.go /go/src/github.com/hunterhug/fafacms/main.go
-
-RUN go build -ldflags "-s -w" -o fafacms main.go
-
-FROM alpine:3.9 AS prod
-
-WORKDIR /root/
-
-COPY --from=go-build /go/src/github.com/hunterhug/fafacms/fafacms /bin/fafacms
-RUN chmod 777 /bin/fafacms
-CMD /bin/fafacms $RUN_OPTS
-```
-
-其中 `github.com/hunterhug/fafacms` 是你的项目。使用 `golang:1.12-alpine` 来编译二进制，然后将二进制打入基础镜像： `alpine:3.9`，这个镜像特别小。
-
-编译：
-
-```
-sudo docker build -t hunterhug/fafacms:latest .
-```
-
-我们多了一个镜像 `hunterhug/fafacms:latest`, 而且特别小， 才几M 。
-
-运行：
-
-```
-sudo docker run -d  --net=host  --env RUN_OPTS="-config=/root/fafacms/config.json" hunterhug/fafacms
-```
-
-可是，如果我们用了 `cgo`， 那么请将 `Dockerfile` 改为：
-
-```
-FROM golang:1.12 AS go-build
-
-WORKDIR /go/src/github.com/hunterhug/fafacms
-
-COPY core /go/src/github.com/hunterhug/fafacms/core
-COPY vendor /go/src/github.com/hunterhug/fafacms/vendor
-COPY main.go /go/src/github.com/hunterhug/fafacms/main.go
-
-RUN go build -ldflags "-s -w" -o fafacms main.go
-
-FROM bitnami/minideb-extras-base:stretch-r165 AS prod
-
-WORKDIR /root/
-
-COPY --from=go-build /go/src/github.com/hunterhug/fafacms/fafacms /bin/fafacms
-RUN chmod 777 /bin/fafacms
-CMD /bin/fafacms $RUN_OPTS
-```