大型系统在线问题诊断与定位

本文是武汉 gopher meetup 的分享内容整理而成,分享内容在“无人值守”的两篇和其它社区分享中亦有提及。(也就是说你看过那两篇,这个可以不用看了) 先来看看苦逼的开发人员 老板说: 队友说: 外组同事说: 底层团队说: 你: 业界的思路? 混口饭吃也是不容易,既然有问题了,我们还是要解决的。要先看看有没有现成的思路可以借鉴? Google 在这篇论文里提到过其内部的线上 profile 流程: 架构图已经比较简单了,线上应用暴露 profile 接口,collector 定时将 profile 信息采集到二进制存储,由统一的在线平台展示。

  • Cao ChunHui
6 min read

随便说说 living documentation

几年前在 oreilly 看到一本叫 《living documentation》的书,可惜当时烂尾了。 最近图灵出版了该书的中文翻译版,才想起来有这么回事。。。正好最近有时间,把这个坑了几年的东西给填上了。 简单来说,这本书基本可以叫 living java doc(误。我们可以先看看日常开发中会涉及到哪些文档: 需求文档 接口文档 业务词汇表文档 模块业务流程文档 系统间交互文档 系统架构文档 系统依赖文档 发布文档 示例文档(tutorial) 项目进度文档 案例文档 汇报文档 要写的类型文档还是不少的,无论哪种文档,

  • Cao ChunHui
7 min read

一种持锁被调度的情况

在给某个项目做长时间极限压测的时候,经常会出现压几小时不出问题,突然就崩了的情况。 查看监控发现崩的时候 goroutine 突然涨起来了,那么可以用我之前开发的问题诊断工具了,配置下面的策略:若 goroutine 突然开始暴涨,则将 goroutine 文本 dump 下来。对这个诊断工具不了解的,可以看看我之前写的 无人值守的自动 dump-2 和 无人值守的自动 dump。 代码集成好之后再压,发现崩溃时,总是有很多卡在锁上的 goroutine: 10760 @ 0x42f81f 0x4401d9 0x4401af 0x43ff4d 0x474df9

  • Cao ChunHui
4 min read

Go 应用的性能优化

为什么要做优化 这是一个速度决定一切的年代,只要我们的生活还在继续数字化,线下的流程与系统就在持续向线上转移,在这个转移过程中,我们会碰到持续的性能问题。 互联网公司本质是将用户共通的行为流程进行了集中化管理,通过中心化的信息交换达到效率提升的目的,同时用规模效应降低了数据交换的成本。 用人话来讲,公司希望的是用尽量少的机器成本来赚取尽量多的利润。利润的提升与业务逻辑本身相关,与技术关系不大。而降低成本则是与业务无关,纯粹的技术话题。这里面最重要的主题就是“性能优化”。 如果业务的后端服务规模足够大,那么一个程序员通过优化帮公司节省的成本,或许就可以负担他十年的工资了。 优化的前置知识 从资源视角出发来对一台服务器进行审视的话,CPU、内存、磁盘与网络是后端服务最需要关注的四种资源类型。 对于计算密集型的程序来说,优化的主要精力会放在 CPU 上,要知道 CPU 基本的流水线概念,知道怎么样在使用少的

  • Cao ChunHui
18 min read

在业务系统中寻找技术含量

从进入互联网公司开始工作起,每个人都在问自己,CRUD 到底有什么技术含量? 别觉得 CRUD 只是业务工程师的问题,无论你在写什么程序,基本上都是在和数据打交道,除了读就是写。只不过读写的时候还会附带一些领域相关的行为。比如: 编译器:读文本,做 parse 网络程序:读连接,decode,encode,写连接 数据库:从磁盘上读,从内存里读,向磁盘里写,向内存里写 工程上,谁也没有权力鄙视谁,你觉得领域的技术含量高,只不过是领域内的工作做的人少罢了。不管门槛多么高的工程领域,只要工程师红利们蜂拥而至,总有一款内卷适合你。

  • Cao ChunHui
8 min read

一些 eink 设备

工程师是一个需要大量阅读的岗位,读书、读文档、读论文、读技术新闻,现在大部分电子设备都是 LCD 或 OLED 屏幕,对眼睛的伤害非常大。 因为行业的特殊原因,有时我们会一天花 13-15 小时使用各种电子设备,工作时间长的人很容易眼睛疲劳,严重的可能还会患上干眼症。 能够缓解这个问题的是市面上用户比较少的 eink 设备,比如 kindle: 目前 kindle 最新的设备是 oasis 3,7 寸屏幕 300 PPI,如果只做纯文字阅读,kindle

  • Cao ChunHui
6 min read

why do we need generics?

Go 社区之父早期提到过 less is more 的哲学,可惜社区里有不少人被带偏了。 每次 Go 增加语法上的新特性、新功能,就会有原教旨主义者跳出来扔出一句 less is more(或者也可能是大道至简),扬长而去,留下风中凌乱的你。 即使到了官方已经确定要增加泛型功能的 2020 年,依然有人煞有介事地写文章说为什么 go doesn't need generics,作为理智的 Gopher,最好不要对别人的结论尽信,至少要看看其它语言社区怎么看待这件事情。 Java 社区是怎么理解泛型的必要性的呢? 简而言之,

  • Cao ChunHui
5 min read

开源说线上分享

当前互联网公司的后端架构都是微服务化的,服务彼此使用 RPC 通信,与业务无关的功能部分会从业务代码中抽离为框架。 框架提供了基础的 RPC 功能,同时需要对稳定性负责,一个微服务框架包含但不限于以下功能: 路由 限流 熔断 负载均衡 服务注册与发现 tracing 链路加密 这些功能看起来也是通用且稳定,所以我们对一个框架的印象往往是成型了之后便很少再升级了。但是云原生时代将我们的假设击得粉碎。底层基础设施也开始迅速发生变化,例如: 物理机集群 -> k8s 集群,破坏了我们的服务实例 ip 不会变的假设 基础设施给服务的资源分配方式发生变化,超卖使以往未经审慎设计的代码在恶劣环境下更易崩溃 服务数量的爆炸式增长使每个内部的微服务都要面对

  • Cao ChunHui
15 min read

用 subsetting 限制连接池中的连接数量

内网使用服务发现后,服务与其它服务的实例之间使用一条 TCP 长连接进行通信。这种情况下常见的做法是按照 registry 下发的 host:port 列表来直接建连。 简单来说就是下图这样: 每一个服务实例都需要和它依赖的服务的每一个实例都把连接给建上。如果各个服务的规模不大,这样没什么问题。 互联网公司的核心服务规模都比较大,几千/万台机器(或几千/万个实例)的单一服务并不少见,这时候 client 要和所有 server 实例建连,会导致 client 端的 conn pool 里有大量连接,当然,server

  • Cao ChunHui
6 min read

无人值守的自动 dump(二)

之前在这篇 无人值守(一) 简单介绍了我们针对线上抖动问题定位的工具的设计思路,思路很简单,技术含量很低,是个人都可以想得到,但是它确实帮我们查到了很多很难定位的问题。 在本篇里,我们重点讲一讲这个工具在生产环境帮我们发现了哪些问题。 OOM 类问题 RPC decode 未做防御性编程,导致 OOM 应用侧的编解码可能是非官方实现(如 node 之类的无官方 SDK 的项目),在一些私有协议 decode 工程中会读诸如 list len 之类的字段,如果外部编码实现有问题,发生了字节错位,就可能会读出一个很大的值。 非标准

  • Cao ChunHui
7 min read

10 个让微服务完全失败的 tips

这是三年前伦敦一个技术大会上的一场非常独特的分享,没想到一场技术大会上能有这么幽默的另类架构师,作者以反讽的形式举出了 10 个微服务环境下对系统搞破坏的 tips。我看了很多遍,其中的案例其实日常研发中大部分也都遇到过了,之前也总结过各式各样的吐槽,比如之前写的《中台的末路》《微服务的灾难》《MQ 正在变成臭水沟》等等。希望日后自己也能做类似风格的演讲。 下面是演讲的内容: 开场白,先是免责声明,让人对号入座就不好了: 然后是听众收益: 老板想要搞事情,让公司系统更现代化,你不想这么干,得找点理由反驳他;或者你想破坏你们现在的系统;学习从实践中总结的血淋淋教训;具体案例做过了匿名化处理,让罪犯可以稍微心安理得一些。 老板从网上学到了新词汇,比如工业4.0(哪个营销号说德国人不讲工业4.

  • Cao ChunHui
12 min read

无人值守的自动 dump(一)

Go 项目做的比较大(主要说代码多,参与人多)之后,可能会遇到类似下面这样的问题: 程序老是半夜崩,崩了以后就重启了,我也醒不来,现场早就丢了,不知道怎么定位 这压测开压之后,随机出问题,可能两小时,也可能五小时以后才出问题,这我蹲点蹲出痔疮都不一定能等到崩溃的那个时间点啊 有些级联失败,最后留下现场并不能帮助我们准确地判断问题的根因,我们需要出问题时第一时间的现场 Go 内置的 pprof 虽然是问题定位的神器,但是没有办法让你恰好在出问题的那个时间点,把相应的现场保存下来进行分析。特别是一些随机出现的内存泄露、CPU 抖动,等你发现有泄露的时候,可能程序已经 OOM 被 kill

  • Cao ChunHui
4 min read

reviewdog

几年前写过一篇 如何使你的代码达到 awesome-go 的入选标准。几年过去了,标准和工具都有所变化。 linter 已经换了两代,刚开始是散乱的 golint,go vet,staticcheck,后来出现了 gometalinter,把散乱的工具集集成到一起。 gometalinter 时代,我把这个工具集成到了当时组内所有项目 Makefile 里,合并代码前要求提交者自行执行 make lint 来检查不符合规范的代码并修正,可惜 Makefile 里的命令没有强制约束,某些没有追求的程序员根本不把君子之约当回事,所以难以执行下去。没办法,只要一个人不在乎,就会影响到后来加入的工程师,

  • Cao ChunHui
3 min read

架构的腐化是必然的

架构的腐化是必然的,不以人的意志为转移。 我们先从一个故事开始,从前有一个公司,这个公司有一个部门,这个部门里有两个组。 两个组做的项目比较类似,都是策略类项目。 其中一个组做需求基本靠堆人,业务和 PM 的所有需求,能找到人,并且让这个人在各种场景,各种模块,各种分支里加 if else 就可以搞定,代码膨胀飞快。很快没人能说得清项目内的细节,但是公司业务涉及的策略又很多,需求做不过来,所以疯狂堆人,小组规模迅速膨胀到几十个人。大家都很忙碌,充实,每天都在加班,就是代码稍微有点看不懂,但这不重要。重要的是大家都很充实且周报饱满。小组 leader

  • Cao ChunHui
8 min read

为什么提升 Go 项目的测试覆盖率有点难

注意,这里讨论的内容可能有争议。如果不同意,欢迎讨论。 awesome-go 要求项目测试覆盖率达到 80% 以上才符合入选标准。有一些公司也会要求项目有相对合理的测试覆盖率(如 70% 以上才符合代码准入条件等等)。 但有时,我们的逻辑代码却挺难做到这么高的覆盖率,主要还是因为目前 Go 的错误处理逻辑: func Register(req RegisterReq) error{ if len(req.Username) == 0 { return errors.New("length of

  • Cao ChunHui
5 min read

欢迎关注我的公众号,也欢迎打赏,我的微信 xargin_buaa,如果想交流也欢迎来加~

京ICP备15065353号-1