本文永久链接 – https://tonybai.com/2025/12/15/go-language-anti-patterns-10-donts

大家好，我是Tony Bai。

“有哪些‘不要做’的教训，是你花了好几年才学会的？”

近日，在 r/golang 社区，这个简单的问题，引爆了一场关于 Go 语言“反模式”与“最佳实践”的集体反思。帖子下数百条评论，汇集了无数 Gopher 在真实项目中用“血与泪”换来的宝贵经验。这些教训，往往不是关于某个高深的算法，而是关于那些看似“理所当然”，却在不经意间为代码埋下地雷的日常习惯。

这篇文章，正是对这场集体智慧的一次系统性梳理。我们从中提炼出 10 条最核心的“不要做”法则，它们如同一份“避坑指南”，能帮助你绕开那些最常见的陷阱，更快地从一名“会写 Go 的程序员”，成长为一名“懂 Go 的工程师”。

不要过度封装包

Don’t overpackage things

初学者往往有一种冲动，想把代码组织成“语义化”的、层层嵌套的包结构。internal/models, internal/services, internal/repositories…… 这种源自其他语言（如 Java）的模式，在 Go 的世界里，往往是一种过早的、不必要的复杂性。

社区忠告：从一个 main.go 文件开始。努力思考，是否真的有必要将代码拆分到多个文件/包中。Go 的包，其主要目的是封装和依赖管理，而不是单纯的文件夹分类。在小型或中型项目中，一个清晰的、扁平的包结构，远比一个复杂的“企业级”目录树更易于维护。

不要滥用 channel 和 goroutine

Don’t just add in channels

并发是 Go 的“名片”，这使得许多开发者（尤其是新手）有一种“锤子心态”——看到任何问题，都想用 goroutine 和 channel 来解决。然而，不必要的并发，是复杂性和 bug 的温床。

社区忠告：

• 先问“是否需要”：你真的需要并发吗？如果不需要在线程间传递消息，你可能根本不需要 channel。一个简单的 sync.WaitGroup 或 sync.Mutex，在很多场景下都比 channel 更简单、更直接。
• 并发不是免费的：Go 让创建 goroutine 变得异常简单，但这并不意味着它是零成本的。过多的 goroutine 会增加调度器的负担，而 channel 的滥用则会使数据流变得难以追踪和调试。

不要盲目追求 DRY

Don’t be zealous about DRY

DRY 是编程的基本原则，但在 Go 的哲学中，它有一个更重要的“上级”——清晰性。为了消除几行重复代码，而引入一个复杂的接口或一个晦涩的辅助函数，往往得不偿失。

社区忠告：“一点点复制，胜过一点点依赖 (a little copy-paste is better than a little dependency)。” 当你发现自己在为了 DRY 而绞尽脑汁时，请停下来问问自己：这份重复，是否真的带来了维护上的痛苦？如果不是，那么接受它，可能是一个更明智的选择。

不要在同一个 PR 中既重构又添加新功能

Don’t refactor and add features in the same PR

在添加一个新功能时，顺手“优化”一下周围的代码，这看起来很高效。但实际上，这会让 Code Review 变得异常痛苦。Reviewer 无法清晰地分辨，哪些改动是为新功能服务的，哪些是纯粹的重构。这不仅增加了审查的难度，也提高了引入新 Bug 的风险。

社区忠告：遵循“童子军军规”——“让营地比你来时更干净”——是好的。但请将它分解为两个独立的、目标明确的 PR：一个只做重构，另一个（基于重构后的代码）只添加新功能。

不要跳过写测试，“就这一次”

Don’t skip writing tests “just this once”

这是所有开发者都曾屈服过的诱惑。“这个改动太小了”、“我百分之百确定它是对的”、“项目赶时间”…… 每一次“就这一次”的妥协，都在为未来的“技术雪崩”添砖加瓦。

社区忠告：将测试视为代码不可分割的一部分。在 Go 中，编写测试是如此简单和自然，以至于没有任何借口可以跳过它。你今天节省下来的 10 分钟，可能会在未来，让你或你的同事，花费数天时间去调试一个本可避免的生产问题。

不要害怕使用 sync.Cond

channel 非常强大，但它并非解决所有并发同步问题的“银弹”。社区中有一种“反 sync”的情绪，认为所有同步都应该用 channel 来完成。

社区忠告：sync.Cond 是一个被低估了的、极其强大的并发原语。当你需要基于某个特定条件来唤醒一个或多个等待的 goroutine 时（例如，一个任务队列的消费者在队列为空时等待），sync.Cond 往往比用 channel 实现的复杂信令机制，要更简单、更高效。不要因为不熟悉，就回避它。

不要返回接口

Returning interfaces. Don’t do it.

在函数签名中返回一个接口，看似遵循了“依赖倒置”的高级原则，甚至觉得这样更“灵活”。但实际上，这往往是一种过早的、有害的抽象。它剥夺了用户访问底层具体类型特有功能的能力，并且如果未来需要添加新方法，接口的变更会极其痛苦。

社区忠告：遵循 Go 的经典谚语：“接收接口，返回结构体 (Accept interfaces, return structs)。”

• 接收接口：让你的函数接收一个只包含其所需最小方法集的接口作为参数。这使得你的函数更容易被测试和复用（你可以传入任何满足该接口的实现，包括 Mock 对象）。
• 返回结构体：让你的函数返回一个具体的类型（通常是指针）。这给了调用者最大的灵活性。

经典范例：

看看标准库中的 os.Open，它返回的是 *os.File（具体结构体），而不是 io.Reader（接口）。
* 为什么这样做？ 因为 *os.File 不仅能读（Read），还能关闭（Close）、获取状态（Stat）、甚至改变权限（Chmod）。
* 灵活性：如果它返回的是接口，用户就无法使用 Chmod 等特有功能了。而返回结构体，用户既可以使用其全部功能，也可以在需要时，轻松地将其赋值给 io.Reader 接口来使用。这就是“返回结构体”带来的自由。

(注：只有当返回的类型是包内私有的、不希望外部直接访问的实现细节时，返回接口才是有意义的，例如 context.WithCancel 返回的是 Context 接口。)

不要过度依赖依赖

Don’t add dependencies without vetting

为了解决一个小问题，而引入一个庞大的、闪亮的第三方库。这在 Node.js 生态中很常见，但在 Go 社区，这通常被视为一种“危险信号”。

社区忠告：

• 先求诸标准库：在引入任何依赖之前，先问问自己：这个问题，标准库真的解决不了吗？
• 审慎评估：如果必须引入依赖，请仔细评估它：它的依赖树有多深？社区是否活跃？维护者是否可靠？一个简单的依赖，可能会为你整个项目，带来潜在的供应链安全风险和维护噩梦。

不要盲从

Don’t do [or not do] something simply because an authoritative voice recommended it

盲目地遵循某个“大神”、某篇“爆款”博客文章、或者某个“权威”推荐的模式，而没有结合自己的具体场景进行批判性思考。

社区忠告：上下文决定一切。YAGNI (You Aren’t Gonna Need It) 是一个好原则，但有时你确实需要提前设计。微服务很好，但有时单体就是最佳选择。没有银弹。最好的实践，是那些在你的团队、你的项目中，被证明行之有效的实践。

不要忘记，代码是给人读的

忘记了代码的最终读者是人类，而不是编译器。编写只有自己能看懂的“聪明”代码，或者忽略文档和注释的重要性。

社区忠告：

• 编写能让你的未来“自已”不会痛骂你的代码。
• 好的设计不是增加，而是保持本质的简单。代码即是负债 (Code is liability)。
• 不要忽视清晰文档的重要性。

小结：在“坑”里成长

这份清单，远非全部。社区的讨论中还充满了诸如“不要用 singleton 来做 mock”、“不要滥用 init 函数”、“不要在疲劳时 Review 代码”等无数宝贵的经验。

它们共同指向了一个核心思想：成为一名优秀的 Go 工程师，其过程不仅仅是学习语言的特性，更是一个不断反思、不断“踩坑”、并从“坑”中总结出属于自己“不要做”清单的修炼过程。希望这份来自社区的集体智慧，能让你在这条路上，走得更稳、也更远。

