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，

在 这篇总结 [http://xargin.com/microservices-patterns/] 的结尾，提到了 GraphQL 的问题。 之前在某公司落地查询 API 方案时，我们没有选择 GraphQL，是因为： * GraphQL 对于数据用户来说有一定的学习成本 * GraphQL 的稳定性很难做，难以限流 学习成本倒也不是特别大的问题，程序员们本能上还是喜欢接触新东西的，这会让他们有一种虚假的获得感。 关键是这个限流问题，是真的很难做，开放 GraphQL 的 API，就像你在 MySQL 上直接开了一个

经常翻阅微服务材料的话，总会碰到 microservices.io 这个网站，总结了微服务方方面面的设计模式。网站的作者是 Chris Richardson。 这些相关的经验在 2018 年成为了《Microservices Patterns》这本书，并且 2019 年引进国内。当时我第一时间购入了这本书，不过那时候很懒，所以没看完。最近在准备分享内容的时候又翻到了这本书，这次完整地读完了一遍。感觉应该是目前微服务领域最好的一本书了。另一本《Building Microservices》也不错，不过内容还是稍微单薄了一些。 这本书为我们提供了宏观上俯瞰微服务整个生态的大图，比如： 当然，18