LinkinStar's Blog

你在实际业务中是否有遇到过下面这样的场景： 订单十分钟没有支付，自动取消 用户注册成功后无任何操作，一天后自动提醒 预定票之后，在出发之前的一天自动提醒用户 这样类似的场景经常会发生在实际的业务中，它们总有一个共性，就是当前并不是马上触发，而是需要过一段时间才进行触发，当触发时间到达时才进行具体的执行。那么问题就来了，为了实现这样的功能，我们如何更加灵活的实现呢？ 为什么使用延迟队列我们以 订单十分钟过期 场景举例： 方案 1：为当前订单创建一个定时器，定时器时间到了之后自动去查询当前订单状态，如果没有支付，则进行取消操作 方案 2：设定一个总的定时器，每一分钟检查一次，当检查发现过期的订单就直接进行取消操作 方案 3：如果你有一个延迟队列，你只需将任务丢进去，等到了对应的时间，这个任务会出队，然后出队的时候进行订单过期时间判断 方案比较正所谓抛弃场景谈方案都是耍流氓：我的观点也很明确，这三种方案都有自己所试用的场景。 方案 1如果全局只有一个用户，并且这个订单又是那种量比较小的，可能每天有个 30 个已经撑死了，这样的后台的系统，可能都谈不上需要高可用的情况，那么方案 ...

之前我们解决了跨主机间容器间通信的问题，但是这也只能说我们铺好了路，村里通路了，但是其实作为 k8s 来说，还有好多其他的问题等待着我们解决。今天我们就通过这些问题来看看 k8s 的 CNI 的设计。CNI 到底究竟是个什么东西，到底是不是和你想的一样那么困难。 问题IP 分配我们知道 k8s 整个集群里面有许多的 pod 那么 IP 怎么分配呢？总不能分配着之后出现 IP 冲突了吧。k8s 集群里面是不是能不有一个类似 DHCP 的东西来管这个 IP 地址分配呢？ 流量转发当流量打到宿主机上时，应该有一个什么设备来快速将请求转到对应的 pod 才对吧？那么谁来做这个事情呢？ 那为了解决上面的问题，我们一步步出发。 k8s 网络模型首先有关 k8s 的网络模型，官网有下面的描述：（https://kubernetes.io/zh/docs/concepts/cluster-administration/networking/） 节点上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信 节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有Pod通信 备 ...

你是否之前看过 k8s 的网络部分，第一次看是否会觉得很困难？或者说你有没有想过为什么 k8s 要这样设计它的网络，跨主机之间的网络通信究竟是怎么实现的？今天就来搞一篇干货，其实想写这个很久了，但是一直拖延症，这次正好碰到了一个新的点想让我仔细重新审视一下。 本文可能需要你有以下知识基础： docker基本原理 k8s基本架构 网络基础知识 本文不想引出过多细节的概念，因为网络本身确实有很多细节，每一个细节其实都可以写一篇，如果篇幅过长就会让人觉得没有重点，于是本文的重点将会放在从外部的大视角来看跨主机的网络通信，其中的细节先挖坑，后面慢慢填。 引子问题我们知道 k8s 往往会有很多主机进行集群的部署，k8s 要管理很多 pod，而这些 pod 里面有很多容器，每个容器都是一个小的服务，服务与服务之间往往需要互相访问，而 pod 并不总是在同一宿主机上，那么问题来了：k8s 是如何做到让服务之间能够互相访问的呢？这里网络的链路到底是怎么走的？ 时刻记住，本文将围绕这个问题展开。 假设和思考如果说每个容器都绑定一个宿主机的端口来进行通信，那么一旦容器很多就要占用非常多的宿主机的端 ...

我们知道 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 的内存确 ...

OCI runtime create failed: /var/lib/docker/overlay2/6573e40fef5bc51b4e565ad9554f225806f05a9f9089cc9e210c0e35a80e6e1f/merged/etc/resolv.conf: read-only 报错信息123456789Error response from daemon: OCI runtime create failed: container_linux.go:344: starting container process caused"process_linux.go:424: container init caused \"rootfs_linux.go:58: mounting\\\"/var/lib/docker/containers/1ec387b2e168281ed480c5050b08893976ac84a2751691e1a9429ae6a66a788a/resolv.conf\\\" to rootfs\\\&q ...

本博客持续更新…用于记录 k8s 使用过程中的很多的小技巧，也希望你能提供更多的小技巧来~ 图形化管理工具 lens图形化 k8s 管理工具: https://github.com/lensapp/lens 我觉得可以少部署一个 dashboard，并且比官方的 dashboard 好看很多 重启 deployment 命令我一开始总是 delete 一次 apply 一次，感觉很蠢，又换成调整 scle 但是还是很慢，查了之后发现原来本来就有重启的命令 1kubectl rollout restart deployment nginx-dep 查看链接配置信息1kubectl config view --minify --raw kubectx当你需要使用 kubectl 操作多个集群的时候，可以使用 kubectx 切换 context，非常方便 多集群管理切换工具：https://github.com/ahmetb/kubectx 更新 configmap 脚本对于配置文件 configmap 的更新我真的没有找到合适的命令，直接 使用 kubectl edit 那么原来的文件 ...