资料链接：https://www.reddit.com/r/golang/comments/1pib68y/whats_a_dont_do_this_lesson_that_took_you_years/

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/09/30/good-taste-in-software-engineering

大家好，我是Tony Bai。

在软件工程领域，我们习惯于用“技术能力”（Technical Skill）来衡量一位工程师的优劣。他是否精通并发模型？能否写出高性能的代码？对底层原理的理解有多深？这些能力可以通过学习和重复练习来获得，是我们评价体系中的“硬通货”。

然而，github工程师Sean Goedecke在他最新的博文中，提出了一个新的观点：决定工程师成长上限的是“技术品味”（Technical Taste）。他认为，“品味”与“能力”是两个正交的维度。你可以技术能力很强，但品味很差；也可以技术尚在发展，但已具备良好的品味。就像一个美食家，即使自己不会烹饪，也能分辨出食物的好坏。同样，一个有品味的工程师，在能亲手构建一个复杂系统之前，就已经知道自己喜欢什么样的软件。在文章中，他还特意以Go的一些语法特性举例，来诠释什么是工程品味。

在这篇文章中，我们将一起拆解“技术品味”这个看似玄妙的概念，学习如何识别自己和他人身上的“坏品味”（比如对“最佳实践”的盲从），并探索一条培养“好品味”的实践路径，帮助我们Go开发者在日常的权衡与决策中，做出更成熟的选择。

“品味”不是“对错”，而是“价值观”的排序

文章以一个经典的例子开场：for循环 vs. map/filter。

许多来自函数式编程背景的开发者会认为，使用map/filter的代码“看起来更美”，因为它们通常涉及纯函数，易于推理，还能避免一类的迭代器bug。这似乎是一个关乎“正确”与“错误”的技术问题。

然而，Go语言的设计者们，出于“有原则的理由”，并没有在语言核心中原生内置map/filter。在Go中，一个简单的for循环：

• 性能上更易于推理：没有高阶函数调用的开销。
• 更灵活：可以轻松扩展到更复杂的迭代策略（如一次处理两个或多个元素）。

这个分歧的本质是什么？Goedecke一针见血地指出：这不是一个关于技术能力高低的争论，而是一个关于“工程价值观”（Engineering Values）优先级排序的差异。

• 偏爱map/filter的工程师，可能将“表达力”和“数学上的优雅”排在了更高的位置。
• 偏爱for循环的Go语言设计者们，则将“性能透明度”和“实现的直接性”置于首位。

成熟的工程师，能够理解并承认这种差异源于价值观的不同，而非技能的缺失。

什么是工程中的“好品味”？

几乎所有软件工程决策都是一次权衡（tradeoff）。

你很少能在两个选项中找到一个绝对更优的。你总是在不同的工程价值观之间做艰难的取舍，比如在“性能”和“可读性”之间，或者在“开发速度”和“正确性”之间。

不成熟的工程师会固执己见，认为“X永远比Y好”。而成熟的工程师则会评估双方的优劣，并思考：“在当前这个特定的项目中，X的收益是否大于Y的收益？”

因此，Goedecke对“技术品味”给出了一个精辟的定义：

Taste is the ability to adopt the set of engineering values that fit your current project.
(品味，是为当前项目选择一套恰如其分的工程价值观的能力。)

你的个人技术偏好，构成了你的基础“品味”。而“好品味”，则是在这个基础上，根据项目所处的真实环境（团队能力、业务阶段、性能要求、交付压力等），灵活调整你的价值观优先级的能力。

如何识别“坏品味”？—— “最佳实践”的诅咒

“坏品味”最常见的表现形式，就是僵化（inflexibility）。

I will always distrust engineers who justify decisions by saying “it’s best practice”.
(我永远不信任那些用“这是最佳实践”来为决策辩护的工程师。)

没有任何工程决策是在所有情境下的“最佳实践”。

当你听到有人用这个词时，往往意味着他正在将过去某个项目的成功经验（那套当时恰好适用的价值观），僵化地、不加思考地套用到一个全新的问题上。

• 一个在金融科技公司追求“五个九”可用性的工程师，如果将同样的价值观带到一个需要快速迭代验证想法的初创公司，坚持为内部仪表盘构建跨区域部署，那就是“坏品味”。这会让项目变得复杂无比，难以理解，拖慢了产品发布的速度，甚至导致了失去市场的机会。
• 一个习惯于用Ruby元编程“炫技”的开发者，如果在一个追求长期可维护性的Go项目中，滥用reflect来实现类似的动态能力，那也是“坏品味”。

Goedecke用了一个绝妙的比喻：品味差的工程师就像一块坏掉的指南针。在一块特定的磁场里（比如他之前工作的领域），这块坏指南针可能恰好能指向北方，让他看起来非常高效。但一旦环境变化（换了项目或公司），这块指南针就会立刻将团队引向错误的方向。

如何培养“好品味”？—— 拥抱灵活性与真实世界

培养技术能力有明确的路径：读书、练习、看代码。而培养“技术品味”则更为神秘。Goedecke给出的建议是：

1. 涉猎多样化的项目：在不同类型、不同阶段、不同需求的项目中工作。密切关注在这些项目中，哪些部分做起来很“容易”，哪些又异常“艰难”。
2. 聚焦于灵活性：刻意避免形成关于“编写软件的唯一正确方式”的强烈、普适性的观点。始终保持开放，愿意倾听和理解那些与你价值观相悖的观点。
3. 拥抱真实世界的混乱：“好品味”无法在玩具问题或技术问答中得到检验。你必须投身于一个真实的、充满了各种混乱约束的实际问题中，才能锻炼你在多重约束下做出最佳权衡的能力。

小结：从理解“品味”，到成为更好的Gopher

综上所述，Sean Goedecke为我们揭示了一个深刻的层次：“技术品味”是超越“技术能力”的、衡量工程师成熟度的关键标尺。 文章的核心不在于掌握多少工具，而在于面对具体问题时，能否为之匹配一套恰如其分的工程价值观。这正是成熟与僵化、权衡与教条、情境与普适之间的分水岭。一个工程师的成长上限，或许就取决于他/她能否从固守个人偏好，进化到为项目选择最佳价值排序的“好品味”阶段。

这套关于“品味”的哲学，在Go的语境中显得尤为贴切，甚至可以说，它完美地解释了Go语言及其社区文化的形成。

Go语言本身，就是其设计者们“好品味”的结晶。他们没有盲目追随当时其他语言的风潮，而是为“构建大型、可维护的网络服务”这一特定问题，选择了一套恰如其分的工程价值观——将简单性、可读性和性能透明度置于极高的优先级。

这门语言的设计，反过来也在塑造着我们的“品味”。它通过“做减法”，有意地减少了语言的“魔法”，迫使开发者回归到问题的本质，进行更多的第一性原理思考，而不是依赖于复杂的框架或语法糖。在Go社区所推崇的“务实主义”、“显式优于隐式”，以及对“最佳实践”的天然警惕，本质上都是一种对情境化“好品味”的追求。

只有理解了为什么Go是现在这个样子，我们才能在使用这门语言时，做出同样充满“品味”的、与项目需求相匹配的决策，从而真正发挥出Go语言的全部威力，成为一名真正成熟的软件工程师。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2025, bigwhite. 版权所有.

Go语言是Google大牛团队(Robert Griesemer、Rob Pike以及Ken Thompson)设计的一种静态类型、编译型编程语言，支持垃圾回收和轻量级并发，它于2009年11月诞生，一面世就以语法简单、原生支持并发、标准库强大、工具链丰富等优点吸引了大量开发者。经过10余年演化和发展，Go如今已成为云基础架构的标准编程语言，很多云原生时代的杀手级平台、中间件、协议和应用都是采用Go语言开发的，比如：Docker、Kubernetes、以太坊、Hyperledger Fabric超级账本、新一代互联网基础设施协议ipfs等。

