2019 年总结 · 拥抱变化

又到了写年终总结的日子，这应该是博客里少有的扯淡文章，写这篇文章的初衷是想让自己认真思考一下与去年相比，今年的自己有哪些成长和变化。如果说 2018 年是作者服务端技术成熟的一年，那么 2019 年是思想转变、心态开放的一年，作者能以更加开放的心态面对不同领域的知识。

技术

作为软件工程师，技术是安身立命之本。学习技术能赋予我们实现想法的能力，这也是作者不断学习技术的原因之一。这一节将从两个方面分享作者在过去一年技术上的成长。

编程能力

编程能力是软件工程师最重要的能力，很多工程师在讨论分布式、高可用系统时都能把别人说的一愣一愣的，张嘴闭嘴就是五个九的可用性，异地多活，但是一旦落到编程能力上，写一个 FizzBuzz 问题1都能漏洞百出，更不用说写出真正高可用的系统了。

具有好的编程能力的工程师能把真正复杂的项目落地，让设计和实现都可以做到足够的优雅，作者也一直在向这个方向努力 —— 不断提升编程能力。我们应该去实现身边经常使用的工具，多多造轮子来提升我们的编程能力：

不要重复造轮子是一个错误的说法，正确的说法应该是不要发明轮子。

• 手写一个简单的键值存储系统；
• 从头开始构建一个 RPC 框架；
• 保证分布式事务的一致性；

抽象能力是决定编程能力的关键，人脑的处理能力绝对是有限的，没有人能够对 Linux、Kubernetes 中的每一行代码都了如指掌（除了明哥2）。我们理解一个项目的方式是自顶向下或者自底向上的，因为人脑同时能够处理的信息有限，无论哪种方式我们同时理解的都只能是项目的一部分。合理的抽象能够帮助我们更高效地理解项目的顶层架构和底层实现，降低心智上的负担。

图 1 - 计算机程序的构造和解释封面

从接触编程到今天，对作者编程能力影响最大的两本书就是：

1. 《计算机程序的构造和解释》（Structure and Interpertation of Computer Programming，SICP）3
2. 《计算机程序的概念、技术和模型》（Concepts, Techniques, and Models of Computer Programming，CTMCP）4

如果你之前只使用过 C 语言或者面向对象编程语言，那么这两本书能够彻底改变你对编程固有的看法，阅读这些书可能不会有立竿见影的效果，但是从长期来看一定会有巨大的收益。作者在看完这两本书之后又学习了 Haskell、Racket、ML 和 Elixir 等编程语言，它们也一直都在影响着作者思考抽象的方式。

在 2019 年没有看过太多的技术书籍，唯一一本让作者印象十分深刻的书就是《数据密集型应用系统设计》（Designing Data-Intensive Applications，DDIA）5，这本书介绍了数据密集型应用面对的问题和对应的解决方案，它事无巨细地分析了单体数据库、分布式数据库和流式存储系统，这种介绍顶层设计思想的书籍对作者有巨大的帮助。

技术栈

作者的技术栈在 2019 年没有太多改变，主要关心的两个技术还是 Kubernetes 和 Go 语言，这里简单介绍一下在过去一年作者对这些技术做了哪些深入的分析和思考。

Kubernetes

作为云原生的操作系统，Kubernetes 的发展势头非常迅猛，围绕 Kubernetes 的生态也在 2019 年不断完善。从 19 年 2 月开始，作者也开始向 Kubernetes6 仓库贡献一些代码。在 Kubernetes 项目中目前主要关注的方向还是调度器和 Kubelet，从开始提交代码到现在已经向 master 分支合入了 103 个 PR。

1. 19 年 2 月份开始向 Kubernetes 项目开始提交代码；
2. 19 年 4 月份加入 Kubernetes 和 Istio 的项目组；
3. 19 年 7 月份成为 sig-scheduling 的 reviewer；

Kubernets 社区中的绝大多数资料和交流都是完全开源的，包括社区会议的录像、历史的代码提交和增加新功能的 Proposal，作者在参与 Kubernetes 项目的过程中不仅能从过去的讨论和提交中学到了容器调度系统的设计思路，还能学到项目的发布周期、CI/CD 的维护、任务的分类以及分布式的社区应该如何治理，这段与全世界的开发者们一起工作的经历真的非常奇妙。

虽然作者从社区中学到了很多东西，但是不得不吐槽的一点是社区中等待代码审查、合并 PR 以及推动项目都需要非常长的时间，这不仅是松散的社区治理导致的，还因为上游做出的决定会影响所有 Kubernetes 的使用者，社区成员对于 API 的变更都会非常谨慎。

除了为 Kubernetes 社区贡献代码之外，作者在业余时间维护了 Proxier7 项目，它是 Kubernetes 中 Service 的替代品，能够提供更加高级的调度能力，感兴趣的读者可以关注一下：

