2021年十一月月 发布的文章

使用Docker Compose构建一键启动的运行环境

本文永久链接 – https://tonybai.com/2021/11/26/build-all-in-one-runtime-environment-with-docker-compose

如今,不管你是否喜欢,不管你是否承认,微服务架构模式的流行就摆在那里。作为架构师的你,如果再将系统设计成个大单体结构,那么即便不懂技术的领导,都会给你送上几次白眼。好吧,妥协了!开拆!“没吃过猪肉,还没见过猪跑吗!”。拆不出40-50个服务,我就不信还拆不出4-5个服务^_^。

终于拆出了几个服务,但又犯难了:以前单体程序,搭建一个运行环境十分easy,程序往一个主机上一扔,配置配置,启动就ok了;但自从拆成服务后,开发人员的调试环境、集成环境、测试环境等搭建就变得异常困难。

有人会说,现在都云原生了?你不知道云原生操作系统k8s的存在么?让运维帮你在k8s上整环境啊。 一般小厂,运维人员不多且很忙,开发人员只能“自力更生,丰衣足食”。开发人员自己整k8s?别扯了!没看到这两年k8s变得越来越复杂了吗!如果有一年不紧跟k8s的演进,新版本中的概念你就可能很陌生,不知源自何方。一般开发人员根本搞不定(如果你想搞定,可以看看我的k8s实战课程哦,包教包会^_^)。

那怎么办呢?角落里曾经的没落云原生贵族docker发话了:要不让我兄弟试试!

1. docker compose

docker虽然成了“过气网红”,但docker依然是容器界的主流。至少对于非docker界的开发人员来说,一提到容器,大家首先想到的还是docker。

docker公司的产品推出不少,开发人员对多数都不买账也是现实,但我们也不能一棒子打死,毕竟docker是可用的,还有一个可用的,那就是docker的兄弟:docker compose

Compose是一个用于定义和运行多容器Docker应用程序的工具。使用Compose,我们可以使用一个YAML文件来配置应用程序的所有服务组件。然后,只需一条命令,我们就可以创建并启动配置中的所有服务。

这不正是我们想要的工具么! Compose与k8s很像,都算是容器编排工具,最大的不同:Compose更适合在单节点上的调试或集成环境中(虽然也支持跨主机,基于被淘汰的docker swarm)。Compose可以大幅提升开发人员以及测试人员搭建应用运行环境的效率。

2. 选版本

使用docker compose搭建运行环境,我们仅需一个yml文件。但docker compose工具也经历了多年演化,这个文件的语法规范也有多个版本,截至目前,docker compose的配置文件的语法版本就有2、2.x和3.x三种。并且不同规范版本支持的docker引擎版本还不同,这个对应关系如下图。图来自docker compose文件规范页面

选版本是最闹心的。选哪个呢?设定两个条件:

  • docker引擎版本怎么也得是17.xx
  • 规范版本怎么也得是3.x吧

这样一来,版本3.2是最低要求的了。我们就选3.2:

// docker-compose.yml
version: "3.2"

3. 选网络

docker compose默认会为docker-compose.yml中的各个service创建一个bridge网络,所有service在这个网络里可以相互访问。以下面docker-compose.yml为例:

// demo1/docker-compose.yml
version: "3.2"
services:
  srv1:
    image: nginx:latest
    container_name: srv1
  srv2:
    image: nginx:latest
    container_name: srv2

启动这个yml中的服务:

# docker-compose -f docker-compose.yml up -d
Creating network "demo1_default" with the default driver
... ...

docker compose会为这组容器创建一个名为demo1_default的桥接网络:

# docker network ls
NETWORK ID          NAME                     DRIVER              SCOPE
f9a6ac1af020        bridge                   bridge              local
7099c68b39ec        demo1_default            bridge              local
... ...

关于demo1_default网络的细节,可以通过docker network inspect 7099c68b39ec获得。

对于这样的网络中的服务,我们在外部是无法访问的。如果要访问其中服务,我们需要对其中的服务做端口映射,比如如果我们要将srv1暴露到外部,我们可以将srv1监听的服务端口80映射到主机上的某个端口,这里用8080,修改后的docker-compose.yml如下:

version: "3.2"
services:
  srv1:
    image: nginx:latest
    container_name: srv1
    ports:
    - "8080:80"
  srv2:
    image: nginx:latest
    container_name: srv2