Go是一门特别容易入门的编程语言，无论是刚出校门的新手还是从其他编程语言转过来的成手，都可以在短时间内快速掌握Go语法并投入到Go代码的编写中。但笔者在日常收到很多Go初学者的疑问：Go入门容易，但进阶难，怎么才能像Go团队那样写出符合Go思维和语言惯例(idiomatic)的高质量代码呢？

这个问题也引发了我的思考。在2017年GopherChina大会上笔者以演讲的形式初次尝试回答这个问题，但鉴于演讲的时长有限，很多内容难于展开，效果不甚理想。而这个慕课网专栏则是我对解答这个问题作出的第二次尝试。

这次解答的思路有两个：

• 思维层面：写出高质量Go代码的前提是思维方式的进阶，即使用Go语言的思维去写Go代码；
• 实践技巧层面：Go标准库、优秀Go开源库是一个挖倔高质量、符合Go惯用法的Go代码的宝库，对其进行阅读、挖掘和整理归纳，我们可以得到一些帮助我们快速进阶的有效实践。

本专栏正是基于上面思路为想实现Go进阶但又不知从何入手的你而设的。

首届图灵奖得主、著名计算机科学家艾伦·佩利(Alan J. Perlis)曾经说过：“不能影响到你的编程思维方式的编程语言不值得去学习和使用”，足见编程思维对编程语言学习和应用的重要性。只有真正领悟了一门编程语言的设计哲学和编程思维，并将其应用到日常编程当中去，你才算是真正地实现了在这门编程语言上的进阶。

因此，本专栏首先将带领大家回顾Go语言的演化历史，一起了解并深刻体会Go大牛们在设计Go语言时的所思所想，与大牛们实现思维上的共鸣，理清那些看似随意的，实则经过深思熟虑的设计的背后的付出。

接下来，本专栏将基于笔者对Go核心团队、Go社区高质量代码的分析归纳，从代码风格、基础语法、函数/方法、接口、并发、错误处理、测试调试、标准库、工程实践等多个方面给出改善Go代码质量，写出符合Go思维和惯例的代码的有效实践。

学习了本专栏的这50条有效实践，你将拥有和Go大牛们一样Go编程思维，写出符合Go惯例风格的高质量Go代码，从众多Go入门选手中脱颖而出，快速实现从Go编程新手到专家的转变！

本专栏共分10个模块(篇)，50个小节。

• 模块1：设计哲学篇

本专栏的开篇和总起。和读者一起穿越时空，回顾历史，详细了解Go语言的诞生、演化以及今天的发展。归纳总结Go语言的设计哲学和原生编程思维，让读者可以站在语言设计者的高度理解Go语言与众不同的设计，在更高层次，形成共鸣，产生认同。只有强烈认同，才能更上一层楼。

• 模块2：代码风格篇

每种编程语言都有自己惯用的代码风格，而遵循语言惯用风格是高质量Go代码的必要条件。本篇详细介绍了得到公认且广泛使用的Go工程的结构布局、代码风格标准、标识符命名惯例以及变量声明形式等。

• 模块3：基础语法篇

本模块详述在基础语法层面高质量Go代码的惯用法和有效实践，涵盖无类型常量的作用、定义Go的“枚举常量”、“零值可用”类型的意义、切片原理以及其高效的原因、Go包导入路径的真正含义等。

• 模块4：函数与方法篇

函数和方法是Go程序的基本组成单元。本模块聚焦于函数与方法的设计与实现，涵盖init函数的使用、跻身“一等公民”行列的函数有何不同、Go方法的本质等帮助读者深入理解它们的内容。

• 模块5：接口篇

接口是Go语言中的“魔法师”。本模块将聚焦接口，涵盖接口的设计惯例、使用接口类型的注意事项以及接口类型对代码可测试性的影响等。

• 模块6：并发编程篇

Go以其轻量级的并发模型而闻名。本模块将详细介绍Go基本执行单元 – goroutine的调度原理、Go并发模型以及常见并发模式、Go支持并发的原生类型-channel的惯用使用模式等内容。

• 模块7：错误处理篇

Go语言十分重视错误处理，它有着相对保守的设计和显式处理错误的惯例。本模块将涵盖Go错误处理的哲学以及在这套哲学下一些常见错误处理问题的优秀实践方案。

• 模块8：测试与调试篇

Go自带强大且为人所称道的工具链，本模块将详细介绍Go在单元测试、性能测试以及代码调试方面的最佳实践方案。

• 模块9：标准库篇

Go拥有功能强大且质量上乘的标准库，多数情况我们仅使用标准库所提供的功能而不借助第三方库就可实现应用的大部分功能，这大幅降低学习成本以及代码依赖的管理成本。本模块将详细说明高频使用的标准库包，如net/http、strings、bytes、time等的正确使用方式，以及reflect包、cgo在使用时的注意事项。

• 模块10：工程实践篇

本模块将涵盖我们使用Go语言做软件项目过程中很大可能会遇到的一些工程问题的解决方法，包括：使用module进行Go包依赖管理、Go应用容器镜像、Go相关工具使用以及Go语言的避“坑”指南。

从上述专栏结构，我们也能看出本专栏并不是Go入门的最佳选择。如果非要给本专栏划定一个目标人群，或者说哪些读者阅读本专栏后会更多受益，我觉得是那些已经迈入Go语言世界、但迫切希望进一步提升层次、写出高质量Go代码的Go开发者。

很多朋友可能会问？你这个专栏有何与众不同之处？在专栏上线前编辑老师也让我编写课程亮点，我觉得下面这几句话可以概括专栏的特点：

• 进阶必备 – 50个有效实践助你掌握高效Go程序设计之道；
• 高屋建瓴 – Go设计哲学与编程思想先行；
• 深入浅出 – 原理深入，例子简明，讲解透彻；
• 图文并茂 – 大量图表辅助学习，重点难点轻松掌控；
• 覆盖全面 – 覆盖高级面试知识点，求职更自信。

本专栏第一次落笔大约在Go 1.12发布后，大约将在今年10月份，即在Go 1.15发布后的第二个月完成。这中间有一定的跨度，因此专栏内的有些内容在各个Go版本间可能会有差异。笔者在内容中已经尽量做了版本适用标识，但难免有疏漏。各位读者在遇到问题时，可以及时反馈给我。

此外，Go语言还在飞速发展，一些当前的惯用表达方式或有效实践可能在日后因语言引入新的特性(比如：Go泛型)而“过时”。我会在我的博客上持续关注Go语言的演化，并将最新的Go高效编程实践分享给大家。

最后再来一次自我介绍：Tony Bai，Go语言技术专家和鼓吹者，GopherChina大会讲师，Go语言技术博客tonybai.com的作者，GopherDaily(Go日报)项目(github.com/bigwhite/gopherdaily)维护者，OSCHINA源创会技术讲师，《七周七语言》译者之一，慕课网《Kubernetes实战：高可用集群搭建、配置、运维与应用》作者，开源拥趸。

作为一名在国内接触Go语言较早(2012年)的Gopher和Go布道师，Tony Bai拥有丰富的Go开发知识和经验。他在个人博客上撰写了大量关于Go语言的文章，并深受Go社区欢迎。目前他正在国内一大型软件公司带领团队使用Go语言构建移动运营商的5G消息平台，这个平台将处理来自全国各地几十万个5G chatbot程序每天发送的几十亿条5G消息请求。

欢迎大家订阅我的专栏! 如有意见和建议，可在我本博文后面的评论中反馈。感谢大家支持。

专栏涉及的源码仓库地址：https://github.com/bigwhite/publication/tree/master/column/imooc/go-50tips/sources

我的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

微信赞赏：

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

© 2020 – 2021, bigwhite. 版权所有.

一、优雅退出的原理

对于服务程序而言，一般都是以daemon形式运行在后台的。通知这些服务程序退出需要使用到系统的signal机制。一般服务程序都会监听某个 特定的退出signal，比如SIGINT、SIGTERM等（通过kill -l命令你可以查看到几十种signal）。当我们使用kill + 进程号时，系统会默认发送一个SIGTERM给相应的进程。该进程通过signal handler响应这一信号，并在这个handler中完成相应的“优雅退出”操作。