图 2 - Proxier 架构图

深入参与一个开源项目是需要时间的，作者一周会在开源社区上花 10 小时左右的时间，Kubernetes 社区中的大多数开发者都是在北美洲，所以很多工作都是在晚上完成的。年初的时候也想关注一下 Istio，不过后来发现参与一个开源社区就需要花费很多时间，所以最终还是将关注点放在了 Kubernetes 上。

在未来一年，作者会继续关注 Kubernetes 以及云原生领域中的其他技术。如果有可能的话，作者也会在之后的文章中分享从开源社区中学到了什么，我们如何才能为开源社区做贡献。

Go

这一年时间，作者阅读了 Go 语言的源代码，从编译原理和运行时等不同的方面分析它的实现原理。编程语言的源代码并没有很多人想象的那个优雅，仓库中充满一些让人难以理解的黑魔法，作为一个庞大的项目，维护者们也只能尽力保证代码的质量，但是不同工程师对于代码的审美难免不同，所以很难面面俱到。

图 3 - Google 趋势上 Go 语言的变化

随着容器和云原生的兴起，Go 语言的发展越来越好，很多大公司都开始使用它构建底层服务。Go 语言也成为了作者目前开发的主力语言，当然这并不意味着要在这一门语言上吊死，只是作者开始认同 Go 语言的设计哲学8，也相信这门语言本身和生态未来的发展。

作者在这一年也不断思考如何写出好的 Go 语言代码和项目，根据个人的体会和经验写了 如何写出优雅的 Go 语言代码，其中介绍了 Go 语言的代码规范、最佳实践和单元测试方法，希望能给想要写好 Go 的工程师分享一些自己的见解。

社区

作者已经从技术上分享了过去一年的变化和成长，接下来我们将继续从内容和社交网络两个方面为各位读者分享这一年作者都做了哪些事情。

内容

2019 年作者的写作风格逐渐成熟，相比于前几年零散地输出一些内容，今年开始更加系统地产出一些文章。

上半年写的 Kubernetes 实现原理 系列文章主要分析 Kubernetes 中四大对象以及 Deployment、StatefulSet、DaemonSet 等应用的实现原理，不过这个系列暂时搁浅了，可能未来还会捡起来继续写。我们在这里将重点介绍今年主要维护的两个系列 — Go 语言设计与实现 和 为什么这么设计。

Go 语言设计与实现

Go 语言设计与实现 是作者从今年年初开始写的电子书，书的题目已经清楚地展示了书中应有的内容，它将通过 Go 语言历史的提交、设计文档以及目前的代码分析语言层面的设计和实现原理。

写这个题目的原因有两个：目前市面上有很多分析 Go 源代码的博客，但是有质量的文章和内容比较少，虽然很多文章对 Go 语言原理的分析非常透彻，但是很难构成一个系列甚至一本书；作者目前将 Go 语言作为主要的开发语言并在较长的时间中使用它，自然希望深入理解其实现原理。这两个原因成为了作者写 Go 语言设计与实现的最大动力。

图 4 - Go 语言设计与实现包含的内容

如图 4 所示，目前书中的内容包括 Go 语言的编译原理、常见数据结构、基础概念、关键字以及并发编程相关内容的设计与实现，未来还会加入元编程、标准库以及内存管理等运行时内容。

Go 语言设计与实现中的 编译原理 一章分析了编译器执行的四个步骤：词法和语法分析、类型检查、中间代码生成和机器码生成。这些内容在之前的互联网上都没有人曾经详细了解和分析过，通过对语言编译器的分析，能够学习很多编译原理相关的知识，了解 Go 语言的编译过程对于很多只在书上见过编译器的开发者是一段比较有趣的经历。

这里简单分享一下这本书的现状，Go 语言设计与实现的第一个章节 函数调用 发布于 2019 年 1 月，截止到 2020 年 1 月已经发布了 23 个章节。目前全书还剩下 14 个章节没有完成，作者将在 2020 年完成剩下的内容，在完善新内容的同时也会更新过去发布的章节，让读者获得更好的阅读体验并有所收获。

为什么这么设计

为什么这么设计（Why’s THE Design，WTD）是作者在今年的最后一个季度开的新坑，这是一系列关于计算机领域中程序设计决策的文章，该系列的每一篇文章都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。这里跟大家分享一下开坑的原因和未来的计划。

作者在今年有一个非常重要的体会 —— 一个优秀的软件工程师不应该只停留在了解开源项目的源代码和实现上、觉得读了一遍源码就完成了目的，通过实现理解背后的设计原理是更重要的。相信很多读者都读过一些项目的源代码，但是回过头来看，真正留下深刻印象的是较真研究过的设计决策。