之前一直在寻找一个 k8s 监控的工具，因为一直使用的是本地的 lens 的客户端，虽然使用上已经非常方便了，但是其实对于资源消耗的监控少了一点，有些资源消耗并不是能容易看到，并且服务间依赖是没有办法表现出来的，后来发现了 Weave Scope 满足了我的需求。 链接https://github.com/weaveworks/scope 特点 资源监控：能实时反映整个集群中的资源状况 cpu 内存 使用情况 并且支持各种角度 服务间依赖：能通过图形展现出服务之间访问的依赖关系 容器交互：实时查看日志和描述信息 支持插件：可以通过插件扩展 部署方便：一个命令即可部署完成 监控页面资源监控 可以清楚的看到每个 node 的资源使用情况 服务间依赖 因为内部服务与服务之间通过 rpc 进行交互，从这里可以很容易看出，某个服务被别的五个服务所依赖调用 容器交互 可以看到占用的 cpu 和内存的情况，然后占用的端口等，还有日志信息 部署支持直接部署在 k8s 集群中，不需要额外的任何配置 https://www.weave.works/docs/scope/latest/installin ...

之前去过几次相关 go 的线下 meetup，这次相对来说比较大型一些，两天的听下来还是比较烧脑的，光是记录的笔记都有近千行了，整体来说收获很大。 有的人问，值票价吗？我回答：对喜欢的投资没有不值得的。对我来说值了~ 有的人问，值得去吗？我回答：不一定，因为可能在很多大佬看来能听到的点不多（采访了几位现场的大厂观众，普遍表示只有其中 1 到 2 场满足他们的要求）但是如果你的小白或者一年到两年左右，还是能见识很多东西的。可能是我听多了，和之前自己学到的有点重复… 下面是个人精炼总结，全是个人总结，自己如果对这个知识或者相关点比较清晰的我就没有记录了。其中会伴随一些个人思考和疑问，可以小声 bb 。大会分 1和 2 会场，所以只能选其中一个听，我也是记录我自己听到的，另外一个会场不清楚（我交叉穿来穿去的）注意并不是有的老师讲的真的不好，而是对我个人来说意义不明显，可能由于知识点已经掌握，也可能是由于工作上确实用不到哦 最后会附上会上笔记，仅做个人使用，乱了也不管~ 最后无论如何，感谢每一位老师的付出~~~ 要点总结 分布式数据库设计难题：数据分片，节点加入和减少 如果让你设计一个系统， ...

我们通常在部署 web 服务的时候往往会选择 nginx 作为最前面的一个狠角色，它的性能和能力大家也是有目共睹的，反向代理负载均衡等等。而作为后起之秀 caddy 却不被人所熟知，不过渐渐的也开始展露头角。今天我就来介绍这个 caddy ，为什么我会称它有可能成为下一个 nginx。 我先列举几个痛点你看下： nginx 的配置文件你是否感觉有时候有点臃肿 https 需要购买或者申请证书，然后配置是否觉得麻烦？ linux 下安装 nginx 需要部分依赖 而 caddy 确实给我了一种眼前一亮的感觉。 使用官网：https://caddyserver.com/ 安装https://caddyserver.com/docs/download安装很简单，直接下载对应的二进制文件即可，或者按照对应到操作系统去安装也可以。没有其他依赖。 使用https://caddyserver.com/docs/getting-started一个命令就可以启动，caddy，默认会去当前目录下寻找 Caddyfile 配置文件，也可以通过 –config 去指定文件位置 123caddy star ...

serverless 大环境下出现了 faas，即 function as a service，函数即服务；其意思也非常好理解，就是能将一个函数作为一个服务进行使用，用户只需要编写一个函数功能即可，不需要额外去关心别的东西。https://github.com/openfaas/faas 是其中的一种实现方式。 环境准备以下环境在 mac 上进行搭建： 首先需要准备 docker 和 kubernetes 的环境，先做 k8s 的环境直接能通过 docker 桌面进行配置，已经算是很方便了。 安装步骤openfaas-cli1curl -sL https://cli.openfaas.com | sh namespace123git clone https://github.com/openfaas/faas-netescd faas-neteskubectl apply -f namespaces.yml password12345678$ cat passwd.sh # PASSWORD=$(head -c 12 /dev/urandom | sha1sum |cut ...

在写 go 的时候，你使用 Mutex 的时候使用的是指针还是说没有使用指针，还是随意来？ 前两天我收到了下面这样的一个 PR，我突然就想到了这个问题，于是就有了这篇博客。 我一开始的想法其实我一开始的想法很简单，因为我一直没有使用指针 在我的某些印象中我曾经记得，使用锁不申明为指针是一个代码规范类似的东西 大多数的（我看过的一些）源码中，没有见过将锁申明为指针的用法 但是当时我没有办法回答这个 PR，你总不能说我是一厢情愿吧…需要一个更加合理的解释 仔细分析上网搜索一番https://www.reddit.com/r/golang/comments/6uyf16/confusion_about_mutex_and_reference/ 很多类似的问题都在问（你不用点开，只是举个例子） 问题关键sync.Mutex 这个东西不能被 copy！（这个我之前也是知道的，毕竟都分析过源码了） 刨根问底虽然这个锁不能被拷贝，那么就应该被申明为指针防止拷贝出现问题吗？ 别慌，先写个例子测测看 12345678910111213141516171819202122232425262728 ...