与“优雅退出”对立的是“暴力退出”，也就是我们常说的使用kill -9，也就是kill -s SIGKILL + 进程号，这个行为不会给目标进程任何时间空隙，而是直接将进程杀死，无论进程当前在做何种操作。这种操作常常导致“不一致”状态的出现。SIGKILL这 个信号比较特殊，进程无法有效监听该信号，无法有效针对该信号设置handler，无法改变其信号的默认处理行为。

二、测试用“服务程序”

为了测试docker容器对优雅退出的支持，我们编写如下“服务程序”用于放在docker容器中运行：

//dockerapp1.go

package main

import "fmt"
import "time"
import "os"
import "os/signal"
import "syscall"

type signalHandler func(s os.Signal, arg interface{})

type signalSet struct {
        m map[os.Signal]signalHandler
}

func signalSetNew() *signalSet {
        ss := new(signalSet)
        ss.m = make(map[os.Signal]signalHandler)
        return ss
}

func (set *signalSet) register(s os.Signal, handler signalHandler) {
        if _, found := set.m[s]; !found {
                set.m[s] = handler
        }
}

func (set *signalSet) handle(sig os.Signal, arg interface{}) (err error) {
        if _, found := set.m[sig]; found {
                set.m[sig](sig, arg)
                return nil
        } else {
                return fmt.Errorf("No handler available for signal %v", sig)
        }

        panic("won't reach here")
}

func main() {
        go sysSignalHandleDemo()
        time.Sleep(time.Hour) // make the main goroutine wait!
}

func sysSignalHandleDemo() {
        ss := signalSetNew()
        handler := func(s os.Signal, arg interface{}) {
                fmt.Printf("handle signal: %v\n", s)
                if s == syscall.SIGTERM {
                        fmt.Printf("signal termiate received, app exit normally\n")
                        os.Exit(0)
                }
        }

        ss.register(syscall.SIGINT, handler)
        ss.register(syscall.SIGUSR1, handler)
        ss.register(syscall.SIGUSR2, handler)
        ss.register(syscall.SIGTERM, handler)

        for {
                c := make(chan os.Signal)
                var sigs []os.Signal
                for sig := range ss.m {
                        sigs = append(sigs, sig)
                }
                signal.Notify(c)
                sig := <-c

                err := ss.handle(sig, nil)
                if err != nil {
                        fmt.Printf("unknown signal received: %v, app exit unexpectedly\n", sig)
                        os.Exit(1)
                }
        }
}

关于Go语言对系统Signal的处理，可以参考《Go中的系统Signal处理》一文。

三、制作测试用docker image

在《 Ubuntu Server 14.04安装docker》一文中，我们完成了在ubuntu 14.04上安装docker的步骤。要制作测试用docker image，我们首先需要pull一个base image。我们以CentOS6.5为例：

在Ubuntu 14.04上执行：
    sudo  docker pull centos:centos6

docker会自动从官方仓库下载一个制作好的docker image。下载成功后，我们可以run一下试试，像这样：

$> sudo docker run -t -i centos:centos6 /bin/bash

我们查看一下CentOS6的小版本：
$> cat /etc/centos-release
CentOS release 6.5 (Final)

这是一个极其精简的CentOS，各种工具均未安装：
bash-4.1# telnet
bash: telnet: command not found
bash-4.1# ssh
bash: ssh: command not found
bash-4.1# ftp
bash: ftp: command not found
bash-4.1# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

如果你要安装一些必要的工具，可以直接使用yum install，默认的base image已经将yum配置好了，可以直接使用。如果通过公司代理访问外部网络，别忘了先export http_proxy。另外docker直接使用宿主机的/etc/resolv.conf作为容器的DNS，我们也无需额外设置DNS。

接下来，我们就制作我们的第一个测试用image。安装官方推荐的Best Practice，我们使用Dockerfile来bulid一个测试用image。步骤如下：

- 建立~/ImagesFactory目录
- 将构建好的dockerapp1拷贝到~/ImagesFactory目录下
- 进入~/ImagesFactory目录，创建Dockerfile文件，Dockerfile内容如下：

FROM centos:centos6
MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
COPY ./dockerapp1 /bin
CMD /bin/dockerapp1

- 执行docker build，结果如下：

$ sudo docker build -t="test:v1" ./
Sending build context to Docker daemon 7.496 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
 —> 68edf809afe7
Step 1 : MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
 —> Using cache
 —> c617b456934a
Step 2 : COPY ./dockerapp1 /bin
2014/10/09 16:05:25 lchown /var/lib/docker/aufs/mnt/fb0e864d3f07ca17ef8b6b69f034728e1f1158fd3f9c83fa48243054b2f26958/bin/dockerapp1: not a directory

居然build失败，提示什么not a directory。于是各种Search，终于发现问题所在，原来是“COPY ./dockerapp1 /bin”这条命令错了，少了个“/”，将" /bin"改为“/bin/”就OK了，Docker真是奇怪啊，这块明显应该做得更兼容些。新的Dockerfile如下：

FROM centos:centos6
MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
COPY ./dockerapp1 /bin/
CMD /bin/dockerapp1

构建结果如下：

$ sudo docker build -t="test:v1" ./
Sending build context to Docker daemon 7.496 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
 —> 68edf809afe7
Step 1 : MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
 —> Using cache
 —> c617b456934a
Step 2 : COPY ./dockerapp1 /bin/
 —> 20c3783c42ab
Removing intermediate container cab639ab4321
Step 3 : CMD /bin/dockerapp1
 —> Running in 31875d3c37f9
 —> 21a720a808a7
Removing intermediate container 31875d3c37f9
Successfully built 21a720a808a7

$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
test                v1                  21a720a808a7        59 seconds ago      214.6 MB

四、第一个测试容器

我们基于image "test:v1"启动一个测试容器：

$ sudo docker run -d "test:v1"
daf3ae88fec23a31cde9f6b9a3f40057953c87b56cca982143616f738a84dcba

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS               NAMES
daf3ae88fec2        test:v1             "/bin/sh -c /bin/doc   17 seconds ago      Up 16 seconds                           condescending_sammet  

通过docker run命令，我们基于image"test:v1"启动了一个容器。通过docker ps命令可以看到容器成功启动，容器id：daf3ae88fec2，别名为：condescending_sammet。

根据Dockerfile我们知道，容器启动后将执行"/bin/dockerapp1"这个程序，dockerapp1退出，容器即退出。 run命令的"-d"选项表示容器将以daemon的形式运行，我们在前台无法看到容器的输出。那么我们怎么查看容器的输出呢？我们可以通过 docker logs + 容器id的方式查看容器内应用的标准输出或标准错误。我们也可以进入容器来查看。

进入容器有多种方法，比如用sudo docker attach daf3ae88fec2。attach后，就好比将daemon方式运行的容器 拿到了前台，你可以Ctrl + C一下，可以看到如下dockerapp1的输出:

^Chandle signal: interrupt

另外一种方式是利用nsenter工具进入我们容器的namespace空间。ubuntu 14.04下可以通过如下方式安装该工具：

$ wget https://www.kernel.org/pub/linux/utils/util-linux/v2.24/util-linux-2.24.tar.gz; tar xzvf util-linux-2.24.tar.gz
$ cd util-linux-2.24
$ ./configure –without-ncurses && make nsenter
$ sudo cp nsenter /usr/local/bin

安装后，我们通过如下方式即可进入上面的容器：

$ echo $(sudo docker inspect –format "{{ .State.Pid }}" daf3ae88fec2)
5494
$ sudo nsenter –target 5494 –mount –uts –ipc –net –pid
-bash-4.1# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 09:20 ?        00:00:00 /bin/dockerapp1
root        16     0  0 09:32 ?        00:00:00 -bash
root        27    16  0 09:32 ?        00:00:00 ps -ef
-bash-4.1#

进入容器后通过ps命令可以看到正在运行的dockerapp1程序。在容器内，我们可以通过kill来测试dockerapp1的运行情况：

