Redis | Tony Bai

标签 redis 下的文章

为什么有了Go module后“依赖地狱”问题依然存在

三月 12, 2022
2 条评论

本文永久链接 – https://tonybai.com/2022/03/12/dependency-hell-in-go

如果所有Gopher都抛弃GOPATH构建模式，拥抱Go module构建模式；如果所有legacy Go package作者都能为自己的legacy package加上go.mod；如果所有Go module作者都严格遵守语义版本(semver)规范，那么Go将彻底解决“依赖地狱”问题。

但现实却没那么乐观！Go中的“依赖地狱问题”依然存在。这一篇我们就来聊聊Go中依赖地狱的“发作场景”、原因以及解决方法。

1. 什么是“依赖地狱(dependency hell)”？

“依赖地狱”问题不是某种编程语言独有的问题，而是一个在软件开发和发布领域广泛存在问题。维基百科对该问题的广义诠释是这样的：

当几个软件包对相同的共享包或库有依赖性，但它们依赖于不同的、不兼容的共享包版本时，就会出现依赖性问题。如果共享包或库只能安装一个版本，用户可能需要通过获得较新或较旧版本的依赖包来解决这个问题。反过来，这可能会破坏其他的依赖关系。

在软件开发构建领域，我们会面对同样的“依赖地狱”问题。文字总是很难懂，我们用更为直观的示意图来说明什么是软件构建过程中的“依赖地狱”问题，大家先看看下面这个示意图：

我们看到在这幅图中：包P1依赖包P3 V1.5版本，包P2依赖包P3 V2.0版本，App同时依赖包P1和包P2。于是问题出现了：构建工具在构建App这个应用时需要决策究竟要使用包P3的哪个版本：V1.5还是V2.0？当然这个问题存在的一个前提是：App中只允许包含包P3的一个版本。

如果P3的V1.5与V2.0版本是不兼容的版本，那么构建工具无论选择包P3的哪个版本，App的构建都会以失败告终。开发人员只能介入手工解决，解决方法无非是将P1对P3的依赖升级到V2.0，或将P2对P3的依赖降级为V1.5版本。但P1、P2多数情况下是第三方开源包，App的开发人员对P1、P2包的作者的影响力有限，因此这种手工解决的成功率也不高。

“依赖地狱”(又称为“钻石依赖”问题)由来已久，几十年来各种编程语言都在努力解决这一问题，并也有了几种可以帮助到开发者的不错的方案。我们先来看看Go语言的解决方案。

2. Go的解决方案

在GOPATH构建模式时代，Go构建工具是无法自动解决上述“依赖地狱”问题的。Go 1.11版本引入Go module构建模式后，经过几年的打磨，Go module构建模式逐渐成熟，并已经成为Go构建模式的标准。

Go module构建模式是可以部分解决上述“依赖地狱”问题的。Go module解决这个问题的思路是：语义导入版本(sematic import versioning)，即在包的导入路径上加上包的major version前缀。关于“语义导入版本”的详细介绍，可以参考我的极客时间专栏“Go语言第一课”的相关内容。

使用“语义导入版本”后，Go解决上面那个问题的方案如下图：

我们看到：Go通过打破“App中只允许包含包P3的一个版本”这个前提实现了P1和P2各自使用自己依赖的版本。但这样做的前提是P1和P2依赖的P3版本的major版本号是不同的。在Go中，由于采用语义导入版本机制，major版本号不同的module被视为不同的module，即使它们源于同一个repository(比如上面的源于同一个P3的v1.5和v2.0就被视为两个不同的module)。

当然这种解决方案是有代价的！第一个代价就是构建出来的app的二进制文件size变大了，因为二进制文件中包含了多个版本的P3的代码；第二个代价，可能也算不上代价，更多是要注意的是不同版本的module之间的类型、变量、标识符不能混用，我们以go-redis/redis这个开源项目举个例子。go-redis/redis最新大版本为v8.11.4，没有启用go.mod时的版本为v6.x.x，我们将这两个版本混用在一起：

package main

import (
    "context"

    "github.com/go-redis/redis"
    redis8 "github.com/go-redis/redis/v8"
)

func main() {
    var rdb *redis8.Client
    rdb = redis.NewClient(&redis.Options{
        Addr:     "localhost:6379",
        Password: "", // no password set
        DB:       0,  // use default DB
    })
    _ = rdb
}

Go编译器在编译这段代码时会报如下错误：

cannot use redis.NewClient(&redis.Options{…}) (value of type *"github.com/go-redis/redis".Client) as type *"github.com/go-redis/redis/v8".Client in assignment