这样启动该组容器后,我们通过curl localhost:8080就可以访问到容器中的srv1服务。不过这种情况下,服务间的相互发现比较麻烦,要么借助于外部的发现服务,要么通过容器间的link来做。

开发人员大多只有一个环境,不同服务的服务端口亦不相同,让容器使用host网络要比单独创建一个bridge网络来的更加方便。通过network_mode我们可以指定服务使用host网络,就像下面这样:

version: "3.2"
services:
  srv1:
    image: bigwhite/srv1:1.0.0
    container_name: srv1
    network_mode: "host"

在host网络下,容器监听的端口就是主机上的端口,各个服务间通过端口区别各个服务实例(前提是端口各不相同),ip使用localhost即可。

使用host网络还有一个好处,那就是我们在该环境之外的主机上访问环境中的服务也十分方便,比如查看prometheus的面板等。

4. 依赖的中间件先启动,预置配置次之

如今的微服务架构系统,除了自身实现的服务外,外围还有大量其依赖的中间件,比如:redis、kafka(mq)、nacos/etcd(服务发现与注册)、prometheus(时序度量数据服务)、mysql(关系型数据库)、jaeger server(trace服务器)、elastic(日志中心)、pyroscope-server(持续profiling服务)等。

这些中间件若没有启动成功,我们自己的服务多半启动都要失败,因此我们要保证这些中间件服务都启动成功后,再来启动我们自己的服务。

如何做呢?compose规范中有一个迷惑人的“depends_on”,比如下面配置文件中srv1依赖redis和nacos两个service:

version: "3.2"
services:
  srv1:
    image: bigwhite/srv1:1.0.0
    container_name: srv1
    network_mode: "host"
    depends_on:
      - "redis"
      - "nacos"
    environment:
      - NACOS_SERVICE_ADDR=127.0.0.1:8848
      - REDIS_SERVICE_ADDR=127.0.0.1:6379
    restart: on-failure

不深入了解,很多人会认为depends_on可以保证先启动依赖项redis和nacos,并等依赖项ready后再启动我们自己的服务srv1。但实际上,depends_on仅能保证先启动依赖项,后启动我们的服务。但它不会探测依赖项redis或nacos是否ready,也不会等依赖项ready后,才启动我们的服务。于是你会看到srv1启动后依旧出现各种的报错,包括无法与redis、nacos建立连接等。

要想真正实现依赖项ready后才启动我们自己的服务,我们需要借助外部工具了,docker compose文档对此有说明。其中一个方法是使用wait-for-it脚本

我们可以改变一下自由服务的容器镜像,将其entrypoint从执行服务的可执行文件变为执行一个start.sh的脚本:

// Dockerfile
... ...
ENTRYPOINT ["/bin/bash", "./start.sh"]

这样我们就可以在start.sh脚本中“定制”我们的启动逻辑了。下面是一个start.sh脚本的示例:

#! /bin/sh

./wait_for_it.sh $NACOS_SERVICE_ADDR -t 60 --strict -- echo "nacos is up" && \
./wait_for_it.sh $REDIS_SERVICE_ADDR -- echo "redis is up" && \
exec ./srv1

我们看到,在start.sh脚本中,我们使用wait_for_it.sh脚本等待nacos和redis启动,如果在限定时间内等待失败,根据restart策略,我们的服务还会被docker compose重新拉起,直到nacos与redis都ready,我们的服务才会真正开始执行启动过程。

在exec ./srv1之前,很多时候我们还需要进行一些配置初始化操作,比如向nacos中写入预置的srv1服务的配置文件内容以保证srv1启动后能从nacos中读取到自己的配置文件,下面是加了配置初始化的start.sh:

#! /bin/sh

./wait_for_it.sh $NACOS_SERVICE_ADDR -t 60 --strict -- echo "nacos is up" && \
./wait_for_it.sh $REDIS_SERVICE_ADDR -- echo "redis is up" && \
curl -X POST --header 'Content-Type: application/x-www-form-urlencoded' -d dataId=srv1.yml --data-urlencode content@./conf/srv1.yml "http://127.0.0.1:8848/nacos/v1/cs/configs?group=MY_GROUP" && \
exec ./srv1

我们通过curl将打入镜像的./conf/srv1.yml配置写入已经启动了的nacos中供后续srv1启动时读取。

