LinkinStar's Blog

我们知道 golang 的 map 并发会有问题，所以 go 官方在 sync 包中加入了一个 sync.map 来作为一个官方的并发安全的 map 实现。 如果你了解过 java 中常用的一个并发安全的 map 叫做 ConcurrentHashMap 就会知道它有两个亮点设计：一是当链表长度过长的时候会转换为红黑树的实现，还有一个就是分段锁。得益于这两个设计也导致 java 中实现的代码非常复杂，偷笑。 那么 go 里面是如何设计的呢？今天我们就来看看它是怎么实现的。 PS: 本文 go 源码基于版本1.16.2，我觉得当有了泛型之后这个库十有八九是要改的…. 数据结构定义123456type Map struct { mu Mutex read atomic.Value // readOnly dirty map[interface{}]*entry misses int} 123456// readOnly is an immutable struct stored atomically in the Map.r ...

RBAC 之所以一直没有写这个，一方面是因为它确实并不复杂，二来平常确实接触不多，今天就来顺路讲讲它 定义Role-Based Access Control 我们常说的 RBAC，我们知道在一个后台管理系统里面经常会有权限管理。而最常用的一种权限设计方式就是基于角色的权限设计，A 用户是管理员拥有所有的权限，B 是普通用户角色只有部分权限等等，而 k8s 也是如此，k8s 内部也有许许多多的资源，通过 RBAC 的权限设计进行管理授权工作。 Role: 角色，定义了一组对 Kubernetes API 对象的操作权限 Subject: 用户，绑定角色的对象 RoleBinding: 用户和角色的绑定关系 其实非常好理解: 用户 -> 角色 -> 权限 Role123456789apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: namespace: default name: pod-readerrules:- apiGroups: [""] # "" 标明 ...

看到很多部署 prometheus 到 k8s 集群的教程，发现都是非常麻烦的各种配置，懒人的我就想整个一键部署的，开箱即用的，既然有了 helm 那肯定只要一个 charts 就可以搞定了吧，想着就是这样，所以在网上找来找去，终于被我发现了。下面记录一下使用过程，方便以后进行部署。 PS: 本文适用于开发者单 k8s 集群部署 prometheus，如果是运维可建议进行独立部署，一方面不需要占用集群内部资源并保证多活，另一方面可以支持多集群扩展。 安装12345# helm 添加对应 repohelm repo add prometheus-community https://prometheus-community.github.io/helm-charts# helm 安装 可以添加参数 --set rbacEnable=true，-n 指定安装的 namespacehelm install prometheus prometheus-community/kube-prometheus-stack -n monitoror 默认用户名密码admin/prom-operato ...

前言，发现一直没有记录过 pprof 分析的博客，其实在实际的业务场景中已经使用它很多次了，对于性能分析来说它真的是一大杀器，基本上有了它，80% 的性能问题都能被一目了然。每次出现性能问题，总是下面几个步骤，测试环境开 pprof，启动，流量重放，火焰图生成，一看，仔细分析一下，问题就浮于水面。 今天来用最简单的一个案例，来让你快速上手 pprof，所以本博客包含以下内容 最快能让你用上 pprof 能让你最快学会认识火焰图 学会了之后其他剩下的功能你就可以慢慢自己摸索了 废话不多直接上案例 前期准备首先你肯定有 go 环境，需要看火焰图还需要安装 graphviz http://www.graphviz.org/download/ 第一个坑来了，如果 mac 使用 brew install graphviz 安装容易出现失败，还有很多奇怪的依赖如 svn java 等，所以建议使用 sudo port install graphviz 安装 问题发现 使用一些监控软件发现问题，如当前我发现有一个项目在刚启动之后，其他相同类似的项目 cpu 使用都是 20 多，但是它有 4 ...

之前我也了解过 CGO 相关的知识，但是当时给我的印象全部都是 “CGO 性能差” “完全没有必要，实际根本用不到”，但是这次听了大佬的一些分享发现 CGO 其实就是黑科技啊，有了它你在使用 go 的时候有了更多的想象力。本文将带你初步了解和使用 CGO，本文只是抛砖头，因为有关 CGO 的文档其实蛮少的，在其中也有很多坑，所以今天来踩一次，不知道会不会留下什么坑…. 有了 CGO，Go 就有机会继承 C/C++近半个世纪的遗产 by 曹大 CGO 使用案例分享 首先来看一下最近我看到使用 CGO 的两个案例 案例 1 mosn https://github.com/mosn/mosn 其中 mosn 通过 CGO 的能力，想办法在 envoy 后面加了一层，使得其底层网络具备 C 同等的处理能力的同时，又能使上层业务可高效复用 mosn 的处理能力及 go 的高开发效率。 案例 2 主动式缓存 这个 GopherChina 上一个学而思网校的分享，主要讲的是如何设计一个主动式内存缓存，其中提到了 Go 的 GC 导致当有大量内存缓存的时候，对象数量过多，GC 扫描的时间会很长 ...

逃逸分析，看着一个非常高大上的名词，很多人第一次听到它的感觉会觉得它好厉害的样子，其实说到底它很好理解，并不复杂。之前一直没有写也是有原因的，因为其实在实际中，我真的很难用上它。这次写也是有原因的，因为有人催更了…其实拖了有一段时间了，最近终于忙完了，开始补债了。 栈和堆在说逃逸分析之前，我们需要有一些前置知识点 栈我们常说的栈是一种数据结构，当然这里说的栈特指我们在谈论内存分配的时候说的栈。它的作用是在函数调用的过程中保存函数的参数局部变量等数据。而且当函数调用完毕后，它所使用的栈空间将立即释放。所以它“便宜”。 堆堆的概念我们就应该非常熟悉了，它用来存放很多需要使用的对象，这些对象的生命，在 go 里面是交给 GC 去管理的，当我们再也不使用的时候，GC 会将它们回收。所以它“贵”，因为它需要额外的做功才能将它回收掉。 为什么？那为什么需要堆？不用堆不行吗？其实答案显然不行，因为如果所有的变量对象都在栈上，用完了就扔掉，那么其他人想要再使用的时候就无法使用了。 那全部都在堆上不行吗？答案也很显然不行，因为栈便宜，用完就扔，堆很贵，你不能将所有的东西都扔给 GC，这样它要累死。 ...

今年本来没想着要去的，因为确实有点远，加上疫情之下不太方便，但是意料之外来了一张门票，那就必须去一下了，这次收获也不少，有了上次的经验，这次就听得很舒服，不像上次那样那么累了，这次能准确的知道什么应该仔细听，什么应该略过，所以这次的笔记就相对来说少一些，精炼一点。 这次去也面基了大佬，果然北京的都是大佬，都比我卷的厉害，以后还要多学习，哈哈哈，膜拜膜拜~ 基于 Golang 构建高可扩展的云原生 PaaS 平台端点 PaaS 介绍整个历程 主要是推 Erda，主要有以下几点个人觉得可以 自定义 pipeline 开箱即用 微服务治理 兼容 java 族（spring 那一套，还有 dubbo） 可观察性数据采集 个人总结：写个这的一定是 java 过来的，autowired 很 java 味道 https://github.com/erda-project/erda MOSN 云原生演进历程MOSN 之前就有听说的，我觉得很像给 Envoy 加个 buff CGO 并没有想的那么性能堪忧 通过 hacker 的方式可以在调用链路中加一层 filter 实现 想办法做到 zero ...

微服务早已是一个过时的热词，同时，容器 和 k8s 的出现让它更一步成为了一种时尚。同样会带来很多附赠的问题，日志收集就是其中一个比较重要的问题。当应用容器化之后，需要查看日志，如果还需要登录服务器，找到对应目录，然后 tail 查看，成本太高了，极大的影响效率。当前其实日志收集方案很多，在实践了多个方案之后，我终于能在今天写出我个人认为我最喜欢的一个方案了 loki 我的需求技术上没有银弹，需要根据实际需求来选择方案，那么我的需求是这样的，你可以做个比较： 当前所有的应用是部署在 k8s 中的，需要收集所有的应用的日志到一个地方做展示 部署最好要轻量，对于性能要求并不高（当前日志量并不大） 日志展示方式友好，能支持基本的时间查询，或者是定位到某个关键字 可选方案从之前的公司包括个人的一些项目上都尝试过很多不同的组合和方案，列举出三个最具有可比性的方案：（以下为个人使用案例，并不能代表所有大众观点，图片来源本地测试服，线上日志不允许公开，但同样禁止转载~） ELK 这似乎是业界最成熟的日志收集方案之一了，因为无论你问哪个有点经验的程序员，提到日志收集，必然会给到这个，我当然不是说 ...

一提到监控大屏，那第一想法就是 grafana 对吧，各种样式图形都非常好看，而且支持各种数据源。而今天要分享的是一个更加轻量的监控大屏 monitoror/monitoror 有了它能帮你快读构建一个的对于网站或者应用的监控页面，特别是在小应用数量多的时候非常简单易用，作为一个大屏展示时它我觉得它足够简洁 demo & repohttps://demo.monitoror.com/ https://github.com/monitoror/monitoror 优点 部署轻量 配置简单 大屏简洁 部署二进制部署https://monitoror.com/documentation/get-started/ 非常简单，只需要将二进制文件下载，然后按照要求配置对应的配置文件，就可以了 12chmod +x monitoror./monitoror 配置文件.env 1MO_CONFIG="./config.json" 配置文件config.json 12345678910111213141516171819202122{ " ...

一开始觉得 oom 是一个常见问题，应该没有什么大问题，反正 k8s 集群会调度的，但其实它造成的连锁反应很恐怖。 问题描述具体简单描述过程：一台机器 OMM， 导致将对应的pod调度到了其他节点上，导致其他节点 OOM 然后开始疯狂输出日志信息，然后导致 master 磁盘不足开始清理并驱逐，然后导致驱逐（Evicted）的应用再次调度到其他节点，然后连锁反应，最终相关大量服务不可用…. pod 出现告警信息 The node had condition: [DiskPressure]. 总的来说就是一个 应用的 oom 不停的被调度来调度去，导致日志疯狂的输出，导致磁盘不足了。 问题解决设置合适的内存请求和限制条件限制单个应用的使用内存还是非常有必要的，免得出现很多意外的情况 1234567resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi 应用 bug 修复代码 bug 肯定要修复的，这个毕竟是导致问题的主要原因 升级 ECS 的内存确 ...