本文永久链接 – https://tonybai.com/2021/06/28/understand-go-execution-tracer-by-example Netflix（奈飞公司）的性能架构师Brendan Gregg在其《BPF Performance Tools》一书中对tracing、sampling等概念做了细致描述，以帮助开发人员理解这些概念，并基于这些概念对性能优化辅助工具进行分类，明确它们的适用场合。这里引用部分内容如下： ...
本文翻译自马可·凯瓦克（Marko Kevac）的《BPF and Go: Modern forms of introspection in Linux》(https://medium.com/bumble-tech/bpf-and-go-modern-forms-of-introspection-in-linux-6b9802682223)。 每个人都有自己喜欢的关于魔法的书。对于一个人来说是托尔金，对于另一个人来说是普拉切特，对于第三个人来说，比如我，是马克斯-弗雷。今天我要给大家讲的是我最喜欢的IT魔法：BPF以及围绕它的现代基础设施。 ...
这篇文章的初衷是想解答知乎上的一位知友提出的问题。没想到完成一种实现后，这个问题居然被删除了。那么既然实现了，就分享出来吧。问题的原文找不到了，问题大致是这样的： 一个程序中存在多个函数调用链都调用了函数D： A1 -> B1 > C1 -> D A2 -> B2 > C2 -> D A3 -> B3 -> C3 -> D ... ... 那么，如果某次函数D被调用时出现了问题，那么怎么知道这个D是哪个函数调用链里的D呢？ 有些gopher可能会说通过Delve在线调试打印函数调用栈可以知晓D的调用链，还有些gopher可能会说通过各个函数中输出的业务日志可以查明出问题的D归属的函数调用链，这些都是可行的思路。 ...
Go 1.13版本在2019.9.3正式发布！国外的Gopher Vincent Blanchon发表了一篇文章《Go: Retrospective》(科学上网阅读)，对Go从1.0版本到1.13版本做了简要的回顾，这里是那篇文章的译文。 ...
在“云原生”、“容器化”、“微服务”、“服务网格”等概念大行其道的今天，一提到集群管理、容器工作负载调度，人们首先想到的是Kubernetes。 Kubernetes经过多年的发展，目前已经成为了云原生计算平台的事实标准，得到了诸如谷歌、微软、红帽、亚马逊、IBM、阿里等大厂的大力支持，各大云计算提供商也都提供了专属Kubernetes集群服务。开发人员可以一键在这些大厂的云上创建k8s集群。对于那些不愿被cloud provider绑定的组织或开发人员，Kubernetes也提供了诸如Kubeadm这样的k8s集群引导工具，帮助大家在裸金属机器上搭建自己的k8s集群，当然这样做的门槛较高（如果您想学习自己搭建和管理k8s集群，可以参考我在慕课网上发布的实战课《高可用集群搭建、配置、运维与应用》）。 Kubernetes的学习曲线是公认的较高，尤其是对于应用开发人员。再加上Kubernetes发展很快，越来越多的概念和功能加入到k8s技术栈，这让人们不得不考虑建立和维护这样一套集群所要付出的成本。人们也在考虑是否所有场景都需要部署一个k8s集群，是否有轻量级的且能满足自身需求的集群管理和微服务部署调度方案呢？外国朋友Matthias Endler就在其文章《也许你不需要Kubernetes》中给出一个轻量级的集群管理方案 – 使用hashicorp开源的nomad工具。 ...
近两年微服务架构流行，主流互联网厂商内部都已经微服务化，初创企业虽然技术积淀不行，但也通过各种开源工具拥抱微服务。再加上容器技术赋能，Kubernetes又添了一把火，微服务架构已然成为当前软件架构设计的首选。 但微服务化易弄，服务治理难搞！ 一、微服务的“痛点” 微服务化没有统一标准，多数是进行业务领域垂直切分，业务按一定的粒度划分职责，并形成清晰、职责单一的服务接口，这样每一块规划为一个微服务。微服务之间的通信方案相对成熟，开源领域选择较多的有RPC或RESTful API方案，比如：gRPC、apache thrift等。这些方案多偏重于数据如何打包、传输与解包，对服务治理的内容涉及甚少。 ...
这大半年一直在搞Kubernetes。每次搭建Kubernetes集群，或多或少都会被Kubernetes的“网络插件们”折腾折腾。因此，要说目前Kubernetes中最难搞的是什么？个人觉得莫过于其Pod网络了，至少也是最难搞的之一。除此之外，以Service和Pod为中心的Kubernetes架构还大量利用iptables规则来实现Service的反向代理和负载均衡，这又与Docker原生容器单机网络实现所基于的linux bridge和iptables规则糅合在一起，让troubleshooting时的难度又增加了一些。 去年曾经花过一段研究Docker网络，但现在看来当时在某些关键环节的理解上还有些模糊，于是花了周末的闲暇时间对Docker容器单机网络做了一次再理解。这次重新认识利用上了iptables的Trace功能以及数据链路层的ebtables，让我可以更清晰地看到单机容器网络的网络数据流流向。同时，有了容器网络理解这个基础，对后续解决K8s Pod网络问题也是大有裨益的。 本文从某个角度来说也可以理解为自我答疑，我不会从最最基础的Docker网络结构说起，对Docker容器单机网络结构不了解的童鞋，可以先看看我之前写的《理解Docker单机容器网络》和《理解Docker容器网络之Linux Network Namespace》两篇文章。 ...
在“云”盛行的今天，分布式系统已不是什么新鲜的玩意儿。用脚也能想得出来：Google、baidu、淘宝、亚马逊、twitter等IT巨头 背后的巨型计算平台都是分布式系统了，甚至就连一个简单的微信公众号应用的后端也都分布式了，即便仅有几台机器而已。分布式让系统富有弹性，面 对纷繁变化的需求，可以伸缩自如。但分布式系统也给开发以及运维人员带来了难题：如何监控和优化分布式系统的行为。 ...
记得刚来公司时曾参与过一个项目，项目中用到了部门基础库中的一个B+树接口。不过在程序调试过程中我们发现可执行程序总是dump core（在sparc solaris上），经初步分析，断定问题就出在B+树接口处，但一时又找不到问题原因。还好这个B+树的实现者就坐在我的旁边。他分析后告诉我：这个B+树接口要求用户自定义的索引结构体的size应该为4的整数倍。按照他的说法，我为结构体打了padding，以满足结构体size为4的整数倍的要求。修改后果然不再dump core了。当时项目进度紧，我也没有求甚解，这件事也就过去了。 ...
日常开发中，我们为了辅助程序调试常常在每个函数的出入口(entry/exit)增加Trace，一般我们多用宏来实现这些Trace语句，例如： #ifdef XX_DEBUG_ #define TRACE_ENTER() printf(“Enter %s\n”, __FUNCTION__) #define TRACE_EXIT() printf(“Exit %s\n”, __FUNCTION__) #else #define TRACE_ENTER() #define TRACE_EXIT() #endif ...