图 5 - 为什么这么设计访问量

图 5 中展示了为什么这么设计系列文章的访问量，从 10 月底发布到 12 月 31 日，访问量总共为 33,000 左右，目前阅读量最高的文章是 为什么 Redis 选择单线程模型，最低的是 为什么 Redis 快照使用子进程。作者对这个结果是有预期的，很多文章发出之前就能预测到大致的访问量，总的来说，作者对这个系列中的大多数文章都是非常满意的：

• 012 为什么 TCP 协议有性能问题
• 011 为什么 MongoDB 使用 B 树
• 010 为什么 Redis 快照使用子进程
• 009 为什么 MySQL 使用 B+ 树
• 008 为什么总是需要无意义的 ID
• 007 为什么基础服务不应该高可用
• 006 为什么 MD5 不能用于存储密码
• 005 为什么你应该使用 Git 进行版本控制
• 004 为什么 TCP 建立连接需要三次握手
• 003 为什么 DNS 使用 UDP 协议
• 002 为什么使用通信来共享内存
• 001 为什么 Redis 选择单线程模型

未来的一年时间内，作者会都持续更新这个系列，希望这个系列能有 100 期以上的内容，感兴趣的读者可以通过上面的链接阅读该系列的全部内容，相信会对各位有所帮助。

社交网络

在这一节中，我们将为各位读者公开 2019 年在几个主要的社交网络中的访问量和阅读量等数据。首先为各位读者分享 2019 年博客面向信仰编程的情况，过去一年时间作者总共发了 45 篇博客，全年 PV 1,103,059、UV 为 222,394，与去年相比 PV 同比增长 39.34% 和 UV 同比增长 82.29%。

注：由于统计口径和方式的变化，今年统计的 PV 跟去年相比有所减少。

图 6 - 2019 年博客访问量

微信公众号是一个相对封闭的平台，作者之前一直都没有使用过微信公众号，但是由于经常有人在上面直接转载作者的文章，所以作者在年初申请了微信公众号，当时的主要目的也是防止其他人用博客上的文章申请原创，所以对于微信公众号的运营也不是特别关注，作者也是从下半年才开始关注这一平台，由于更早的数据随着账号的迁移已经丢失了，所以没法分享具体的增长情况。

图 7 - 2019 年 10 ~ 12 月微信公众号累计关注人数

根据微信公众号后台的已有数据，在过去两个月时间微信公众号的关注人数增长了 2100 左右，12 月与 11 月相比增长了 26.9%。

总结

在 2019 年，作者在技术和社区运营的成长都抵不过另一方面的改变 —— 能以更开放的心态接受不同领域的知识。在大学毕业的这两年多的时间，很多人都曾经建议过我应该用更开放的心态看待问题，作者一直都向这个方向努力，但是一直都没有改变过内心的看法，直到最近才真正接受了这一建议，这对于个人的成长是有非常重要的意义。

很多工程师包括作者都对其他领域的知识不感兴趣甚至认为除了技术的其他知识都不值得学习，但是随着接触的领域越来越多，发现了不同知识的价值，作者现在能以更开放的心态去主动学习更多技能。

我们不需要成为所有领域的专家，根据 20/80 理论，只要稍微花一些时间学习某个领域的内容就能获得较大的效果，作者也会在未来的时间努力学习多个领域的知识和技能，提升自己对世界的认识。

感谢各位读者一直以来对作者的支持，你们的支持对于我来说也非常重要。

{% include related/summary.md %}

1. FizzBuzz 问题 https://wiki.c2.com/?FizzBuzzTest ↩︎

2. 对 jQuery 了如执掌的明哥 https://github.com/drduan/minggeJS ↩︎

3. Structure and Interpertation of Computer Programming，Harold Abelson / Gerald Jay Sussman / Julie Sussman, Feb 2004 https://book.douban.com/subject/1148282/ ↩︎

4. Concepts, Techniques, and Models of Computer Programming, Peter Van Roy / Seif Haridi, Fed 2004 https://book.douban.com/subject/1782316/ ↩︎

5. Designing Data-Intensive Applications，Martin Kleppmann，Apr 2017 https://book.douban.com/subject/30329536/ ↩︎

6. Kubernetes https://github.com/kubernetes/kubernetes ↩︎

7. Proxier https://github.com/draveness/proxier ↩︎

8. Simplicity is Complicated https://talks.golang.org/2015/simplicity-is-complicated.slide#18 ↩︎

转载申请

知识共享许可协议
本作品采用知识共享署名 4.0 国际许可协议进行许可，转载时请注明原文链接，图片在使用时请保留全部内容，可适当缩放并在引用处附上图片所在的文章链接。

文章图片

你可以在 技术文章配图指南 中找到画图的方法和素材。