5. 全家桶,一应俱全

就像前面提到的,如今的系统对外部的中间件“依存度”很高,好在主流中间件都提供了基于docker启动的官方支持。这样我们的开发环境也可以是一个一应俱全的“全家桶”。不过要有一个很容易满足的前提:你的机器配置足够高,才能把这些中间件全部运行起来。

有了这些全家桶,我们无论是诊断问题(看log、看trace、看度量数据),还是作性能优化(看持续profiling的数据),都方便的不要不要的。

6. 结合Makefile,简化命令行输入

docker-compose这个工具有一个“严重缺陷”,那就是名字太长^_^。这导致我们每次操作都要敲入很多命令字符,当你使用的compose配置文件名字不为docker-compose.yml时,更是如此,我们还需要通过-f选项指定配置文件路径。

为了简化命令行输入,减少键盘敲击次数,我们可以将复杂的docker-compose命令与Makefile相结合,通过定制命令行命令并将其赋予简单的make target名字来实现这一简化目标,比如:

// Makefile

pull:
    docker-compose -f my-docker-compose.yml pull

pull-my-system:
    docker-compose -f my-docker-compose.yml pull srv1 srv2 srv3

up: pull-my-system
    docker-compose -f my-docker-compose.yml up

upd: pull-my-system
    docker-compose -f my-docker-compose.yml up -d

up2log: pull-my-system
    docker-compose -f my-docker-compose.yml up > up.log 2>&1

down:
    docker-compose -f my-docker-compose.yml down

ps:
    docker-compose -f my-docker-compose.yml ps -a

log:
    docker-compose -f my-docker-compose.yml logs -f

# usage example: make upsrv service=srv1
service=
upsrv:
    docker-compose -f my-docker-compose.yml up -d ${service}

config:
    docker-compose -f my-docker-compose.yml config

另外服务依赖的中间件一般都时启动与运行开销较大的系统,每次和我们的服务一起启停十分浪费时间,我们可以将这些依赖与我们的服务分别放在不同的compose配置文件中管理,这样我们每次重启自己的服务时,没有必要重新启动这些依赖,这样可以节省大量“等待”时间。

7. .env文件

有些时候,我们需要在compose的配置文件中放置一些“变量”,我们通常使用环境变量来实现“变量”的功能,比如:我们将srv1的镜像版本改为一个环境变量:

version: "3.2"
services:
  srv1:
    image: bigwhite/srv1:${SRV1_VER}
    container_name: srv1
    network_mode: "host"
  ... ...

docker compose支持通过同路径下的.env文件的方式docker-compose.yml中环境变量的值,比如:

// .env
SRV1_VER=dev

这样docker compose在启动srv1时会将.env中SRV1_VER的值读取出来并替换掉compose配置文件中的相应环境变量。通过这种方式,我们可以灵活的修改我们使用的镜像版本。

8. 优点与不足

使用docker compose工具,我们可以轻松拥有并快速启动一个all-in-one的运行环境,大幅度加速了部署、调试与测试的效率,在特定的工程环节,它可以给予开发与测试人员很大帮助。

不过这样的运行环境也有一些不足,比如:

  • 对部署的机器/虚拟机配置要求较高;
  • 这样的运行环境有局限,用在功能测试、持续集成、验收测试的场景下可以,但不能用来执行压测或者说即便压测也只是摸底,数据不算数的,因为所有服务放在一起,相互干扰;
  • 服务或中间件多了以后,完全启动一次也要耐心等待一段时间。

“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!部落目前虽小,但持续力很强,欢迎大家加入!

img{512x368}

img{512x368}
img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go 1.18新特性前瞻:Go工作区模式

本文永久链接 – https://tonybai.com/2021/11/12/go-workspace-mode-in-go-1-18

Go 1.18版本如无意外,将于2022年2月发布

在这个版本中,除了包含万众期待的Go泛型之外,还包含很多实用的功能特性,Go工作区模式(Go workspace mode)就是其中之一,它弥补了当前go module构建模式的一些不足,堪称是go module构建模式的最后一块拼图。这篇文章我们就来看看什么是Go工作区模式,它究竟能解决什么问题。

一. 引子

1. replace带来的烦恼

近期在研究raft算法,参考的是etcd的raft实现。etcd还提供了一个raftexample的样例来说明如何实现基于raft的分布式应用。