-bash-4.1# kill -s SIGINT 1

通过前面的attach窗口，我们可以看到dockerapp1输出:

handle signal: interrupt

如果你发送SIGTERM信号，那么dockerapp1将终止运行，容器也就停止了。

-bash-4.1# kill 1

attach窗口显示：

signal termiate received, app exit normally

我们可以看到容器启动后默认执行的时Dockerfile中的CMD命令，如果Dockerfile中有多行CMD命令，Docker在启动容器 时只会执行最后一条CMD命令。如果在docker run中指定了命令，docker则会执行命令行中的命令而不会执行dockerapp1，比如：

$ sudo docker run -t -i "test:v1" /bin/bash
bash-4.1#

这里我们看到直接执行的时bash，dockerapp1并未执行。

五、docker stop的行为

我们先来看看docker stop的manual：

$ sudo docker stop –help
Usage: docker stop [OPTIONS] CONTAINER [CONTAINER...]
Stop a running container by sending SIGTERM and then SIGKILL after a grace period
  -t, –time=10      Number of seconds to wait for the container to stop before killing it. Default is 10 seconds.

可以看出当我们执行docker stop时，docker会首先向容器内的当前主程序发送一个SIGTERM信号，用于容器内程序的退出。如果容器在收到SIGTERM后没有马上退出， 那么stop命令会在等待一段时间（默认是10s）后，再向容器发送SIGKILL信号，将容器杀死，变为退出状态。

我们来验证一下docker stop的行为。启动刚才那个容器：

$ sudo docker start daf3ae88fec2
daf3ae88fec2

attach到容器daf3ae88fec2
$ sudo docker attach daf3ae88fec2

新打开一个窗口，执行docker stop命令：
$ sudo docker stop daf3ae88fec2
daf3ae88fec2

可以看到attach窗口输出：
handle signal: terminated
signal termiate received, app exit normally

通过docker ps查看，发现容器已经退出。

也许通过上面的例子还不能直观的展示stop命令的两阶段行为，因为dockerapp1收到SIGTERM后直接就退出 了，stop命令无需等待容器慢慢退出，也无需发送SIGKILL。我们改造一下dockerapp1这个程序。

我们复制一下dockerapp1.go为dockerapp2.go，编辑dockerapp2.go，将handler中对SIGTERM的 处理注释掉，其他不变：

handler := func(s os.Signal, arg interface{}) {
                fmt.Printf("handle signal: %v\n", s)
                /*
                if s == syscall.SIGTERM {
                        fmt.Printf("signal termiate received, app exit normally\n")
                        os.Exit(0)
                }
                */
        }

我们使用dockerapp2来构建一个新image：test:v2，将Dockerfile中得dockerapp1换成 dockerapp2即可。

$ sudo docker build -t="test:v2" ./
Sending build context to Docker daemon 9.369 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
 —> 68edf809afe7
Step 1 : MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
 —> Using cache
 —> c617b456934a
Step 2 : COPY ./dockerapp2 /bin/
 —> 27cd613a9bd7
Removing intermediate container 07c760b6223b
Step 3 : CMD /bin/dockerapp2
 —> Running in 1aac086452a7
 —> 82eb876fefd2
Removing intermediate container 1aac086452a7
Successfully built 82eb876fefd2

利用image "test:v2"创建一个容器来测试stop。

$ sudo docker run -d "test:v2"
29f3ec1af3c355458cbbd802a5e8a53da28e9f51a56ce822c7bba2a772edceac

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS               NAMES
29f3ec1af3c3        test:v2             "/bin/sh -c /bin/doc   7 seconds ago       Up 6 seconds                            romantic_feynman   

Attach到这个容器并观察，在另外一个窗口stop该container。我们在attach窗口只看到如下输出：

handle signal: terminated

stop命令的执行没有立即返回，而是等待容器退出。等待10s后，容器退出，stop命令执行结束。从这个例子我们可以明显看出stop的两阶 段行为。

如果我们以sudo docker run -i -t "test:v1" /bin/bash形式启动容器，那stop命令会将SIGTERM发送给bash这个程序，即使你通过nsenter进入容 器，启动了dockerapp1，dockerapp1也不会收到SIGTERM，dockerapp1会随着容器的退出而被强行终止，就像被 kill -9了一样。

六、多进程容器服务程序

上面无论是dockerapp1还是dockerapp2，都是一个单进程服务程序。如果我们在容器内执行一个多进程程序，我们该如何优雅退出 呢？我们先来编写一个多进程的服务程序dockerapp3：

在dockerapp1.go的基础上对main和sysSignalHandleDemo进行修改形成dockerapp3.go，修改后这两 个函数的代码如下：

//dockerapp3.go
… …

func main() {
        go sysSignalHandleDemo()

        pid, _, err := syscall.RawSyscall(syscall.SYS_FORK, 0, 0, 0)
        if err != 0 {
                fmt.Printf("err fork process, err: %v\n", err)
                return
        }

        if pid == 0 {
                fmt.Printf("i am in child process, pid = %v\n", syscall.Getpid())
                time.Sleep(time.Hour) // make the child process wait
        }
        fmt.Printf("i am parent process, pid = %v\n", syscall.Getpid())
        fmt.Printf("fork ok, childpid = %v\n", pid)
        time.Sleep(time.Hour) // make the main goroutine wait!
}

func sysSignalHandleDemo() {
        ss := signalSetNew()
        handler := func(s os.Signal, arg interface{}) {
                fmt.Printf("%v: handle signal: %v\n", syscall.Getpid(), s)
                if s == syscall.SIGTERM {
                        fmt.Printf("%v: signal termiate received, app exit normally\n", syscall.Getpid())
                        os.Exit(0)
                }
        }

        ss.register(syscall.SIGINT, handler)
        ss.register(syscall.SIGUSR1, handler)
        ss.register(syscall.SIGUSR2, handler)
        ss.register(syscall.SIGTERM, handler)

        for {
                c := make(chan os.Signal)
                var sigs []os.Signal
                for sig := range ss.m {
                        sigs = append(sigs, sig)
                }
                signal.Notify(c)
                sig := <-c

                err := ss.handle(sig, nil)
                if err != nil {
                        fmt.Printf("%v: unknown signal received: %v, app exit unexpectedly\n", syscall.Getpid(), sig)
                        os.Exit(1)
                }
        }
}

dockerapp3利用fork创建了一个子进程，这样dockerapp3实际上是两个进程在运行，各自有自己的signal监听 goroutine，goroutine的处理逻辑是相同的。注意：由于Windows和Mac OS X不具备fork语义，因此在这两个平台上运行dockerapp3不会得到预期结果。

利用dockerapp3，我们创建image "test:v3":

$ sudo docker build -t="test:v3" ./
[sudo] password for tonybai:
Sending build context to Docker daemon 11.24 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
 —> 68edf809afe7
Step 1 : MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
 —> Using cache
 —> c617b456934a
Step 2 : COPY ./dockerapp3 /bin/
 —> 6ccf97065853
Removing intermediate container 6d85fe241939
Step 3 : CMD /bin/dockerapp3
 —> Running in 75d76380992a
 —> c9e7bf361ed7
Removing intermediate container 75d76380992a
Successfully built c9e7bf361ed7

启动基于test:v3 image的容器：

$ sudo docker run -d "test:v3"
781cecb4b3628cb33e1b104ea57e506ad5cb4a44243256ebd1192af86834bae6
$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS               NAMES
781cecb4b362        test:v3             "/bin/sh -c /bin/doc   5 seconds ago       Up 4 seconds                            insane_bohr      

通过docker logs查看dockerapp3的输出：

$ sudo docker logs 781cecb4b362
i am parent process, pid = 1
fork ok, childpid = 13
i am in child process, pid = 13

可以看出主进程pid为1，子进程pid为13。我们通过stop停止该容器：

$ sudo docker stop 781cecb4b362
781cecb4b362

再次通过docker logs查看：

