本文永久链接 – 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语言生态的所有需求！部落目前虽小，但持续力很强，欢迎大家加入！

我爱发短信：企业级短信平台定制开发专家 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

微信赞赏：

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

本文翻译自Saif Sadiq的文章《Common anti-patterns in Go》。

众所周知，编码是一门艺术，就像每个拥有精湛艺术并为之感到骄傲的工匠一样，我们作为开发人员也为我们编写的代码感到自豪。为了获得最佳效果，艺术家不断寻找可提高其手艺的方法和工具。同样，作为开发人员，我们也在不断提高自己的技能，并对”如何写出好的代码”这个最重要的问题的答案保持好奇。

弗雷德里克·布鲁克斯（Frederick P. Brooks）在他的书《人月神话》中写道：

“程序员和诗人一样，工作时只是稍稍脱离了纯粹的思维定式。他在空气中建造他的城堡，通过发挥想象力进行创作。很少有一种创作媒介是如此灵活，如此容易打磨和重做，如此容易实现宏大的概念结构”。

这篇文章试图探索上面漫画中大问号的答案。编写良好代码的最简单方法是避免在我们编写的代码中包含反模式。

0. 什么是反模式

一个简单的反模式示例就是编写一个API，而无需考虑该API的使用者如何使用它，如下面的示例1所述。意识到反模式并有意识地避免在编程时使用它们，这无疑是朝着更具可读性和可维护性的代码库迈出的重要一步。在本文中，让我们看一下Go中一些常见的反模式。

当编写代码时没有未来的因素做出考虑时，就会出现反模式。反模式最初可能看起来是一个适当的问题解决方案，但是，实际上，随着代码库的扩大，这些反模式会变得模糊不清，并给我们的代码库添加“技术债务”。

反模式的一个简单例子是，在编写API时不考虑API的消费者如何使用它，就如下面例1那样。意识到反模式，并在编程时有意识地避免使用它们，肯定是迈向更可读和可维护的代码库的重要一步。在这篇文章中，我们来看看Go中常见的几种反模式。

1. 从导出函数(exported function)返回未导出类型(unexported type)的值

在Go中，要导出(export)任何一个字段(field)或变量(variable)，我们都需要确保其名称是以大写字母开头。导出(export)它们的动机是使它们对其他包可见。例如，如果要使用math包中的Pi函数，我们将其定义为math.Pi。而使用math.pi将无法正常工作，并且会报错。

以小写字母开头的名称（结构字段，函数或变量）不会被导出，并且仅在定义它们的包内可见。

使用返回未导出类型值的导出函数或方法可能会令人沮丧，因为其他包中的该函数的调用者将不得不再次定义一个类型才能使用它。

// 反模式
type unexportedType string

func ExportedFunc() unexportedType {
    return unexportedType("some string")
} 

// 推荐
type ExportedType string
func ExportedFunc() ExportedType {
    return ExportedType("some string")
}

2. 空白标识符的不必要使用

在各种情况下，将值赋值给空白标识符是不需要，也没有必要的。如果在for循环中使用空白标识符，Go规范中提到：

如果最后一个迭代变量是空白标识符，则range子句等效于没有该标识符的同一子句。

// 反模式
for _ = range sequence {
    run()
}
x, _ := someMap[key]
_ = <-ch 

// 推荐
for range something {
    run()
} 

x := someMap[key]
<-ch

3. 使用循环/多次append连接两个切片

将多个切片附加到一个切片时，无需遍历切片并一个接一个地附加(append)每个元素。相反，使用一个append语句执行此操作会更好，更有效率。

例如，下面的代码段通过迭代遍历元素逐个附加元素来连串连接sliceOne和sliceTwo：

for _, v := range sliceTwo {
    sliceOne = append(sliceOne, v)
}

但是，由于我们知道append是一个变长参数函数，我们可以使用零个或多个参数来调用它。因此，可以仅使用一个append函数调用来以更简单的方式重写上面的示例，如下所示：

sliceOne = append(sliceOne, sliceTwo…)

4. make调用中的冗余参数

该make函数是一个特殊的内置函数，用于分配和初始化map、slice或chan类型的对象。为了使用make初始化切片，我们必须提供切片的类型、切片的长度以及切片的容量作为参数。在使用make初始化map的情况下，我们需要传递map的大小作为参数。

但是，make的这些参数已经具有默认值：

• 对于channel，缓冲区容量默认为零（不带缓冲）。
• 对于map，分配的大小默认为较小的起始大小。
• 对于切片，如果省略容量，则容量参数的值默认为与长度相等。

所以，

ch = make(chan int, 0)
sl = make([]int, 1, 1)

可以改写为：

ch = make(chan int)
sl = make([]int, 1)

但是，出于调试或方便数学计算或平台特定代码的目的，将具名常量与channel一起使用不被视为反模式。

const c = 0
ch = make(chan int, c) // 不是反模式

