分类 Golang 下的文章 - 無標題文檔

2019-06-21

由于工作的关系，所以又点了 Golang 这个技能树。几个月下来，对于这个语言以及对应技术栈的理解不算透彻，但多多少少会有些心得。

在这里整理下最近用 Golang 写的些小工具以及类库，希望能对大家有所帮助。

Genpasswd 简单的密码生成工具

源码地址：https://github.com/mingcheng/genpasswd.go ，根据名字就知道这是个生成随机密码的小工具。这个项目是本人的第一个 Goalng 项目，主要是熟练使用了些对应的脚本和配套的 CI 等工具（Travis 非常好用）。

QQWry 基于纯真 IP 库的微服务应用

源码地址：https://github.com/mingcheng/qqwry.go ，根据 IP 地址反查对应的地理位置等信息。

纯真 IP 库其实不是新东西了，早在以前 QQ 时代显示对方的 IP 信息就基本上会拿这个库来处理。其实，这个项目也只是根据线上现成的项目改进了下，使其支持在线获取以及更新最新的数据库（后续考虑增加 GRPC 的支持）。

NCMDump 云音乐 NCM 格式分析

源码地址： https://github.com/mingcheng/ncmdump.go ，云音乐出于版权方面的考虑有些歌曲在下载到本地的时候，格式是所谓的 NCM 格式。这在导入到其他设备的时候会有些麻烦。

网络上有对应的 C++ 以及 Python 的实现。其实也有对应 Golang 的实现，但会有些 Bug 例如解析某些 flac 封装的歌曲的时候会报异常，所以改进了下。通过这个项目，对于 AES 加密以及文件操作有了很直观的认知。

PIDFile 生成 PID 文件的库

源码地址：https://github.com/mingcheng/pidfile ，由于些 Golang 通常用于 Daemon 的编写，所以会考虑使用 PID 文件避免程序重复启动，因此就有了这个库。

Obsync 华为对象存储同步工具

源码地址：https://github.com/mingcheng/obsync.go ，尝试使用了下华为云的对象存储服务（OBS），发现支持的节点不错而且对比阿里云相对便宜些。诡异的是它还有非洲的节点，速度也不慢电信直连。

这样子，我的线上备份以及同步就有了另外个去处，数据方面也会安心一点。在中美这个节点上，支持下华为吧。

最后，顺便说下 Chaosblade 这个项目，它是阿里的混沌实验实施工具。其源代码相对来说不会很复杂，可以阅读下以后多给它做些改进。

One more thing. 还有个小玩意是 NSFW 的，我改造了下使其支持代理下载，具体的看链接吧：https://github.com/mingcheng/pornhub-dl.go

- eof -

使用多个版本交叉编译 Golang 项目

2019-06-03

在编写内部项目中，往往不同的项目因为历史遗留问题，会有存在多个版本的 golang 编译器共存的情况。

同时，由于 golang 的包管理的短板（虽然在 golang 1.11 以后推出了 go mod），因此不可避免的安装 govendor、go dep 等多个包管理工具，非常的混乱。

本地使用多个 golang 的编译器版本其实更容易造成混乱，同时 env 满天飞也非常不方面维护。解决这块的问题很容易就想到了使用 Docker 去编译和检查本地项目， Docker 官方维护了多个版本的 golang 镜像。

那么考虑的目标是：

使用同一个 Makefile 以及 Dockerfile 去维护项目的编译
因为 golang 1.11 以后官方推出了 go mod，所以尽量使用官方的包管理工具
接上条，老版本的依赖和本地编译使用 go mod vendor 去管理
Makefile 不管 golang 编译器的版本问题，编译器版本让 Dockerfile 去管理
本地环境尽量使用最新版本的 golang 编译器，然后导入到 vendor 中

那么这样子，我们可以简单的使用 Dockerfile 去编译执行，例如下面使用编译器版本 golang 1.9.7 类似：

FROM golang:1.9.7 AS builder
# ...
RUN go build .
# ...

但需要注意的是，golang 1.11 之前必须代码在 $GOPATH 中，所以需要映射

ENV GOPATH /go
ENV GOROOT /usr/local/go
ENV PACKAGE ${YOUR_PACKAGE_NAME}
ENV BUILD_DIR ${GOPATH}/src/${PACKAGE}

# ...
COPY . ${BUILD_DIR}

然后在本地使用 go mod vendor 下载依赖包到项目的 /vendor 就可以在老版本中免去使用 dep、govendor 等依赖工具，统一使用官方的 go mod 去管理和下载依赖。

还有需要关注的是 Makefile 需要加个判断，为了增加通用性，建议根据路径判断 golang 的环境路径，而不是判断是否在 Docker 环境下：

# ...
ifneq ("$(wildcard /go)","")
    GOPATH=/go
    GOROOT=/usr/local/go
endif

GO=env $(GO_ENV) $(GOROOT)/bin/go

# ...

build:$(DIR_SRC)/main.go
    @$(GO) build $(GO_FLAGS) -o $(BIN) $(DIR_SRC)

这样子 Makefile 文件就可以同时同于本地高版本的环境以及 Docker 编译环境了。

详细的示例代码可以参看这个简单的项目（作用只是用于生成随机密码），其中的 Makefile 以及 Dockerfile 。

最后，有个讨论 vendor 目录到底要不要纳入到版本控制中？我个人的看法是看情况，大部分情况下不会将这些第三方代码纳入版本控制中。主要的理由有：

这些代码是第三方库的代码，不会直接更改以及维护；
go.mod 以及 go.sum 文件已经保存了第三方依赖的库信息（版本、hash 等等）；
库文件通常会很多，纳入这些的文件会「污染」本地的 git history；
不同于开源项目，我们本地的开发环境是可控的。

所以，类似的 Consul 等比较大型的项目还是会将 vendor 目录纳入到版本控制中，个人认为这也是因为兼容方面的考虑更多些，而如果个本地项目往往环境是可控的。