要学习raftexample,我们首先要对其进行构建。raftexample的README.md文件中有raftexample编译方法的步骤,但这份安装步骤还停留在Go 1.11版本之前的gopath构建模式时期。如今我们要构建它,最好将其先转换为一个go module后再在go module模式下进行构建。不知道如何将一个legecy go project转换为go module的朋友可以去看一下我的极客时间专栏《Go语言第一课》^_^。

我们先把raftexample单独copy出来,放到一个单独的目录下,然后进入raftexample目录并在该其下执行下面命令添加go.mod文件,这里我们构建使用的go版本是go 1.17

$cd raftexample
$go mod init github.com/bigwhite/raftexample

生成的go.mod内容如下:

$cat go.mod
module github.com/bigwhite/raftexample

go 1.17

接下来,我们执行go mod tidy命令让go命令自行分析raftexample的依赖并下载这些依赖:

$go mod tidy
go: finding module for package go.etcd.io/etcd/client/pkg/v3/types
go: finding module for package go.etcd.io/etcd/raft/v3/raftpb
go: finding module for package go.etcd.io/etcd/client/pkg/v3/fileutil
go: finding module for package go.etcd.io/etcd/server/v3/storage/wal
go: finding module for package go.etcd.io/etcd/server/v3/etcdserver/api/v2stats
go: finding module for package go.etcd.io/etcd/server/v3/etcdserver/api/snap
go: finding module for package go.etcd.io/etcd/server/v3/etcdserver/api/rafthttp
go: finding module for package go.etcd.io/etcd/raft/v3
... ...
go: downloading go.etcd.io/etcd/pkg/v3 v3.5.1
go: downloading go.etcd.io/etcd/api/v3 v3.5.1
go: finding module for package go.etcd.io/etcd/server/v3/storage/wal/walpb
go: finding module for package go.etcd.io/etcd/server/v3/storage/wal
github.com/bigwhite/raftexample imports
    go.etcd.io/etcd/server/v3/storage/wal: module go.etcd.io/etcd/server/v3@latest found (v3.5.1), but does not contain package go.etcd.io/etcd/server/v3/storage/wal
github.com/bigwhite/raftexample imports
    go.etcd.io/etcd/server/v3/storage/wal/walpb: module go.etcd.io/etcd/server/v3@latest found (v3.5.1), but does not contain package go.etcd.io/etcd/server/v3/storage/wal/walpb

go mod tidy命令报错,提示没找到server/v3.5.1下面的go.etcd.io/etcd/server/v3/storage/wal和go.etcd.io/etcd/server/v3/storage/wal/walpb包。翻看etcd工程server/v3.5.1标签下的源码,server下的确不包含storage这个目录。但在main分支下,storage目录是存在的。这很可能是etcd项目自v3.5.0版本开始进行多module改造(原先etcd项目是一个module,后该项目下拆分为多个module,并使用多module标签来管理)后的bug。

怎么处理这一情况呢?我们只能祭出replace大法了!刚说过etcd的main分支下storage目录是存在的,于是我们就手工修改一下raftexample的go.mod文件,添加下面这一行配置:

replace go.etcd.io/etcd/server/v3 v3.5.1 => /Users/tonybai/go/src/github.com/etcd-io/etcd/server

然后我们再执行go mod tidy,这回依赖分析与下载顺利完成了并且通过go build命令我们可以成功构建raftexample了。此时,raftexample的go.mod变成了这个样子:

module github.com/bigwhite/raftexample

go 1.17

replace go.etcd.io/etcd/server/v3 v3.5.1 => /Users/tonybai/go/src/github.com/etcd-io/etcd/server

require (
    go.etcd.io/etcd/client/pkg/v3 v3.5.1
    go.etcd.io/etcd/raft/v3 v3.5.1
    go.etcd.io/etcd/server/v3 v3.5.1
    go.uber.org/zap v1.19.1
)

