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

工程师应该怎么学习

只要一日自诩工程师,就没有办法放弃学习。本文不算是技术文,只是介绍一些个人的学习方法和经验。如果很多点你已经做到并且做好,一笑了之便可。 阅读书籍 对于工程师来说,从书籍得来的知识是必不可少的。现在很多年轻的程序员会从网络博客来学习技术,但博客内容大多缺乏体系(主要说总结性质的博客内容),不系统。很多博主为了掩饰自己的未知,遇到不知道的关键点就一笔带过,进而导致缺失。即使原作者非常努力,内容上没有缺失,你能从中获取的也只是别人总结好的知识,没有自己的主动思考,这中间便缺少过程式的沉淀,一味地满足于背诵别人总结好的知识,最后也只不过沦为他人的复读机而已。 对于工程师来说,书籍依然是最重要的知识获取媒介。即使只是通过目录概览,也能获取某个领域的大致蓝图。 目前大部分优秀的技术书籍依然以英文为主,能够读懂英文技术书籍是工程师的硬实力。英语阅读能力怎么训练呢?如果不是为了应试,可以尝试逼迫自己去翻译一些英文文档/文章来进行专门训练。

  • Cao ChunHui
16 min read

生于非阻塞,死于日志

metrics 上报在高并发时会带来性能问题,为了解决问题,有时反而又会带来别的问题。 举个例子,一般的 metrics 上报代码可能是下面这样: // when request in metrics.Req(caller, count, latency) 内部实现一般也就是个 UDP 调用,可能碰到的是 fd 锁的问题,在 这篇 里已经写过了。 为了优化这个锁带来的阻塞问题,有些系统会把 metrics 上报改为非阻塞逻辑: func Req(caller string,

  • Cao ChunHui
2 min read

MQ 正在变成臭水沟

MQ 对于业务系统建模非常重要,是解决分离关注点、依赖反转、CQRS、最终一致等业务问题的重要法宝。 然而企业对于 MQ 中的数据管理却并不重视。从互联网企业发展的历程来看这个问题,最初 MQ 不是很可靠,大家不会把让特别重要的业务依赖 MQ,所以接入到 MQ 的业务事件并不多。总共也就两三个 topic,开发相应的系统对这些内容进行管理看起来没什么必要,甚至可能连详尽的业务信息都要从生产者的代码注释中去寻找。公司规模不大,这些都是可以接受的。 经历过 1Mb 小水管的朋友大概还记得当初火爆的 Flashget 的 Slogan: 下载的最大问题是什么——速度,其次是什么—

  • Cao ChunHui
8 min read

ACL 和俄罗斯套娃

逻辑复杂的系统中,我们经常能看到“规则引擎”和“决策树”之类的东西。 在数据准备好的前提下,规则引擎和决策树都可以理解成在大宽表上进行决策的过程,两者进行逻辑运算需要较为统一的数据格式,即需要对不同来源的数据内容进行统一抽象。 在之前的文章中,我写过 一劳永逸接入所有下游数据系统,讲的便是复杂系统中对准备数据过程的一种抽象。这种抽象在方法论大湿们发明的概念中早有总结:Anti Corruption Layer。你可以把它叫做 adapter,也可以把它称为 facade,或者把它贯名 anti corruption layer,你的听众听不懂哪一个名词,你就尽量用那种叫法,可以显得自己博学多才出世高人。 数据准备过程是典型的对外部系统进行适配的过程,在一个中大型规模的公司,没有进行过数据治理的前提下,必然会产生大量的像下图架构的技术产品:

  • Cao ChunHui
4 min read

为什么 Go 模块在下游服务抖动恢复后,CPU 占用无法恢复

某团圆节日公司服务到达历史峰值 10w+ QPS,而之前没有预料到营销系统又在峰值期间搞事情,雪上加霜,流量增长到 11w+ QPS,本组服务差点被打挂(汗 所幸命大虽然 CPU idle 一度跌至 30 以下,最终还是幸存下来,没有背上过节大锅。与我们的服务代码写的好不无关系(拍飞 事后回顾现场,发现服务恢复之后整体的 CPU idle 和正常情况下比多消耗了几个百分点,感觉十分惊诧。恰好又祸不单行,工作日午后碰到下游系统抖动,虽然短时间恢复,我们的系统相比恢复前还是多消耗了两个百分点。如下图: 确实不太符合直觉,cpu

  • Cao ChunHui
5 min read

一劳永逸接入所有下游数据系统

虽然公司内的存储和数据系统名目繁多,但一般难以满足领域(就是 DDD 里说的那个 domain)内或子域(subdomain)内的所有需求,在业务部门内部还有着花样繁多的各种数据系统。这样的现状会导致业务接入数据服务的开发成本非常高。 这么说可能比较抽象,举个例子,如果你们公司有 LBS 相关的业务,一般一定会有一个坐标相关的服务,可以使用用户 id 获取瞬时坐标信息。也可能用一个订单或者配送 id 获得某件事情的发生轨迹。坐标轨迹相关的服务和地图类的数据强相关,所以这种服务一般是由单独的部门提供。 再比如说,公司内有公共的订单服务,但主服务不可能为各种相对独立的支撑域(supporting domain)的业务需求,无穷无尽地加字段,这种时候一般支持域会在其内部构建自己业务强相关的业务数据服务。

  • Cao ChunHui
8 min read

家境贫寒,整理不易,客官如果觉得不错欢迎打赏!我的微信 xargin_buaa,如果想交流也欢迎来加~

京ICP备15065353号-1