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

本文内容是 2013 年 Google 对 packetdrill 的论文翻译。 网络协议测试很麻烦，线上的网络问题往往都是偶发的，难以捕捉。 packetdrill 是一个跨平台的脚本工具，可以用来测试整个 TCP/UDP/IP 网络栈实现的正确性和性能，从系统调用一直到硬件网络接口，从 IPv4 到 IPv6。 该工具对 Google 工程师研发 Linux TCP 中的 Early Retransmit，Fast Open，Loss

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

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

在 Go 的 runtime 里有一些创建了就没法回收的东西。 之前在 这篇 [http://xargin.com/cpu-idle-cannot-recover-after-peak-load/] 里讲过 allgs 没法回收的问题。 除了 allgs 之外，当前 Go 创建的线程也是没法退出的，比如这个来自 xiaorui.cc 的例子，我简单做了个修改，能从网页看到线程： package main /* #include #include #include void output(