require (
    github.com/beorn7/perks v1.0.1 // indirect
    github.com/cespare/xxhash/v2 v2.1.1 // indirect
    github.com/coreos/go-semver v0.3.0 // indirect
    github.com/dustin/go-humanize v1.0.0 // indirect
    github.com/gogo/protobuf v1.3.2 // indirect
    github.com/golang/protobuf v1.5.2 // indirect
    github.com/matttproud/golang_protobuf_extensions v1.0.1 // indirect
    github.com/prometheus/client_golang v1.11.0 // indirect
    github.com/prometheus/client_model v0.2.0 // indirect
    github.com/prometheus/common v0.26.0 // indirect
    github.com/prometheus/procfs v0.6.0 // indirect
    github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2 // indirect
    go.etcd.io/etcd/api/v3 v3.5.0 // indirect
    go.etcd.io/etcd/pkg/v3 v3.5.0 // indirect
    go.uber.org/atomic v1.7.0 // indirect
    go.uber.org/multierr v1.7.0 // indirect
    golang.org/x/sys v0.0.0-20210603081109-ebe580a85c40 // indirect
    golang.org/x/time v0.0.0-20210220033141-f8bda1e9f3ba // indirect
    google.golang.org/protobuf v1.26.0 // indirect
)

但问题来了!require指示符将go.etcd.io/etcd/server/v3 v3.5.1替换为一个本地路径etcd源码拷贝下的server module,这个本地路径是因开发者环境而异的,但go.mod文件通常是上传到代码服务器上,这就意味着另外一个开发人员下载了这份代码后极大可能是无法成功编译的,他要想完成raftexample的编译,就得将replace后面的本地路径改为适配自己环境下的路径。于是乎每当开发人员pull代码后,第一件事就是要修改go.mod中的replace,每次上传代码前,可能也要将replace路径复原,这是一个很糟心的事情,但在Go 1.18版本之前似乎只能这样做。

2. 依赖本地尚未发布的module更糟糕

别急着学习Go工作区模式!我们再来看另外一个当前go module机制的问题。这个问题同样也是一位学员在我的《Go语言第一课》中咨询过的一个问题,我在《Go语言第一课FAQ》中曾对这个问题做个解答。在这里我再详细举例说明一下。

假设我有一个名为hello-module的项目,它的结构和代码都很简单:

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/local-module/hello-module
$cat go.mod
module github.com/bigwhite/hello-module

go 1.17

$cat main.go

package main

import "github.com/bigwhite/a"

func main() {
    a.A()
}

我们看到:hello-module对外唯一的依赖是module path为github.com/bigwhite/a的module,但后者是一个尚在本地进行开发,还未发布到github.com上的module。如果此时执行go mod tidy,我们将得到下面错误提示:

$go mod tidy
go: finding module for package github.com/bigwhite/a
github.com/bigwhite/hello-module imports
    github.com/bigwhite/a: cannot find module providing package github.com/bigwhite/a: module github.com/bigwhite/a: reading https://goproxy.io/github.com/bigwhite/a/@v/list: 404 Not Found
    server response:
    not found: github.com/bigwhite/a@latest: terminal prompts disabled
    Confirm the import path was entered correctly.
    If this is a private repository, see https://golang.org/doc/faq#git_https for additional information.

go命令无法找到github.com/bigwhite/a这个module。怎么办呢?我们目前的一个“土办法”就是自己“伪造”一个require,然后用replace将伪造的require指向本地的module a的目录

下面是伪造的go.mod文件的内容:

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/local-module/hello-module
module github.com/bigwhite/hello-module

go 1.17

require github.com/bigwhite/a v1.0.0

replace github.com/bigwhite/a v1.0.0 => /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.18-examples/foresight/workspace/local-module/module-a

通过go.mod内容可以看到,我们伪造了hello-module对github.com/bigwhite/a的v1.0.0版本的依赖,并用replace指示符将该版本指向本地的module-a的开发目录。

虽然“伪造”go.mod文件内容可以解决这个场景中的问题,但显然这种方法给开发者的体验也很差,这样的hello-module的go.mod文件一旦提交到代码仓库,同样会给其他开发者带去心智负担。

目前的Go module机制在解决上述两个场景时力不从心,显然缺少最后的那块拼图。而Go 1.18中将引入的Go工作区模式就是go module的最后那块拼图。下面我们就来简要看看Go工作区模式。

二. Go工作区模式

Go工作区模式是Go开发者Michael Matloob在2021年4月提出的一个名为“Multi-Module Workspaces in cmd/go”的proposal。这个proposal引入一个go.work文件用于开启Go工作区模式。go.work通过directory指示符设置一些本地路径,这些路径下的go module构成一个工作区(workspace),Go命令可以操作这些路径下的go module,也会优先使用工作区中的go module