$ sudo docker logs 781cecb4b362
i am parent process, pid = 1
fork ok, childpid = 13
i am in child process, pid = 13
1: handle signal: terminated
1: signal termiate received, app exit normally

我们可以看到主进程收到了stop发来的SIGTERM并退出，主进程的退出导致容器退出，导致子进程13也无法生存，并且没有优雅退出。而在非 容器状态下，子进程是可以被init进程接管的。

因此对于docker容器内运行的多进程程序，stop命令只会将SIGTERM发送给容器主进程，要想让其他进程也能优雅退出，需要在主进程与 其他进程间建立一种通信机制。在主进程退出前，等待其他子进程退出。待所有其他进程退出后，主进程再退出，容器停止。这样才能保证服务程序的优雅 退出。

七、容器内启动多个服务程序

虽说docker best practice建议一个container内只放置一个服务程序，但对已有的一些遗留系统，在架构没有做出重构之前，很可能会有在一个 container中部署两个以上服务程序的情况和需求。而docker Dockerfile只允许执行一个CMD，这种情况下，我们就需要借助类似supervisor这样的进程监控管理程序来启动和管理container 内的多个程序了。

下面我们来自制作一个基于centos:centos6的安装了supervisord以及两个服务程序的image。我们将dockerapp1拷贝一份，并将拷贝命名为dockerapp1-brother。下面是我们的Dockerfile：

FROM centos:centos6
MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
RUN yum install python-setuptools -y
RUN easy_install supervisor
RUN mkdir -p /var/log/supervisor
COPY ./supervisord.conf /etc/supervisord.conf
COPY ./dockerapp1 /bin/
COPY ./dockerapp1-brother /bin/
CMD ["/usr/bin/supervisord"]

supervisord的配置文件supervisord.conf内容如下：

; supervisor config file

[unix_http_server]
file=/var/run/supervisor.sock   ; (the path to the socket file)
chmod=0700                       ; sockef file mode (default 0700)

[supervisord]
logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
childlogdir=/var/log/supervisor            ; ('AUTO' child log dir, default $TEMP)

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL  for a unix socket

[supervisord]
nodaemon=false

[program:dockerapp1]
command=/bin/dockerapp1
stdout_logfile=/tmp/dockerapp1.log
stopsignal=TERM
stopwaitsecs=10

[program:dockerapp1-brother]
command=/bin/dockerapp1-brother
stdout_logfile=/tmp/dockerapp1-brother.log
stopsignal=QUIT
stopwaitsecs=10

开始build镜像：
    $> sudo docker build -t="test:supervisor-v1" ./
    … …
    Successfully built d006b9ad10eb

基于该镜像，启动一个容器：
$> sudo docker run -d "test:supervisor-v1"
05ded2b898c90059d4c9b5c6ccc8603b6848ae767360c42bd9b36ff87fb4b9df

执行ps命令查看镜像id：
$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

怎么回事？Container没有启动起来？

$ sudo docker ps -a
CONTAINER ID        IMAGE                 COMMAND                CREATED             STATUS                      PORTS               NAMES
05ded2b898c9        test:supervisor-v1    "/usr/bin/supervisor   22 seconds ago      Exited (0) 21 seconds ago                       hungry_engelbart

通过ps -a查看，container启动是成功了，但是成功退出了。于是尝试查看一下log：

sudo docker logs 05ded2b898c9
/usr/lib/python2.6/site-packages/supervisor-3.1.2-py2.6.egg/supervisor/options.py:296: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
  'Supervisord is running as root and it is searching '

似乎是supervisord转为daemon程序，容器主进程退出了，容器随之终止了。

看来容器内的supervisord不能以daemon形式运行，应该以前台形式run。修改一下supervisord.conf中得配置：

将
[supervisord]
nodaemon=false

改为

[supervisord]
nodaemon=true

重新制作镜像:

$ sudo docker build -t="test:supervisor-v2" ./
Sending build context to Docker daemon 13.12 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
 —> 68edf809afe7
Step 1 : MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
 —> Using cache
 —> c617b456934a
Step 2 : RUN yum install python-setuptools -y
 —> Using cache
 —> e09c66a1ea8c
Step 3 : RUN easy_install supervisor
 —> Using cache
 —> 9c8797e8c27e
Step 4 : RUN mkdir -p /var/log/supervisor
 —> Using cache
 —> 9bfc67f8517d
Step 5 : COPY ./supervisord.conf /etc/supervisord.conf
 —> 8c514f998363
Removing intermediate container 4a185856e6ed
Step 6 : COPY ./dockerapp1 /bin/
 —> 0317bd4914d3
Removing intermediate container ac5738380854
Step 7 : COPY ./dockerapp1-brother /bin/
 —> d89711888bdf
Removing intermediate container eadc9444e716
Step 8 : CMD ["/usr/bin/supervisord"]
 —> Running in aaa042ac3914
 —> 9655256bbfed
Removing intermediate container aaa042ac3914
Successfully built 9655256bbfed

有了前面的铺垫，这次build image瞬间完成。启动容器，查看容器启动状态，查看容器内supervisord的运行日志如下：

$ sudo docker run -d "test:supervisor-v2"
61916f1c82338b28ced101b6bde119e4afb7c7fa349b4332ed51a43a4586b1b9

$ sudo docker ps
CONTAINER ID        IMAGE                COMMAND                CREATED             STATUS              PORTS               NAMES
61916f1c8233        test:supervisor-v2   "/usr/bin/supervisor   16 seconds ago      Up 16 seconds                           prickly_einstein

$ sudo docker logs 8eb3e9892e66

/usr/lib/python2.6/site-packages/supervisor-3.1.2-py2.6.egg/supervisor/options.py:296: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
  'Supervisord is running as root and it is searching '
2014-10-09 14:36:02,334 CRIT Supervisor running as root (no user in config file)
2014-10-09 14:36:02,349 INFO RPC interface 'supervisor' initialized
2014-10-09 14:36:02,349 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2014-10-09 14:36:02,349 INFO supervisord started with pid 1
2014-10-09 14:36:03,354 INFO spawned: 'dockerapp1' with pid 14
2014-10-09 14:36:03,363 INFO spawned: 'dockerapp1-brother' with pid 15
2014-10-09 14:36:04,368 INFO success: dockerapp1 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2014-10-09 14:36:04,369 INFO success: dockerapp1-brother entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

可以看到supervisord已经将dockerapp1和dockerapp1-brother启动起来了。

现在我们尝试停止容器，我们预期是supervisord在退出前通知dockerapp1和dockerapp1-brother先退出，我们可以通过 查看容器内的/tmp/dockerapp1.log和/tmp/dockerapp1-brother.log来确认supervisord是否做了通 知。

$ sudo docker stop 61916f1c8233
61916f1c8233

$ sudo docker logs 61916f1c8233
… …
2014-10-09 14:37:52,253 WARN received SIGTERM indicating exit request
2014-10-09 14:37:52,254 INFO waiting for dockerapp1, dockerapp1-brother to die
2014-10-09 14:37:52,254 INFO stopped: dockerapp1-brother (exit status 0)
2014-10-09 14:37:52,256 INFO stopped: dockerapp1 (exit status 0)

通过容器的log，我们看出supervisord是等待两个程序退出后才退出的，不过我们还是要看看两个程序的输出日志以最终确认。重新启动容器，通过nsenter进入到容器中。

-bash-4.1# vi /tmp/dockerapp1.log

handle signal: terminated
signal termiate received, app exit normally

-bash-4.1# vi /tmp/dockerapp1-brother.log

handle signal: terminated
signal termiate received, app exit normally

两个程序的标准输出日志证实了我们的预期。

BTW，在物理机上测试supervisord以daemon形式运行，当kill掉supervisord时，supervisord是不会通知其监控 和管理的程序退出的。只有在以non-daemon形式运行时，supervisord才会在退出前先通知下面的程序退出。如果在一段时间内下面程序没有 退出，supervisord在退出前会kill -9强制杀死这些程序的进程。

