Uber 最近发了一篇文章，主要讲的是在核心服务上动态调整 GOGC 来降低 GC 的 mark 阶段 CPU 占用。基本可以做到有效果，低风险，可扩展，半自动化。 Uber 当前的服务规模大概是几千微服务，基于云上的调度基础设施来进行部署。大部分服务是 GO 写的，这篇文章的作者是做 Maps Production Engineering，这个组之前帮一些 Java 系统调整过 GC 参数(这应该就是他们帮 Go 做优化想的也是怎么调整参数的出发点吧)
在任何语言的并发编程场景中，都有 race 问题，现代语言为了解决 race 问题有两种思路，一种是像 rust 那样的通过所有权+Sync/Send 限制用户尽量无法写出带 race 的代码；一种是像 Go 这样，通过 race detector 在测试期间检查数据竞争问题。 Go 的 race detector 设计决定了其无法在线上环境开启，而很多公司的项目上线前其实是没有 race test 的环节的，这就导致了一些 Gopher
之前在做性能优化分享的时候，经常会说接口延迟大幅上升时，应该先去看看 pprof 里的 goroutine 页面，看看 goroutine 是不是阻塞在什么地方了(比如锁)，如果确实是这样，那就去解决这个阻塞问题，可以大幅度优化接口的延迟。 如果我们只是做工程，知道上面这个简单的结论就可以了，最近在一个中年人技术群里，一位前同事问了这么个问题，《Systems Performance》这本书里有一个 USE 方法论，其中提到了一个 Saturation (饱和度)的概念，这个和 Utilization 有啥区别？实际工作中有把 Saturation 监控起来的么？
几个月前听过一个老同事说早期 lyft 来国内交流的时候，展示过他们强大的线下开发环境，所有的前后端服务都可以在同一台电脑上启动，颇为羡慕，正好最近陶师傅分享了 lyft 的线下环境方案，感觉参考价值挺大的。 先来定义一下问题：现在微服务架构在国内互联网公司已经普及了，互联网公司的主流程服务比较复杂，尽管已经尽最大努力进行解耦，改造过后还是会依赖几十至上百的外部服务。这样导致的最大的问题是，业务研发在线下测试主流程服务极其困难。 如果你恰好在这样的环境工作，想一想，你在修改了主流程的代码之后，是不是没有办法在本地完成测试？是不是必须得把你的开发分支部署到远端的某个环境去？或者是不是必须部署到有 QA 维护的 Staging 环境才能开发 debug？如果中招了，那么你也应该看看 lyft 的方案。 多语言/
最近有意无意地看到三个分享，正好都是和优化相关的，看看不同领域对性能的不同关注点还是挺有意思的。 databend 的性能优化 databend 是一个对标 clickhouse 的数据库，他们的性能目标是要比 ck 快，会追求一些比较细节的代码优化。 gvisor 在蚂蚁的优化 gvisor 是 Google 做的一个安全容器产品，在蚂蚁有落地了十万+实例，之前在职的时候我也和他们组的人交流过(膜拜一下搞内核的老板们)，可以看到 Go 做内核级别的产品，还是有很多困难的。 k8s api server 优化 之前在职的时候做 k8s
最近在面试的时候，和面试官说 A 家有比较先进的业务架构和基础设施，被人要求一一列举，一时语塞(这么多东西，我半小时实在给你说不完)，才想起来去年本来答应老东家的同事要总结一些两家的业务和基础设施之间的 diff，都鸽了快一年了。看来面试的时候是遭报应了，该还的债总是要还的。 正好去年也没做什么技术方面的总结，从 A 家离职半年有余，这个时间点总结一下去年一整年的学习成果还是稍微有一点必要的，等明年说不定就忘了。 业务单元化在前一家公司工作的时候，碰到过 A 家来的人说稳定性问题可以用单元化来解决，所以进了 A 家，单元化也是我重点关注的问题。 单元化的方案原理比较容易理解，用户 id 按照常数做 hash，比如
这本书第二部分讲的是文化，对于技术人员来说稍微有点无聊，不过决定我们在一家公司工作舒服不舒服的，其实主要就是这些文化内容，如果用这一部分里的内容去考核那些我们日常工作中的人，可能结果也会令人失望。 这一部分的内容可以看出 Google 和国内公司的文化有巨大的差异，对国内的工程师和 manager 来说，有一些思想有借鉴意义，而另一些只当参考即可(全信的话，你一定会被坑得很惨)。 软件开发要依赖团队协作Google 内部的代码管理系统收到过很多人的需求，希望能把项目设置成 private，这个需求来自于很多人在项目写完之前，不想让别人看到自己的代码，这种心态是由于研发人员的不安全感。比如他们可能害怕： 别人嘲笑你，这样的错误你都犯，和你的工作年限是不是匹配啊，可能你其实是个菜鸡明明是自己想出来的 idea，但是最终却被别人抢去邀功了对代码的“隐藏”行为并不能给我们带来好处，从项目开始设计一直到完成，
这个是这本书的读书笔记，这本书总共有四个部分。 第一部分只有一章，所以可以水一篇，开心。 第一部分：论题什么是软件工程软件工程是随着时间的推移不停地对代码进行集成(Programming integrated over time)，这本书将软件项目分成两种，一种是 programming，一种是 software engineering，具体的区别： programming 指短期任务，比如一次性的脚本，一次性的算法题目，学校里的项目等等；一种是 software enginnering，要考虑你的项目要长期存活，所以要认真地考虑“时间”这个要素对软件本身的影响。SE 核心要考虑的是项目的能力，即修改的能力、
每过一段时间，就会有人跳出来批判 DDD，这东西到底是垃圾还是银弹？ 在某某公司干活的时候，有一批人声称要用 DDD 改造老旧系统，彻底解决核心流程规模化之后，项目难以维护的问题。之前某篇文章里的这张图，就是在用 DDD 做项目重构之前的烂摊子： 大家都很聪明，聪明到最后没人知道这新需求到底该往哪里写了。架构师们聚在一起学习 DDD 精神，产出学习报告，大半年过去，终于出了一些成果，有些子项目完成了用 DDD 进行的重构，年底可以拿来在酒会上邀功了，这下我们跟上了业界业务开发的主流方法论，可喜可贺，可喜可贺啊。 年末的时候部门内匿名提问的小纸条却向架构师们发直球：“为什么用了 DDD 以后，
之前写过文章讲工程师应该怎么学习，讲的最多的就是要多读体系化的技术书籍。最近碰到一些朋友说读书读不进去，读的太慢，或者读完就忘该怎么办。 这篇文章解答一下这几个问题： 读书读不进去如何加快阅读技术类书籍的速度读过的书会忘记怎么办读书读不进去读技术书主要有两个目的，一是和工作内容结合寻找能够落地的方案，二是了解不太熟悉的领域的宏观大图，帮助自己建立知识体系，拓宽视野。 能直接和工作内容结合的书是最好的，如果我们在做流式计算领域，那把市面上常见的几本英文书：《stream processing with flink/spark》 和 《streaming systems》读完自然是应该的，书的内容和我们的工作密切相关，这种类型的书不太可能看不进去，如果看不进去，就看看自己的银行卡余额。 若是想拓宽视野，阅读的内容大多就和我们的日常工作脱离了，如果书里的一些生僻内容，恰好触达了我们某根脆弱的躺平神经，可能直接就弃了。这需要我们对自己的意志力有一些要求，
假期就不聊技术了。 《Stop Reading The News》 是一个 150 页的小册子，假期闲来无事，把它读完了。最初买这本小书的原因是看到了这么一个故事：作者受邀去英国的卫报(The Guardian)宣传自己的书《The Art of Thinking Clearly》，卫报的编辑表示对作者 blog 上的批判新闻的文章更感兴趣，希望他能详细讲一讲(有股鸿门宴的味道啊)。所以作者在没有准备的情况下，头铁地现场陈述了新闻的种种罪状，并尴尬地在现场没有得到任何回应。 卫报的编辑们作为新闻媒体的从业人员，想必是不会同意作者的观点的，不过他们还是很神奇的，把它的观点汇总起来发表在了网站上：news
《righting software》是 Pearson 出版社 2020 年出版的一本书，作者是 Juval Löwy，今年国内也引进了这本书，中文名是《架构之道》。 中秋期间读完了这本书里我比较关心的部分，本文将其中的一些核心观点进行摘录。 作者首先总结自己几十年的经验(先表达一下羡慕)，提出了靠谱软件的设计方法，称为 The Method(中文译成了元方法)： The Method = System Design + Project Design 这本书也就被分成了这两部分，System Design 和 Project
之前陶师傅推荐过这么一篇文章，Complexity has to live somewhere，大致意思是系统的复杂度是没法凭空消失的，只能从一个地方转移到另一个地方，因为现实世界的逻辑就是那么多，边边角角的 case 就是那么多，你必须要处理，这必然会给系统引入复杂度。 尽管这些复杂度你可以转移给你的同事，或者外包给第三方系统，但复杂度是不灭的。 设计系统时，我们要注意到这一点，同时要管理好复杂度问题。 在《a philosophy of software design》这本书中，作者也提出了一个不一样的，比较有意思的系统复杂度理论， 可以和上面那篇文章结合在一起来看。 C 代表 Complexity，
本人现在暂时是无业状态，所以本文不代表任何雇主观点。 到了 2021 这个时间点，大多数公司都决定拥抱云原生，但不少程序员对云原生的理解局限于“原生基于 k8s 的应用”。公司只要上云(k8s)了，就是拥抱云原生了。稍微理解多一点的人觉得除了 k8s，我们只要上了 service mesh，就是拥抱云原生了。 cncf 给云原生的定义其实非常地庞杂： 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，
Go 1.17 修改了用了很久的基于栈的调用规约，在了解 Go 的调用规约之前，我们得知道什么是调用规约。 x86 calling convention，简单概括一下，其实就是语言对于函数之间传参的一种约定。调用方要知道我要把参数按照什么形式，什么顺序传给被调用函数，被调用函数也遵守该规范去相应的位置找到传入的参数内容。 老版本的 Go 的参数传递图我们已经在很多很多地方见过了，这里贴一个我之前画的： 可以看到入参和返回值都在栈上，按顺序，从低地址，到高地址排列。 这种基于栈的传参在设计和实现上确实要简单，但栈上传参会导致函数调用过程中数次发生从寄存器和内存之间的参数搬运操作。比如 call 的时候，要把参数全搬到 SP 的位置(这里从寄存器
最近翻看了一些 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，
在 这篇总结 的结尾，提到了 GraphQL 的问题。 之前在某公司落地查询 API 方案时，我们没有选择 GraphQL，是因为： GraphQL 对于数据用户来说有一定的学习成本GraphQL 的稳定性很难做，难以限流学习成本倒也不是特别大的问题，程序员们本能上还是喜欢接触新东西的，这会让他们有一种虚假的获得感。 关键是这个限流问题，是真的很难做，开放 GraphQL 的 API，就像你在 MySQL 上直接开了一个 SQL 接口一样，用 SQL 可以一次只查一条数据，也可以一次查一亿条数据。
经常翻阅微服务材料的话，总会碰到 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 差不多，
从毕业至今，已经待过四家公司，算上实习期间三月游的公司差不多已经快十家了，时常会碰到一些有意思的言论。 在某司的时候就经常听到人说，“我们在 T 姓巨头的时候”，“我们在 A 姓巨头的时候”，“我们在 B 姓巨头的时候”，以任意一家巨头公司作为观点的前缀，显得观点就特别有分量。仔细想想，实习期间我也是在这些所谓的巨头公司待过的，我怎么就没有想到可以在自己编的故事前面加上这是 X 家的事情，所以还是他们比较机智。 大公司里的平均水平高，牛人多，并不代表进去的就一定是牛人，还有不少认不清是自己强还是公司机制强的混子。 即使是在大公司，也会有很多垃圾系统，他们内部没有限流，没有熔断，没有降级，也没有过载保护。但是他们却不会崩溃，
这次去 Gopher China 和不少老朋友见了个面，还有不少在微信上认识已久，一直没见过面的网友。同时也和各个公司的一线开发们聊了聊，互相交流了彼此使用 Go 时的一些心得和痛点。 综合近期了解的一些相关分享，我把到目前为止见到的，不那么常见的，各方对 Go 的优化和 hack 集中在这篇文章里。因为考虑到一些公司情况比较特殊，所以本文中列出的点就不标记是哪个公司做的了。未来他们觉得时机成熟应该也会自己出来做一些分享。 网络方面 当前 Go 的网络抽象在效率上有些低，每一个连接至少要有一个 goroutine 来维护，有些协议实现可能有两个。因此 goroutine 总数 = 连接数
前置知识在这里。 在 stackoverflow 上有这么一个问题，问题的答案中有这么几段： At the same time, x86 defines quite a strict memory model, which bans most possible reorderings, roughly summarized as follows: Stores have a single global order of visibility,
有一个观点已经被说烂了：使用 MQ 可以帮助业务系统解耦。 想法很简单，在业务状态流转时，如果没有 MQ，那么其它系统想要知道状态变了，那就需要核心流程系统去主动做通知。 比如电商系统里订单从创建到处理中状态切换了，客服系统需要知道，风控系统需要知道，用户系统也需要知道。 这里的通知通过 RPC 来进行，下游系统需要的数据可以在这次 RPC 里携带上，也可以在请求的时候让下游系统自己去查。 下游系统增加的时候，核心业务的代码也需要修改，比如新做了一个积分系统，现在订单状态流转积分系统也想知道。 核心系统需要不停地增加调用关系来迎合下游新增的业务方需求。这些边边角角的计算逻辑和订单系统本身没啥关系，但是因为下游需要拿到这些数据，我们就需要自己用 RPC 去调用下游的接口。这确实不太合理。 当下游系统发生事故时，
今年不少业务开发像突然被开了光一样开始讲 nocode 和 lowcode，可以看出现今的互联网可能真的是编不出什么好故事了。 在之前的文章里，我们已经讲过自动化、平台化和中台化了，不管业务模式怎么变，企业内总还是有一些局部系统最终能够把开发模式沉淀下来，变成拖拖拽拽就可以进行变更的“网页制作大师”系统。 像阿里这样的公司，中台落地并迭代多年以后，核心业务的流程变化其实并不会有太多的编码任务，从内部资料来看，套用以往的业务模式，改改配置或者上上活动，基本不需要程序员去做开发了。 不管我们在哪个公司，只要我们按照《在业务系统中寻找技术含量》这篇文章的思路去做系统，最终一定能够将大部分繁琐的重复劳动做到自动化。二八定律，就是可以将那 80% 的重复劳动用界面化、系统化、流程化的手段完全消灭掉。剩下的 20%
Fail at Scale 是 Facebook 2015 年在 acm queue 上发表的一篇文章。主要写了常见的线上故障和应对方法，内容还是比较实在的。 "What Would You Do If You Weren't Afraid?" 和 "Fortune Favors the Bold." 是 FB 公司信条，挂墙上那种。
The Tail at Scale，是 Google 2013 年发表的一篇论文，大规模在线服务的长尾延迟问题。 要知道怎么解决长尾问题，先要理解长尾延迟是个什么问题，在开发在线服务的时候，我们都知道要关注服务的 p99/p999 延迟，要让大部分用户都能够在预期的时间范围内获得响应。 下面是一个不同响应时间的请求数分布图： 大部分系统也都遵循这种分布规律，现在互联网的系统规模比较大，一个服务依赖几十上百个服务的情况都是有可能的。单一模块的长尾延迟会在有大量依赖的情况下，在服务粒度被放大，《The Tail at Scale》论文里给出了这样的例子。 考虑一个系统，大部分服务调用在 10ms 内响应，但