即redis v8下的Client与redis Client并非一个类型，即使它们的内部字段相同，也不能混用在一起。

那么，是不是说有了Go module构建机制后，“依赖地狱”问题就彻底从Go开发中被移除了呢？不是的。“依赖地狱”问题依旧存在，下面我们就来看看哪些情况下还会出现此类问题。

3. 哪些情形下“依赖地狱”依旧存在

1) 依赖不带go.mod的legacy Go包

如今Go语言引入Go module已经多年了，但Go社区仍然存在大量legacy的Go包尚未增加go.mod文件。对于这样的go包，Go命令的处理策略大致是这样的：

对于尚未打tag的go包，那么就按等同于v0/v1的方式处理

go命令将go包缓存在本地mod cache时，会合成一个go.mod文件，比如：

// $GOMODCACHE/cache/download
go.starlark.net
└── @v
    ├── list
    ├── list.lock
    ├── v0.0.0-20190702223751-32f345186213.mod // 这里是合成的go.mod
    ├── v0.0.0-20200821142938-949cc6f4b097.info
    ├── v0.0.0-20200821142938-949cc6f4b097.lock
    ├── v0.0.0-20200821142938-949cc6f4b097.mod // 这里是合成的go.mod
    ├── v0.0.0-20200821142938-949cc6f4b097.zip
    ├── v0.0.0-20200821142938-949cc6f4b097.ziphash
    ├── v0.0.0-20210901212718-87f333178d59.info
    └── v0.0.0-20210901212718-87f333178d59.mod // 这里是合成的go.mod

对于已经打了tag的go包且tag的major版本号<2，那么也按等同于v0/v1的方式处理

go命令将这样的go包缓存在本地mod cache时，同样会合成一个go.mod文件，比如：

// $GOMODCACHE/cache/download
pierrec
|-- lz4
|   |-- @v
|   |   |-- list
|   |   |-- v1.0.1.info
|   |   |-- v1.0.1.lock
|   |   |-- v1.0.1.mod // 这里是合成的go.mod
|   |   |-- v1.0.1.zip
|   |   |-- v1.0.1.ziphash

对于打了tag且tag的major版本号>=2的，Go命令将包下载到mod cache中后，同样会为该go包合成一个go.mod文件，该文件名vX.Y.Z+incompatible.mod，比如下面这个例子：

