是什么影响了我的接口延迟

之前在做性能优化分享的时候,经常会说接口延迟大幅上升时,应该先去看看 pprof 里的 goroutine 页面,看看 goroutine 是不是阻塞在什么地方了(比如锁),如果确实是这样,那就去解决这个阻塞问题,可以大幅度优化接口的延迟。 如果我们只是做工程,知道上面这个简单的结论就可以了,最近在一个中年人技术群里,一位前同事问了这么个问题,《Systems Performance》这本书里有一个 USE 方法论,其中提到了一个 Saturation (饱和度)的概念,这个和 Utilization 有啥区别?实际工作中有把 Saturation 监控起来的么?

lyft 的线下开发环境秘籍

几个月前听过一个老同事说早期 lyft 来国内交流的时候,展示过他们强大的线下开发环境,所有的前后端服务都可以在同一台电脑上启动,颇为羡慕,正好最近陶师傅分享了 lyft 的线下环境方案 [https://eng.lyft.com/scaling-productivity-on-microservices-at-lyft-part-2-optimizing-for-fast-local-development-9f27a98b47ee] ,感觉参考价值挺大的。 先来定义一下问题:现在微服务架构在国内互联网公司已经普及了,互联网公司的主流程服务比较复杂,尽管已经尽最大努力进行解耦,改造过后还是会依赖几十至上百的外部服务 。这样导致的最大的问题是,业务研发在线下测试主流程服务极其困难。 如果你恰好在这样的环境工作,想一想,你在修改了主流程的代码之后,是不是没有办法在本地完成测试?是不是必须得把你的开发分支部署到远端的某个环境去?或者是不是必须部署到有 QA 维护的 Staging 环境才能开发 debug?

三份优化相关的材料

最近有意无意地看到三个分享,正好都是和优化相关的,看看不同领域对性能的不同关注点还是挺有意思的。 databend 的性能优化 [https://github.com/datafuselabs/datafuse-presentations/blob/master/meetup-20211203-performance-tuning-in-databend/performance-tuning-in-databend.pdf] databend 是一个对标 clickhouse 的数据库,他们的性能目标是要比 ck 快,会追求一些比较细节的代码优化。 gvisor 在蚂蚁的优化 [https://gvisor.dev/blog/2021/12/02/running-gvisor-in-production-at-scale-in-ant/

2020 年学到了什么

最近在面试的时候,和面试官说 A 家有比较先进的业务架构和基础设施,被人要求一一列举,一时语塞(这么多东西,我半小时实在给你说不完),才想起来去年本来答应老东家的同事要总结一些两家的业务和基础设施之间的 diff,都鸽了快一年了。看来面试的时候是遭报应了,该还的债总是要还的。 正好去年也没做什么技术方面的总结,从 A 家离职半年有余,这个时间点总结一下去年一整年的学习成果还是稍微有一点必要的,等明年说不定就忘了。 业务 单元化 在前一家公司工作的时候,碰到过 A 家来的人说稳定性问题可以用单元化来解决,所以进了 A 家,单元化也是我重点关注的问题。 单元化的方案原理比较容易理解,用户 id 按照常数做

Software engineering at Google 笔记(二)

这本书第二部分讲的是文化,对于技术人员来说稍微有点无聊,不过决定我们在一家公司工作舒服不舒服的,其实主要就是这些文化内容,如果用这一部分里的内容去考核那些我们日常工作中的人,可能结果也会令人失望。 这一部分的内容可以看出 Google 和国内公司的文化有巨大的差异,对国内的工程师和 manager 来说,有一些思想有借鉴意义,而另一些只当参考即可(全信的话,你一定会被坑得很惨)。 软件开发要依赖团队协作 Google 内部的代码管理系统收到过很多人的需求,希望能把项目设置成 private,这个需求来自于很多人在项目写完之前,不想让别人看到自己的代码,这种心态是由于研发人员的不安全感。比如他们可能害怕: * 别人嘲笑你,这样的错误你都犯,和你的工作年限是不是匹配啊,可能你其实是个菜鸡 * 明明是自己想出来的 idea,但是最终却被别人抢去邀功了 对代码的“
京ICP备15065353号-1