最后要说的时，在验证一些想法时，没有必要build image，我们可以直接将本地文件copy到容器中，下面是一个例子，我们将dockerapp1和dockerapp1-brother拷贝到镜像中：
$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
4d8982bfccc7        centos:centos6      "/bin/bash"         26 minutes ago      Up 26 minutes                           sharp_thompson     
$ sudo docker inspect -f '{{.Id}}' 4d8982bfccc7
4d8982bfccc79dea762b41f8a6f669bda1ec73c8881b6ca76e7a7917c62972c4
$ sudo cp dockerapp1  /var/lib/docker/aufs/mnt/4d8982bfccc79dea762b41f8a6f669bda1ec73c8881b6ca76e7a7917c62972c4/bin/dockerapp1
$ sudo cp dockerapp1-brother  /var/lib/docker/aufs/mnt/4d8982bfccc79dea762b41f8a6f669bda1ec73c8881b6ca76e7a7917c62972c4/bin/dockerapp1-brother

© 2014, bigwhite. 版权所有.

Go这门语言也许你还不甚了解，甚至是完全不知道，这也有情可原，毕竟Go在TIOBE编程语言排行榜上位列30开外。但近期使用Golang 实现的一杀手级应用 Docker你却不该不知道。docker目前火得是一塌糊涂啊。你去国内外各大技术站点用眼轻瞥一下，如 果没有涉及到“docker”字样新闻的站点建 议你以后就不要再去访问了^_^。Docker是啥、怎么用以及基础实践可以参加国内一位仁兄的经验之作：《 Docker – 从入门到实践》。

据我了解，目前国内试水Go语言开发后台系统的大公司与初创公司日益增多，比如七牛、京东、小米，盛大，金山，东软，搜狗等，在这里我们可以看到一些公司的Go语言应用列表，并且目前这个列表似乎依旧在丰富中。国内Go语言的推广与布道也再稳步推进中，不过目前来看多以Go入 门与基础为主题，Go idioms、tips或Best Practice的Share并不多见，想必国内的先行者、布道师们还在韬光养晦，积攒经验，等到时机来临再厚积薄发。另外国内似乎还没有一个针对Go的 布道平台，比如Golang技术大会之类的的平台。

在国外，虽然Go也刚刚起步，但在Golang share的广度和深度方面显然更进一步。Go的国际会议目前还不多，除了Golang老东家Google在自己的各种大会上留给Golang展示自己的 机会外，由 Gopher Academy 发起的GopherCon 会议也于今年第一次举行，并放出诸多高质量资料，在这里可以下载。欧洲的Go语言大会.dotgo也即将开幕，估计后续这两个大会将撑起Golang技术分享 的旗帜。

言归正传，这里要写的东西并非原创，自己的Go仅仅算是入门级别，工程经验、Best Practice等还谈不上有多少，因此这里主要是针对GopherCon2014上的“舶来品”的学习心得。来自CloudFlare的工程师John Graham-Cumming谈了关于 Channel的实践经验，这里针对其分享的内容，记录一些学习体会和理解，并结合一些外延知识，也可以算是一种学习笔记吧，仅供参考。

一、Golang并发基础理论

Golang在并发设计方面参考了C.A.R Hoare的CSP，即Communicating Sequential Processes并发模型理论。但就像John Graham-Cumming所说的那样，多数Golang程序员或爱好者仅仅停留在“知道”这一层次，理解CSP理论的并不多，毕竟多数程序员是搞工程 的。不过要想系统学习CSP的人可以从这里下载到CSP论文的最新版本。

维基百科中概要罗列了CSP模型与另外一种并发模型Actor模型的区别：

Actor模型广义上讲与CSP模型很相似。但两种模型就提供的原语而言，又有一些根本上的不同之处：
    – CSP模型处理过程是匿名的，而Actor模型中的Actor则具有身份标识。
    – CSP模型的消息传递在收发消息进程间包含了一个交会点，即发送方只能在接收方准备好接收消息时才能发送消息。相反，actor模型中的消息传递是异步 的，即消息的发送和接收无需在同一时间进行，发送方可以在接收方准备好接收消息前将消息发送出去。这两种方案可以认为是彼此对偶的。在某种意义下，基于交 会点的系统可以通过构造带缓冲的通信的方式来模拟异步消息系统。而异步系统可以通过构造带消息/应答协议的方式来同步发送方和接收方来模拟交会点似的通信 方式。
    – CSP使用显式的Channel用于消息传递，而Actor模型则将消息发送给命名的目的Actor。这两种方法可以被认为是对偶的。某种意义下，进程可 以从一个实际上拥有身份标识的channel接收消息，而通过将actors构造成类Channel的行为模式也可以打破actors之间的名字耦合。

二、Go Channel基本操作语法

Go Channel的基本操作语法如下：

c := make(chan bool) //创建一个无缓冲的bool型Channel

c <- x        //向一个Channel发送一个值
<- c          //从一个Channel中接收一个值
x = <- c      //从Channel c接收一个值并将其存储到x中
x, ok = <- c  //从Channel接收一个值，如果channel关闭了或没有数据，那么ok将被置为false

不带缓冲的Channel兼具通信和同步两种特性，颇受青睐。

三、Channel用作信号(Signal)的场景

1、等待一个事件(Event)

等待一个事件，有时候通过close一个Channel就足够了。例如：

//testwaitevent1.go
package main

import "fmt"

func main() {
        fmt.Println("Begin doing something!")
        c := make(chan bool)
        go func() {
                fmt.Println("Doing something…")
                close(c)
        }()
        <-c
        fmt.Println("Done!")
}

这里main goroutine通过"<-c"来等待sub goroutine中的“完成事件”，sub goroutine通过close channel促发这一事件。当然也可以通过向Channel写入一个bool值的方式来作为事件通知。main goroutine在channel c上没有任何数据可读的情况下会阻塞等待。

关于输出结果：

根据《Go memory model》中关于close channel与recv from channel的order的定义：The closing of a channel happens before a receive that returns a zero value because the channel is closed.

我们可以很容易判断出上面程序的输出结果：

Begin doing something!
Doing something…
Done!

如果将close(c)换成c<-true，则根据《Go memory model》中的定义：A receive from an unbuffered channel happens before the send on that channel completes.
"<-c"要先于"c<-true"完成，但也不影响日志的输出顺序，输出结果仍为上面三行。

2、协同多个Goroutines

同上，close channel还可以用于协同多个Goroutines，比如下面这个例子，我们创建了100个Worker Goroutine，这些Goroutine在被创建出来后都阻塞在"<-start"上，直到我们在main goroutine中给出开工的信号："close(start)"，这些goroutines才开始真正的并发运行起来。

//testwaitevent2.go
package main

import "fmt"

func worker(start chan bool, index int) {
        <-start
        fmt.Println("This is Worker:", index)
}

func main() {
        start := make(chan bool)
        for i := 1; i <= 100; i++ {
                go worker(start, i)
        }
        close(start)
        select {} //deadlock we expected
}

3、Select

【select的基本操作】
select是Go语言特有的操作，使用select我们可以同时在多个channel上进行发送/接收操作。下面是select的基本操作。

select {
case x := <- somechan:
    // … 使用x进行一些操作

case y, ok := <- someOtherchan:
    // … 使用y进行一些操作，
    // 检查ok值判断someOtherchan是否已经关闭

case outputChan <- z:
    // … z值被成功发送到Channel上时

default:
    // … 上面case均无法通信时，执行此分支
}

【惯用法：for/select】

我们在使用select时很少只是对其进行一次evaluation，我们常常将其与for {}结合在一起使用，并选择适当时机从for{}中退出。

for {
        select {
        case x := <- somechan:
            // … 使用x进行一些操作

        case y, ok := <- someOtherchan:
            // … 使用y进行一些操作，
            // 检查ok值判断someOtherchan是否已经关闭

        case outputChan <- z:
            // … z值被成功发送到Channel上时

        default:
            // … 上面case均无法通信时，执行此分支
        }
}

【终结workers】

下面是一个常见的终结sub worker goroutines的方法，每个worker goroutine通过select监视一个die channel来及时获取main goroutine的退出通知。