// $GOMODCACHE/cache/download
pierrec
|-- lz4
|   |-- @v
|   |   |-- list
|   |   |-- v2.6.1+incompatible.info
|   |   |-- v2.6.1+incompatible.lock
|   |   |-- v2.6.1+incompatible.mod // 这里是合成的go.mod
|   |   |-- v2.6.1+incompatible.zip
|   |   `-- v2.6.1+incompatible.ziphash

以上三种情况下，合成的.mod文件中的module root path都是不带vN后缀的，无论是否打tag，也不论tag major版本是否>=2，以v2.6.1+incompatible.mod为例，其内容如下：

// v2.6.1+incompatible.mod
module github.com/pierrec/lz4

我们看到，该合成的mod文件中也不包含这个legacy包自身所依赖的第三方包的require代码块。那么依赖lz4这个legacy包的项目如何确定lz4的第三方依赖的版本呢？并且lz4依赖的第三方包的版本记录在哪里呢？我们以app依赖github.com/pierrec/lz4为例，看下面示意图：

go mod命令在做依赖分析时，会根据源码中的import github.com/pierrec/lz4确定lz4的版本，由于没有vN后缀，go命令会找lz4的v2以下的源码中的go.mod，但lz4在这之前都没有添加go.mod，于是只能按照legacy的模式去确定lz4的版本，这里确定的是v2.6.1+incompatible，go命令将其作为app module的直接依赖：

require github.com/pierrec/lz4 v2.6.1+incompatible

之后go命令还会对lz4的依赖做分析，并将其记录到app module的go.mod中，作为indirect依赖：

require github.com/frankban/quicktest v1.14.2 //indirect

将直接依赖的legacy包的第三方依赖记录在自己的go.mod中是为了满足基于go.mod的可重现构建的要求。

好了！我们了解了go命令处理legacy go包的方式，再来看看如果出现“钻石依赖”情况下，Go命令是如何处理的？直接给结论，如下图：

在这幅图中，我们让P1依赖lz4的v1.0.1版本，让P2依赖lz4的v2.6.1+incompatible版本，这两个版本都是legacy（未添加go.mod）下打的tag。那么当app既依赖P1又依赖P2时，go命令会如何选择lz4的版本呢？Go命令简单粗暴的选择了同时满足P1和P2的最小版本：v2.6.1+incompatible。这里Go似乎做了一个假设：legacy包的新版本一定是向前兼容老版本的。对于lz4这个包来说，这个假设是正确的，我们对App的构建与执行不会遇到问题。

但是一旦这个假设不成立，比如：lz4的v2.6.1是一个不兼容v1.0.1的发布，那么App的构建将遇到错误。这种情况go命令是无能为力了，只能进行手工干预！那怎么干预呢？无非以下几种手段：

提issue督促P1作者将对lz4的依赖升级到最新v2.6.1版本

这种手段效率低不说，很可能P1的author根本就不会搭理你。

fork一个P1，自己修改，然后让App依赖你fork后的P1

这种手段可行，但后续就要自己维护一个fork的P1，无形中给自己增加了额外的负担。

vendor下来，自己修改，在vendor目录下维护

这种手段也可行，但后续只能使用vendor模式构建，且要自己维护一个本地的P1，同样也给自己增加了额外的负担。

那就没有更好的方法了么？真没有！从legacy项目到拥抱go module的项目的过渡过程注定是坎坷的。

2) 采用go module机制的依赖包的冲突问题

看完legacy包后，我们再来看依赖是采用go module机制的包的冲突问题。有了对上面例子理解的基础，理解下面的例子的就更容易了，我们来看下面示意图：

这个例子也很简单，P1和P2都依赖module P3，分别依赖P3的v1.1.0版本和v1.2.0版本，和之前的例子一样，App既依赖P1，也依赖P2，这样就构成了图中右侧的“钻石结构”。不过，Go module的另外一个机制：最小版本选择(MVS)可以很好的解决这个依赖问题，关于MVS的详情，同样可以参考我的极客时间专栏“Go语言第一课”的相关内容。

MVS机制同样是基于语义版本之上的，它会选择满足此App依赖的最小可用版本，这里P3的v1.1.0版本与v1.2.0版本的major版本号相同，因此按照语义版本规范，他们是兼容的版本，于是go命令选择了满足app依赖的最小可用版本为v1.2.0(此时P3的最高版本为v1.7.0，Go命令没有选择最高版本)。

不过理论约定与实际常常脱节，一旦P3的author在发布v1.2.0时没有识别出与v1.1.0的不兼容change，那么这种情况下，不兼容v1.1.0的P3版本会导致对P1包的构建失败！这就是采用go module机制的依赖包时最常见的“依赖地狱”问题。

可以看到，这个问题的根源还是在于go module的author。识别不兼容的change难吗？也不难，但的确繁琐，费脑子。那么作为module author, 如何尽量避免未按照语义版本规范发布版本号兼容实则不兼容的module版本呢？

Go社区的作法分为两类：

极端作法：
- 不发布1.0版本，一直在0.x.y，不承诺新版本兼容老版本；
- 每次发稍大一些的版本都升级major版本号，这样既避免了繁琐的检查是否有不兼容change的问题，也肯定不会给社区带去“依赖地狱”问题。
常规作法：
- 检查是否有不兼容change，只有在存在不兼容change的情况下，才升级major版本。

Go官博曾经发表过一篇名为《Keeping Your Modules Compatible》的文章，以告诉大家如何检查新的change中是否有不兼容的change。文中还提到Go团队已经开发了一个名为gorelease的工具来帮助Go开发者检测新版本与旧版本之间是否存在不兼容的变化(当然，工具也很可能不能完全扫描出来不兼容性change)，大家可以在这里查看gorelease的详细用法。

4. 未来畅想

近几年成长时候也很迅猛的Rust语言在面对“依赖地狱”这一问题上似乎走到了Go的前面，在《How Rust Solved Dependency Hell》一文中大致讲解了Rust解决这一问题的方案。其原理大致是利用的名字修饰，即同一个依赖的两个不兼容的版本可以共存与一个Rust应用中，每个版本中的标识符在应用中都是独一无二的，Rust通过包名、版本号等作为名字修饰以达到此目的。

那么，未来Go module是否能做到这点呢？笔者认为是可行的，并且是兼容于现在go module的机制的。Go module的引入，实则也是一种“namespace”的概念，具备像Rust那样解决问题的基础。但Go团队是否要这么做就是另当别论了，因为一旦Go语言世界像本文开篇中所提到的那样，那么现有机制也可以很好地解决“依赖地狱”问题。

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2022年，Gopher部落全面改版，将持续分享Go语言与Go应用领域的知识、技巧与实践，并增加诸多互动形式。欢迎大家加入！

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

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

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

十一月 26, 2021
0 条评论

本文永久链接 – 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}

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

我的联系方式：