之前陶师傅推荐过这么一篇文章，Complexity has to live somewhere
[https://ferd.ca/complexity-has-to-live-somewhere.html]
，大致意思是系统的复杂度是没法凭空消失的，只能从一个地方转移到另一个地方，因为现实世界的逻辑就是那么多，边边角角的 case
就是那么多，你必须要处理，这必然会给系统引入复杂度。
尽管这些复杂度你可以转移给你的同事，或者外包给第三方系统，但复杂度是不灭的。
设计系统时，我们要注意到这一点，同时要管理好复杂度问题。
在《a philosophy of software design》这本书中，作者也提出了一个不一样的，
本人现在暂时是无业状态，所以本文不代表任何雇主观点。
到了 2021 这个时间点，大多数公司都决定拥抱云原生，但不少程序员对云原生的理解局限于“原生基于 k8s
的应用”。公司只要上云(k8s)了，就是拥抱云原生了。稍微理解多一点的人觉得除了 k8s，我们只要上了 service mesh，就是拥抱云原生了。
cncf 给云原生的定义其实非常地庞杂：
> 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式
API。
> 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，
Go 1.17 修改了用了很久的基于栈的调用规约，在了解 Go 的调用规约之前，我们得知道什么是调用规约。
x86 calling convention [https://en.wikipedia.org/wiki/X86_calling_conventions]
，简单概括一下，其实就是语言对于函数之间传参的一种约定。调用方要知道我要把参数按照什么形式，什么顺序传给被调用函数，被调用函数也遵守该规范去相应的位置找到传入的参数内容。
老版本的 Go 的参数传递图我们已经在很多很多地方见过了，这里贴一个我之前画的：
可以看到入参和返回值都在栈上，按顺序，从低地址，到高地址排列。
这种基于栈的传参在设计和实现上确实要简单，
最近翻看了一些 Google 的老文章/论文，发现 Google 有不少系统的设计文上都写着 planet
scale，行星级，口气那是真的大。仔细想想，FAANG 这样能把生意做到全球的互联网公司，除了这五家，也没几家其它的了，人家确实有吹行星级的资本。着实羡慕。
Google 的员工出来创业，公司名也是 TailScale(似乎是做 vpn 的)，PlanetScale(这家似乎是拿着 vitess 出来创业的)
这样，说明 ex-googler 也是比较喜欢这家公司的文化的。
截止 2021 年，《Go 语言高级编程》在国内已售出超过 1.6w 册，从技术图书的角度来讲，这本书已经算是成功了，这离不开各位读者的支持，感谢大家~
2016 年的时候，golang-china 的柴树杉找到我，想要一起写一本书，那时候 Go 在国内已经有了一些起色，Gopher
的活动越来越多了，比如后来每年都在办的 GopherChina，和线下很多 Go 语言的 meetup。
国内不少大公司的业务部门还在犹豫要不要把主语言切换到 Go。
我还在某公司写 PHP，