//testterminateworker1.go
package main

import (
    "fmt"
    "time"
)

func worker(die chan bool, index int) {
    fmt.Println("Begin: This is Worker:", index)
    for {
        select {
        //case xx：
            //做事的分支
        case <-die:
            fmt.Println("Done: This is Worker:", index)
            return
        }
    }
}

func main() {
    die := make(chan bool)

    for i := 1; i <= 100; i++ {
        go worker(die, i)
    }

    time.Sleep(time.Second * 5)
    close(die)
    select {} //deadlock we expected
}

【终结验证】

有时候终结一个worker后，main goroutine想确认worker routine是否真正退出了，可采用下面这种方法：

//testterminateworker2.go
package main

import (
    "fmt"
    //"time"
)

func worker(die chan bool) {
    fmt.Println("Begin: This is Worker")
    for {
        select {
        //case xx：
        //做事的分支
        case <-die:
            fmt.Println("Done: This is Worker")
            die <- true
            return
        }
    }
}

func main() {
    die := make(chan bool)

    go worker(die)

    die <- true
    <-die
    fmt.Println("Worker goroutine has been terminated")
}

【关闭的Channel永远不会阻塞】

下面演示在一个已经关闭了的channel上读写的结果：

//testoperateonclosedchannel.go
package main

import "fmt"

func main() {
        cb := make(chan bool)
        close(cb)
        x := <-cb
        fmt.Printf("%#v\n", x)

        x, ok := <-cb
        fmt.Printf("%#v %#v\n", x, ok)

        ci := make(chan int)
        close(ci)
        y := <-ci
        fmt.Printf("%#v\n", y)

        cb <- true
}

$go run testoperateonclosedchannel.go
false
false false
0
panic: runtime error: send on closed channel

可以看到在一个已经close的unbuffered channel上执行读操作，回返回channel对应类型的零值，比如bool型channel返回false，int型channel返回0。但向close的channel写则会触发panic。不过无论读写都不会导致阻塞。

【关闭带缓存的channel】

将unbuffered channel换成buffered channel会怎样？我们看下面例子：

//testclosedbufferedchannel.go
package main

import "fmt"

func main() {
        c := make(chan int, 3)
        c <- 15
        c <- 34
        c <- 65
        close(c)
        fmt.Printf("%d\n", <-c)
        fmt.Printf("%d\n", <-c)
        fmt.Printf("%d\n", <-c)
        fmt.Printf("%d\n", <-c)

        c <- 1
}

$go run testclosedbufferedchannel.go
15
34
65
0
panic: runtime error: send on closed channel

可以看出带缓冲的channel略有不同。尽管已经close了，但我们依旧可以从中读出关闭前写入的3个值。第四次读取时，则会返回该channel类型的零值。向这类channel写入操作也会触发panic。

【range】

Golang中的range常常和channel并肩作战，它被用来从channel中读取所有值。下面是一个简单的实例：

//testrange.go
package main

import "fmt"

func generator(strings chan string) {
        strings <- "Five hour's New York jet lag"
        strings <- "and Cayce Pollard wakes in Camden Town"
        strings <- "to the dire and ever-decreasing circles"
        strings <- "of disrupted circadian rhythm."
        close(strings)
}

func main() {
        strings := make(chan string)
        go generator(strings)
        for s := range strings {
                fmt.Printf("%s\n", s)
        }
        fmt.Printf("\n")
}

四、隐藏状态

下面通过一个例子来演示一下channel如何用来隐藏状态：

1、例子：唯一的ID服务

//testuniqueid.go
package main

import "fmt"

func newUniqueIDService() <-chan string {
        id := make(chan string)
        go func() {
                var counter int64 = 0
                for {
                        id <- fmt.Sprintf("%x", counter)
                        counter += 1
                }
        }()
        return id
}
func main() {
        id := newUniqueIDService()
        for i := 0; i < 10; i++ {
                fmt.Println(<-id)
        }
}

$ go run testuniqueid.go
0
1
2
3
4
5
6
7
8
9

newUniqueIDService通过一个channel与main goroutine关联，main goroutine无需知道uniqueid实现的细节以及当前状态，只需通过channel获得最新id即可。

五、默认情况

我想这里John Graham-Cumming主要是想告诉我们select的default分支的实践用法。

1、select  for non-blocking receive

idle:= make(chan []byte, 5) //用一个带缓冲的channel构造一个简单的队列

select {
case b = <-idle:
 //尝试从idle队列中读取
    …
default:  //队列空，分配一个新的buffer
        makes += 1
        b = make([]byte, size)
}

2、select for non-blocking send

idle:= make(chan []byte, 5) //用一个带缓冲的channel构造一个简单的队列

select {
case idle <- b: //尝试向队列中插入一个buffer
        //…
default: //队列满？

}

六、Nil Channels

1、nil channels阻塞

对一个没有初始化的channel进行读写操作都将发生阻塞，例子如下：

package main

func main() {
        var c chan int
        <-c
}

$go run testnilchannel.go
fatal error: all goroutines are asleep – deadlock!

package main

func main() {
        var c chan int
        c <- 1
}

$go run testnilchannel.go
fatal error: all goroutines are asleep – deadlock!

2、nil channel在select中很有用

看下面这个例子：

//testnilchannel_bad.go
package main

import "fmt"
import "time"

func main() {
        var c1, c2 chan int = make(chan int), make(chan int)
        go func() {
                time.Sleep(time.Second * 5)
                c1 <- 5
                close(c1)
        }()

        go func() {
                time.Sleep(time.Second * 7)
                c2 <- 7
                close(c2)
        }()

        for {
                select {
                case x := <-c1:
                        fmt.Println(x)
                case x := <-c2:
                        fmt.Println(x)
                }
        }
        fmt.Println("over")
}

我们原本期望程序交替输出5和7两个数字，但实际的输出结果却是：

5
0
0
0
… … 0死循环

再仔细分析代码，原来select每次按case顺序evaluate：
    – 前5s，select一直阻塞；
    – 第5s，c1返回一个5后被close了，“case x := <-c1”这个分支返回，select输出5，并重新select
    – 下一轮select又从“case x := <-c1”这个分支开始evaluate，由于c1被close，按照前面的知识，close的channel不会阻塞，我们会读出这个 channel对应类型的零值，这里就是0；select再次输出0；这时即便c2有值返回，程序也不会走到c2这个分支
    – 依次类推，程序无限循环的输出0

我们利用nil channel来改进这个程序，以实现我们的意图，代码如下：

//testnilchannel.go
package main

import "fmt"
import "time"

func main() {
        var c1, c2 chan int = make(chan int), make(chan int)
        go func() {
                time.Sleep(time.Second * 5)
                c1 <- 5
                close(c1)
        }()

        go func() {
                time.Sleep(time.Second * 7)
                c2 <- 7
                close(c2)
        }()

        for {
                select {
                case x, ok := <-c1:
                        if !ok {
                                c1 = nil
                        } else {
                                fmt.Println(x)
                        }
                case x, ok := <-c2:
                        if !ok {
                                c2 = nil
                        } else {
                                fmt.Println(x)
                        }
                }
                if c1 == nil && c2 == nil {
                        break
                }
        }
        fmt.Println("over")
}

$go run testnilchannel.go
5
7
over

可以看出：通过将已经关闭的channel置为nil，下次select将会阻塞在该channel上，使得select继续下面的分支evaluation。

七、Timers

1、超时机制Timeout

带超时机制的select是常规的tip，下面是示例代码，实现30s的超时select：

func worker(start chan bool) {
        timeout := time.After(30 * time.Second)
        for {
                select {
                     // … do some stuff
                case <- timeout:
                    return
                }
        }
}

2、心跳HeartBeart

与timeout实现类似，下面是一个简单的心跳select实现：

func worker(start chan bool) {
        heartbeat := time.Tick(30 * time.Second)
        for {
                select {
                     // … do some stuff
                case <- heartbeat:
                    //… do heartbeat stuff
                }
        }
}

© 2014, bigwhite. 版权所有.