5. 函数中无用的return

return在没有返回值的函数中作为最终语句不是一种好习惯。

// 没用的return，不推荐
func alwaysPrintFoofoo() {
    fmt.Println("foofoo")
    return
} 

// 推荐
func alwaysPrintFoo() {
    fmt.Println("foofoo")
}

但是，具名返回值的return不应与无用的return相混淆。下面的return语句实际上返回了一个值。

func printAndReturnFoofoo() (foofoo string) {
    foofoo := "foofoo"
    fmt.Println(foofoo)
    return
}

6. switch语句中无用的break语句

在Go中，switch语句不会自动fallthrough。在像C这样的编程语言中，如果前一个case语句块中缺少break语句，则执行将进入下一个case语句中。但是，人们发现，fallthrough的逻辑在switch-case中很少使用，并且经常会导致错误。因此，包括Go在内的许多现代编程语言都将switch-case的默认逻辑改为不fallthrough。

因此，在一个case case语句中，不需要将break语句作为最终语句。以下两个示例的行为相同。

反模式：

switch s {
case 1:
    fmt.Println("case one")
    break
case 2:
    fmt.Println("case two")
}

好的模式：

switch s {
case 1:
    fmt.Println("case one")
case 2:
    fmt.Println("case two")
}

但是，为了在Go中switch-case中实现fallthrough机制，我们可以使用fallthrough语句。例如，下面给出的代码段将打印23。

switch 2 {
case 1:
    fmt.Print("1")
    fallthrough
case 2:
    fmt.Print("2")
    fallthrough
case 3: fmt.Print("3")
}

7. 不使用辅助函数执行常见任务

对于一组特定的参数，某些函数具有一些特定表达方式，可以用来简化效率，并带来更好的理解/可读性。

例如，在Go中，要等待多个goroutine完成，可以使用sync.WaitGroup。通过将计数器的值-1直至0，以表示所有goroutine都已经执行完毕：

wg.Add(1) // ...some code
wg.Add(-1)

但使用sync包提供的辅助函数wg.Done()可以使代码更简单并容易理解。因为它本身会通知sync.WaitGroup所有goroutine即将完成，而无需我们手动将计数器减到0。

wg.Add(1)
// ...some code
wg.Done()

8. nil切片上的冗余检查

nil切片的长度为零。因此，在计算切片的长度之前，无需检查切片是否为nil切片。

例如，下面的nil检查是不必要的。

if x != nil && len(x) != 0 { // do something
}

上面的代码可以省略nil检查，如下所示：

if len(x) != 0 { // do something
}

9. 太复杂的函数字面量

可以删除仅调用单个函数且对函数内部的值没有做任何修改的函数字面量，因为它们是多余的。可以改为在外部函数直接调用被调用的内部函数。

例如：

fn := func(x int, y int) int { return add(x, y) }

可以简化为：

add(x, y)

译注：原文少了简化后的代码，这里根据译者的理解补充的。

10. 使用仅有一个case语句的select语句

select语句使goroutine等待多个通信操作。但是，如果只有一个case语句，实际上我们不需要使用select语句。在这种情况下，使用简单send或receive操作即可。如果我们打算在不阻塞地发送或接收操作的情况处理channel通信，则建议在select中添加一个default case以使该select语句变为非阻塞状态。

// 反模式
select {
    case x := <-ch: fmt.Println(x)
} 

// 推荐
x := <-ch
fmt.Println(x)

使用default:

select {
    case x := <-ch:
        fmt.Println(x)
    default:
        fmt.Println("default")
}

11. context.Context应该是函数的第一个参数

context.Context应该是第一个参数，一般命名为ctx.ctx应该是Go代码中很多函数的（非常）常用参数，由于在逻辑上把常用参数放在参数列表的第一个或最后一个比较好。为什么这么说呢？因为它的使用模式统一，可以帮助我们记住包含该参数。在Go中，由于变量可能只是参数列表中的最后一个，因此建议将context.Context作为第一个参数。各种项目，甚至Node.js等都有一些约定，比如错误先回调。因此，context.Context应该永远是函数的第一个参数，这是一个惯例。

// 反模式
func badPatternFunc(k favContextKey, ctx context.Context) {
    // do something
}

// 推荐
func goodPatternFunc(ctx context.Context, k favContextKey) {
    // do something
}

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，>每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需>求！部落目前虽小，但持续力很强。在2021年上半年，部落将策划两个专题系列分享，并且是部落独享哦：

• Go技术书籍的书摘和读书体会系列
• Go与eBPF系列

欢迎大家加入！

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中！本专栏主要满足>广大gopher关于Go语言进阶的需求，围绕如何写出地道且高质量Go代码给出50条有效实践建议，上线后收到一致好评！欢迎大家订
阅！

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网热卖>中，欢迎小伙伴们订阅学习！

我爱发短信：企业级短信平台定制开发专家 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

微信赞赏：

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