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

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

抢占抢占 # 从 Go 1.14 开始，通过使用信号，Go 语言实现了调度和 GC 过程中的真“抢占“。抢占流程由抢占的发起方向被抢占线程发送 SIGURG 信号。当被抢占线程收到信号后，进入 SIGURG 的处理流程，将 asyncPreempt 的调用强制插入到用户当前执行的代码位置。本节会对该过程进行详尽分析。抢占发起的时机 # 抢占会在下列时机发生： STW 期间 在 P 上执行 safe point 函数期间

看了看日历，现在已经是 2021 年了，偶尔还是能看到有人在发诸如 《http body 未关闭导致线上事故》，或者 《sql.Rows 未关闭半夜惊魂》类的文章，令人有一种梦回 2015 的感觉。 在这个 Go 的静态分析工具已经强到烂大街的时代，写这些文章除了暴露这些人所在的公司基础设施比较差，代码质量低以外，并不能体现出什么其它的意思了。毕竟哪怕是不懂怎么读源码，这样的问题你 Google 搜一下也知道是怎么回事了。 特别是有些人还挂着大公司的 title，让人更加不能理解。下面是简单的静态分析工具的科普，希望给那些还在水深火热的 Gopher 们送点解药。

为了能和读者互动，之前 blog 一直是有 gitalk 的。 不过 gitalk 似乎是用了 github deprecated 的 API，现在频繁地往我邮箱发邮件，还是很烦的： 之前想换 gitalk 的时候发现并没有什么好的竞品，不过毕竟已经 2021 了，让我发现了这个东西：https://utteranc.es/，还有这个东西： https://giscus.app/。 utterances 和 gitlak 差不多，