我们先用go工作区模式解决一下前面提到的第一个问题。

在go 1.18版本发布之前,你需要使用gotip才能体验go工作区模式,安装gotip的方法如下:

$go install golang.org/dl/gotip@latest // go 1.17版本及以后使用go install。go 1.16及之前的版本用go get
$gotip download
$gotip version
go version devel go1.18-b7529c3 Tue Nov 9 06:27:04 2021 +0000 darwin/amd64

现在我们进入raftexample下面,然后通过下面命令初始化一个go.work:

$gotip work init .
$cat go.work
go 1.18

directory ./.

我们看到gotip work init命令创建了一个go.work文件,init后的路径被放在了go.work的directory指示符代码块中,directory指示符中的这些路径共同构成了一个Go工作区。我们将当前目录放入directory中,当前目录下的module就被置于我们的工作区当中了。

go.work还支持replace指示符,我们将前面放置在go.mod中的replace挪到go.work中:

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/raftexample-with-go-workspace/go.work

go 1.18

directory ./.

replace go.etcd.io/etcd/server/v3 v3.5.1 => /Users/tonybai/go/src/github.com/etcd-io/etcd/server

然后我们再执行构建:

$gotip build

这回顺利通过了构建。将replace挪到go.work后,go.mod文件就可以放心地提交到远程代码仓库了,其他开发人员下载后也无需修改go.mod,因为他们也有自己的Go工作区模式go.work文件。

go.work配置的是开发者的本地工作区,因此是不建议提交到远程代码仓库中的,我们可以通过.gitignore将其忽略掉。我们甚至可以在任何go module的项目目录之外下放置go.work文件。

除了用replace,我们还可以将本地的etcd项目拷贝也纳入到我们的工作区当中,这样就无需replace了,比如我们可以将上面的go.work改为如下这样:

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/raftexample-with-go-workspace/go.work

$cat go.work
go 1.18

directory (
    ./.
    /Users/tonybai/go/src/github.com/etcd-io/etcd
)

这样raftexample同样可以成功编译。

同样我们也可以通过这种方法解决我们在引子中提到的第二个问题。

和上面例子一样,我们为hello-module这个项目添加一个go.work:

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/local-module/hello-module
$gotip work init ./ ../module-a
$cat go.work
go 1.18

directory (
    ./
    ../module-a
)

在这次init中,我们为init传入了两个路径,除了当前路径外,还将hello-module依赖的module-a在本地的路径传给了init,这样当前目录下的module与上层的module-a下的module就在同一个工作区当中了。接下来我们直接执行构建,go命令就可以在工作区顺利找到hello-module的依赖module-a了。

$gotip build
$./hello-module
this is a.A

三. 管理多module的工作区

最初这个proposal的名字就是multi modules workspace,即多module的工作区管理。当你的本地有很多module,且这些module存在相互依赖,那么我们可以在这些module的外面建立一个Go工作区,基于这个Go工作区开发与调试这些module就变得十分方便。

比如我们有三个module:a、b和c,其中a与b都依赖c。我们可以在a、b、c三个module路径的上一层创建一个Go工作区:

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/multi-modules
$go work init a b c
$cat go.work
go 1.18

directory (
    ./a
    ./b
    ./c
)

这之后,三个module:a、b和c就都在刚刚创建的这个go工作空间了,我们基于该工作空间便可以构建a与b,以构建a为例:

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/multi-modules
$gotip build -o a_bin github.com/bigwhite/a
$./a_bin
C in c

四. 小结

Go 1.18尚未发布,Go工作区还在active开发中,很多机制可能在后续的几个月还会发生变化。上面的内容仅仅是对Go工作空间做一个前瞻性的介绍,Go 1.18正式发布后,Go工作空间的机制和使用可能与目前有一定差别。

另外,go mod tidy目前并不care Go工作区,这块在原proposal有提到,大家注意!

go workspace特性的作者在油管曾发过一个go工作空间的demo视频:https://www.youtube.com/watch?v=wQglU5aB5NQ&feature=youtu.be,demo是基于最初的go工作区实现做的,大家也可以去看看。

本文所涉及的源码在这里下载:https://github.com/bigwhite/experiments/tree/master/go1.18-examples。


“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!部落目前虽小,但持续力很强,欢迎大家加入!

img{512x368}

img{512x368}
img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats