之前有朋友问如何做集成测试，今天就重点讲讲这个集成测试在开源项目中是如何做的。通常是需要对外提供服务的开源项目都需要集成测试：PulsarKafkaDubbo 等而只提供本地类库的项目通常只需要编写单元测试即可：HutoolApache Commmon以我接触到的服务型应用主要分为两类：一个是 Java 应用一个是 Golang 应用。🐳GolangGolang 因为工具链没有 Java 那么强大，所以大部分的集成测试的功能都是通过编写 Makefile 和 shell 脚本实现的。还是以我熟悉的 Pulsar 的 go-client 为例，它在 GitHub 的集成测试是通过 GitHub action 触发的，定义如下：最终调用的是 Makefile 中的 test 命令，并且把需要测试的 Golang 版本传入进去。Dockerfile：这个镜像简单来说就是将 Pulsar 的镜像作为基础运行镜像（这里面包含了 Pulsar 的服务端），然后将这个 pulsar-client-go 的代码复制进去编译。接着运行：1cd /pulsar/pulsar-client-go && ./scripts/run-ci.sh也就是测试脚本。测试脚本的逻辑也很简单：启动 pulsar 服务端运行测试代码因为所有的测试代码里连接服务端的地址都是localhost，所以可以直接连接。通过这里的 ...继续阅读 (59)

🧰Helm 的作用在开始前需要先对 kubernetes Operator 有个简单的认识。以为我们在编写部署一些简单Deployment的时候只需要自己编写一个 yaml 文件然后kubectl apply即可。123456789101112131415161718192021222324252627apiVersion:apps/v1kind:Deploymentmetadata:labels:app:k8s-combatname:k8s-combatspec:replicas:1selector:matchLabels:app:k8s-combattemplate:metadata:labels:app:k8s-combatspec:containers:-name:k8s-combatimage:crossoverjie/k8s-combat:v1imagePullPolicy:Alwaysresources:limits:cpu:"1"memory:300Mirequests:cpu:"0.1"memory:30Mi1kubectl apply -f deployment.yaml这对于一些并不复杂的项目来说完全够用了，但组件一多就比较麻烦了。这里以 Apache Pulsar 为例：它的核心组件有:BrokerProxyZookeeperBookkeeperProme ...继续阅读 (65)

原文链接：https://medium.com/@andreiboar/5-small-tips-i-recently-learned-in-go-cf52d50cf129让编译器计算数组数量我们在 Go 通常很少使用数组 arrays，一般使用切片 Slice 来代替；但是当你需要使用的时候，如果你对需要指定数量大小感到很烦时可以使用[...]让编译器自动帮我们计算数组大小：123456789101112packagemainimport"fmt"funcmain(){arr := [3]int{1,2,3}sameArr := [...]int{1,2,3}// Use ... instead of 3// Arrays are equivalentfmt.Println(arr)fmt.Println(sameArr)}使用 go run . 替换 go run main.go每当我用 Go 写第一行代码时，我都习惯于开始写main.go:1234567891011packagemainimport"fmt"funcmain(){sayHello()}funcsayHello(){fmt.Println("Hello!")}但是当main ...继续阅读 (56)

以前有写过两篇文章来简单聊过如何做开源的事情，最近我自己组了一个社区里面也有不少朋友对开源感兴趣，于是我便根据自己的经验系统的梳理了一些关于开源的事情。新手如何快速参与开源项目手把手教你为开源项目贡献代码有兴趣的可以先看看之前这两篇。🔎如何找到自己感兴趣的开源项目首先第一步先想清楚自己搞开源的目的是什么：参考社区大佬的代码，提升技术丰富个人履历，提高面试通过率更功利一点就是想成为某个项目的Committer/PMC单纯喜欢分享，热爱开源，认可开源改变世界💪。我人为前面三种都是一个目的，提升自己获得后续的好处；最后一种则是妥妥的纯热爱。以我个人来说，我两者都沾一点；我相信大部分人都是前面三类的目的，到这里我可能要先浇点冷水。往往一个开源项目从你熟悉它开始到提第一个 PR 然后到合并中间经历的时间可能是大大超出你的预期的。特别是越大型越专业的项目（我相信你也是想加入这类有一定知名度的项目）。因为开源社区大部分都是执行异步沟通，与即时通讯的快速反馈不同，甚至还有不少 reviewer 处于不同的时区。所以一开始就想做好心理预期，不要指望着我给某个项目提交一个很牛逼的功能，然后他们快速 review 合并，然后给你 commit 权限。而且有不少开源项目是由某一个公司主导的，比如（Pulsar、Golang、Kafka），他们可能对于外部社区来的新手并不那么上心，一个 PR 晾在 ...继续阅读 (56)

背景在上一篇《从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅》中在最后提到在做一些 Trace 的定制开发。到现在差不多算是完成了，可以和大家分享一下。我们的需求是这样的：假设现在有三个服务：ServiceA、ServiceB、ServiceCServiceA对外提供了一个 http 接口request，在这个接口会调用ServiceB的order订单接口创建订单，同时serviceB调用serviceC的 pay 接口。整个调用关系如上图所示。默认情况下 span 中的 attribute 会记录当前 span 的一些信息，比如：这些都是当前一些当前 span 内置的信息，比如当前 gRPC 接口的一些基本数据：服务名、ip、端口等信息。但这里并没有上游的一些信息，虽然我们可以通过 Jaeger 的树状图得知上游是哪个应用调用过来的，但是一旦某个 span 下有多个子 span 的调用，就没办法很直观知道这个子 span 的上游是由谁发起的调用。比如如下这个链路：当一个调用链非常长，同时也非常复杂时，没办法第一时间知道某一个 span 的上游到底是谁发起的，需要手动一层层的去折叠，或者全靠眼睛去找。预期效果为此我们希望的效果是可以通过给每一个子 span 中加入两个 attribute，来标明它的父调用来源。比如在 serviceB 中的所有 span 中 ...继续阅读 (64)

在上一篇：从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅我们讲解了 Trace 的一些核心概念：TraceSpanContextBaggage 等这次我们来讲另一个话题Metrics。背景关于 metrics 我最早接触相关概念的就是 prometheus，它是第二个加入 CNCF（云原生）社区的项目（第一个是 kubernetes），可见在云原生领域 Metrics 指标监控从诞生之初就是一个非常重要的组件。现实也确实如此，如今只要使用到了 kubernetes 相关的项目，对其监控就是必不可少的。当然也不止是云原生的项目才需要 Metrics 指标监控，我们任何一个业务都是需要的，不然我们的服务运行对开发运维来说都是一个黑盒，无法知道此时系统的运行情况，因此才需要我们的业务系统将一些关键运行指标暴露出来。业务数据：比如订单的增长率、销售金额等业务数据；同时还有应用自身的资源占用情况：QPSLatency内存CPU 等信息。在使用 OpenTelemetry 之前，因为 prometheus 是这部分的绝对标准，所以我们通常都会使用 prometheus 的包来暴露这些指标：123456789101112The clientio.prometheussimpleclient0.16.0Hotspot JVM metricsio.prometheussimp ...继续阅读 (58)

在之前写过两篇比较系统的关于 OpenTelemetry 的文章：OpenTelemetry 实践指南：历史、架构与基本概念实操 OpenTelemetry：通过 Demo 掌握微服务监控的艺术从基本概念到如何部署 demo 实战了解 OpenTelemetry，从那个 demo 中也可以得知整个 OpenTelemetry 体系的复杂性，包含了太多的组件和概念。为了能更清晰的了解每个关键组件的作用以及原理，我打算分为几期来讲解 OpenTelemetry 的三个核心组件：TraceMetricsLogs首先以 Trace 讲起。Trace开始之前还是先复习一下 Trace 的历史背景。如今现代的分布式追踪的起源源自于 Google 在 2010 年发布的一篇论文：Dapper, a Large-Scale Distributed Systems Tracing Infrastructure在这篇论文中提出了分布式追踪的几个核心概念：TraceSpanSpan 的一些基础数据结构可视化追踪以及展示之后 Twitter 受到了 Dapper 的启发开源了现在我们熟知的Zipkin，包含了存储和可视化 UI 展示我们的追踪链路。Uber 也在 2015 年开源了Jaeger项目，它的功能和 Zipkin 类似，但目前我们用的较多的还是 Jaeger；现在已经成为 CNCF 的托管项目。 ...继续阅读 (77)

原文链接:https://overcast.blog/13-kubernetes-tricks-you-didnt-know-647de6364472使用 PreStop 优雅关闭 Pod123456789101112apiVersion:v1kind:Podmetadata:name:graceful-shutdown-examplespec:containers:-name:sample-containerimage:nginxlifecycle:preStop:exec:command:["/bin/sh","-c","sleep 30 && nginx -s quit"]PreStop 允许 Pod 在终止前执行一个命令或者是脚本，使用它就可以在应用退出前释放一些资源，确保应用可以优雅退出。比如可以在 Nginx 的 Pod 退出前将当前的请求执行完毕。使用临时容器调试 Pod临时容器可以不修改一个运行的容器的前提下调试容器，可以很方便的调试一些生产环境的 bug，可以避免重启应用。1kubectl alpha debug -it podname --image=busybox --target=containername生产环境谨慎使用，只有在当前环境下无法排查问题的时候才使用。基于自定义的 Metrics 自动扩容Podkubernetes 是提供了 HPA 机制可以 ...继续阅读 (61)

前言在上一篇文章OpenTelemetry 实践指南：历史、架构与基本概念中回顾了可观测性的历史以及介绍了一些 OpenTelemetry 的基础概念，同时也介绍了 OpenTelemetry 社区常用的开源项目。基础背景知识了解后，这篇就来介绍一下使用 OpenTelemetry 如何实战部署应用，同时在一个可视化页面查看 trace、metric 等信息。项目介绍我们参考官方文档构建几个 spring boot 、Golang 项目再配合 Agent 其实也可以很方便的集成 OpenTelemetry。但是要完整的体验 OpenTelemetry 的所有功能，包含 trace、logs、metrics，还有社区这么多语言的支持其实还是比较麻烦的。我们还需要单独部署 collector、存储的 backend service 等组件、包括 trace UI 展示所需要的 Jaeger，metric 所需要的 grafana 等。这些所有东西都自己从头弄的话还是比较费时，不过好在社区已经将这些步骤都考虑到了。特地为大家写了一个opentelemetry-demo。这个项目模拟了一个微服务版本的电子商城，主要包含了以下一些项目：ServiceLanguageDescriptionaccountingserviceGo处理和计算订单数据adserviceJava广告服务cartserv ...继续阅读 (67)

背景之前陆续写过一些和 OpenTelemetry 相关的文章：实战：如何优雅的从 Skywalking 切换到 OpenTelemetry实战：如何编写一个 OpenTelemetry Extensions从一个 JDK21+OpenTelemetry 不兼容的问题讲起这些内容的前提是最好有一些 OpenTelemetry 的背景知识，看起来就不会那么枯燥，为此这篇文章就来做一个入门科普，方便一些对 OpenTelemetry 不是那么熟的朋友快速掌握一些 OpenTelemetry 的基本概念。历史发展早在OpenTelemetry诞生之前可观测性这个概念就一直存在了，我记得我最早接触到这个概念是在 16 年当时的公司所使用的一个产品：pinpoint现如今这个项目依然比较活跃。依然还记得当时通过它可以直接看到项目调用的拓扑图，在时间坐标上框出高延迟的点就能列出这些请求，同时还能查看此时的运行日志。这样强大的功能对于一个刚工作一年的小白来说冲击力实属太大了一点。后来才了解到 pinpoint 属于 APM 这类产品，类似的产品还有：Apache SkyWalking美团的 CAT 等他们都是可以用于性能分析和链路追踪的产品，到后来公司的运维层面也接入过 Zabbix、open-falcon 之类的产品：17之后全面切换到 spring boot 时，也用过社区提供的spring ...继续阅读 (61)

背景前段时间公司领导让我排查一个关于在 JDK21 环境中使用 Spring Boot 配合一个 JDK18 新增的一个 SPI(java.net.spi.InetAddressResolverProvider) 不生效的问题。但这个不生效的前置条件有点多：JDK 的版本得在 18+SpringBoot3.x还在额外再配合使用-javaagent:opentelemetry-javaagent.jar使用，也就是 OpenTelemetry 提供的 agent。才会导致自定义的InetAddressResolverProvider无法正常工作。在复现这个问题之前先简单介绍下java.net.spi.InetAddressResolverProvider这个 SPI；它是在 JDK18 之后才提供的，在这之前我们使用InetAddress的内置解析器来解析主机名和 IP 地址，但这个解析器之前是不可以自定义的。在某些场景下会不太方便，比如我们需要请求order.service这个域名时希望可以请求到某一个具体 IP 地址上，我们可以自己配置 host ，或者使用服务发现机制来实现。但现在通过InetAddressResolverProvider就可以定义在请求这个域名的时候返回一个我们预期的 IP 地址。同时由于它是一个 SPI，所以我们只需要编写一个第三方包，任何项目依赖它之后在发 ...继续阅读 (81)

背景最近在给opentelemetry-operator提交一个标签选择器的功能时，因为当时修改的函数是私有的，无法添加单测函数，所以社区建议我补充一个e2e test.因为在当前的版本下，只要给 deployment 打上了instrumentation.opentelemetry.io/inject-java: "true"这类注解就会给该 deployment 注入 agent。但没办法指定不同的 agent 版本（或者不同的环境变量），所以希望可以新增一个选择器，同时可以针对不同的 deployment 维护不同版本的Instrumentation(是用于控制需要注入 deployment 的资源)；这样就可以灵活控制了。在这之前我其实也很少做 kubernetes 的 operator 开发，对如何做 kubernetes 的 e2e 测试也比较陌生，好在社区提供了详细的贡献文档。安装简单来说需要两个关键组件：kind: kubernetes in docker，是可以在本地利用 docker 启动一个 kubernetes 集群的工具，通常用于在本地进行开发、测试关于 kubernetes 相关的功能。安装 kind 的前提是本地已经安装好了 docker。chainsaw: 一个 e2e 测试框架，提供了声明式的方式定义测试用例，也有着丰富断言功能。他们的安装都很简单 ...继续阅读 (88)

背景前两天收到业务反馈有一个 topic 的分区消息堆积了：根据之前的经验来看，要么是业务消费逻辑出现问题导致消费过慢，当然也有小概率是消息队列的 Bug（我们使用的是 pulsar）。排查通过排查，发现确实是在一点多的时候消息堆积了（后面是修复之后堆积开始下降）。于是我在刚才堆积处查看了一条堆积消息的列表：获取到其中一条消息的messageId.这里本质上使用的是 pulsar-admin 的 API。org.apache.pulsar.client.admin.Topics#peekMessages再通过这条消息的 id （为了演示，这里的 messageId 可能不一样）在我们的 pulsar 消息链路系统中找到了消息的发送链路：通过这个链路会发现消息一直在推送，但就是没有收到客户端的 ACK 响应。相关的消息链路埋点可以参考这里：如何编写一个 Pulsar Broker Interceptor 插件简单来说就是在以下几个 broker 提供的拦截器接口加上埋点数据即可：messageProducedmessageDispatchedmessageAcked既然知道了是客户端没有响应 ACK，那就得知道客户端此时在干什么。首先排查了 JVM 内存、CPU 等监控情况，发现一切都挺正常的，这段时间没有明显的尖刺。Arthas 排查于是便准备使用 arthas 查看下线程的运行情 ...继续阅读 (81)

当我们没有使用云原生方案部署应用时采用的日志方案往往是 ELK 技术栈。这套技术方案比较成熟，稳定性也很高，所以几乎成为了当时的标配。可是随着我们使用 kubernetes 步入云原生的时代后， kubernetes 把以往的操作系统上的许多底层都屏蔽，再由他提供了一些标准接口。同时在 kubernetes 中的日志来源也比传统虚拟机多，比如可能有容器、kubernetes 自身的事件、日志等。我们的日志采集方案也得与时俱进，kubernetes 的官方博客有介绍提供一下几种方案：节点采集第一种方案是在节点中采集日志，我们知道 kubernetes 是分为 master 调度节点以及 worker 工作节点；我们的应用都是运行在 worker 节点中的。在 kubernetes 环境中更推荐使用标准的 stdout/stderr 作为日志输出，这样 kubernetes 更方便做统一处理。以我们的 docker 运行时为例，默认情况下我们的标准输入文件会写入到/var/log目录中。如上图所示：我们可以在 kubernetes 的每一个 worker 节点中部署一个DaemonSet类型的采集器（filebeat 等），再由他去采集该节点下/var/log的日志，最终由他将日志采集后发往日志处理的后端，比如 elasticsearch 等组件中。这种方案的好处是资源占用较 ...继续阅读 (103)

前言前段时间我们从SkyWalking切换到了OpenTelemetry，与此同时之前使用 SkyWalking 编写的插件也得转移到 OpenTelemetry 体系下。我也写了相关介绍文章：实战：如何优雅的从 SkyWalking 切换到 OpenTelemetry好在 OpenTelemetry 社区也提供了 Extensions 的扩展开发，我们可以不用去修改社区发行版：opentelemetry-javaagent.jar的源码也可以扩展其中的能力。比如可以：修改一些 trace，某些 span 不想记录等。新增 metrics这次我准备编写的插件也是和 metrics 有关的，因为 pulsar 的 Java sdk 中并没有暴露客户端的一些监控指标，所以我需要在插件中拦截到一些关键函数，然后执行暴露出指标。截止到本文编写的时候， Pulsar 社区也已经将Java-client集成了 OpenTelemetry，后续正式发版后我这个插件也可以光荣退休了。由于 OpenTelemetry 社区还处于高速发展阶段，我在中文社区没有找到类似的参考文章（甚至英文社区也没有，只有一些 example 代码，或者是只有去社区成熟插件里去参考代码）其中也踩了不少坑，所以觉得非常有必要分享出来帮助大家减少遇到同类问题的机会。开发流程OpenTelemetry extension 的写 ...继续阅读 (78)

背景时间过得很快啊，一转眼已经到了 2024 年，还记得 15 年刚工作那会掌握个SSM/H(Spring/Struts2/Mybatis/Hibernate)框架就能应付大部分面试了。现在 CS 专业的新同学估计都没听说过 SSM😢恰好从我刚开始工作时的移动互联网热潮到电商->共享经济->toB 大热->如今我都经历了一遍，技术栈也有由最开始的单体应用+物理机发展到现在的 kubernetes 云原生架构。当然中途也经历了几个大的阶段：SOA服务化-> 微服务-> 云原生-> 服务网格-> 无服务等几个阶段。最近一份工作又主要是在做基础架构，我认为了解的还算是比较全面的，所以本文我就以我的视角分享下我们在 2024 年应当使用哪些云原生技术栈，因为涉及到的技术组件比较多，就不过多讨论细节了。但可以保证的是提到的技术栈都是我所用过的，优缺点都会提到，主打一个真实体验。操作系统首先是操作系统，这里有别于以往我们传统的操作系统(Linux/Windows Server/MacOS)，主要指的是云原生的操作系统，没有太多可以选择的余地，那就是kubernetes。不过怎么维护好 kubernetes 是一个难点问题，还记得去年下半年滴滴出过一次事故，网传就是 kubernetes 升级出现的问题。根据我们的经验来看，对于小团队更建议直接托管给云厂商，维护 kubern ...继续阅读 (83)

背景最近公司将我们之前使用的链路工具切换为了OpenTelemetry.我们的技术栈是：123456OTLPClient──────────►Collect────────►StartRocks(Agent) ▲││Jaeger其中客户端使用 OpenTelemetry 提供的 Java Agent 进行埋点收集数据，再由 Agent 通过 OTLP(OpenTelemetry Protocol) 协议将数据发往 Collector，在Collector中我们可以自行任意处理数据，并决定将这些数据如何存储（这点在以往的 SkyWalking 体系中是很难自定义的）这里我们将数据写入 StartRocks 中，供之后的 UI 层进行查看。OpenTelemetry是可观测系统的新标准，基于它可以兼容以前使用的 Prometheus、 victoriametrics、skywalking 等系统，同时还可以灵活扩展，不用与任何但一生态或技术栈进行绑定。更多关于 OTel 的内容会在今后介绍。难点其中有一个关键问题就是：如何在线上进行无缝切换。虽然我们内部的发布系统已经支持重新发布后就会切换到新的链路，也可以让业务自行发布然后逐步的切换到新的系统，这样也是最保险的方式。但这样会有几个问题：当存在调用依赖的系统没有全部切换为新链路 ...继续阅读 (78)

背景在整个大环境的降本增效的熏陶下，我们也不得不做好应对方案。根据对线上流量、存储以及系统资源的占用，发现我们的 Pulsar 集群有许多的冗余，所以考虑进行缩容从而减少资源浪费，最终也能省一些费用。不过在缩容之前很有必要先聊聊扩容，Pulsar 一开始就是存算分离的架构（更多关于 Pulsar 架构的内容本文不做过多介绍，感兴趣的可以自行搜索），天然就非常适合 kubernetes 环境，也可以利用kubernetes的能力进行快速扩容。扩容Pulsar 的扩容相对比较简单，在 kubernetes 环境下只需要修改副本即可。Broker当我们的 broker 层出现瓶颈时（比如 CPU、内存负载较高、GC 频繁时）可以考虑扩容。计算层都扩容了，也需要根据流量计算下存储层是否够用。如果我们使用的是 helm 安装的 Pulsar 集群，那只需要修改对于的副本数即可。1234broker:configurationcomponent:brokerreplicaCount:3->5当我们将副本数从 3 增加到 5 之后 kubernetes 会自动拉起新增的两个 Pod，之后我们啥也不需要做了。Pulsar 的负载均衡器会自动感知到新增两个 broker 的加入，从而帮我们将一些负载高的节点的流量迁移到新增的节点中。Bookkeeper在介绍 bookkeeper 扩容前先简单介绍些 ...继续阅读 (79)

起因因为订阅了 Pulsar 的开发者邮件，前段时间看到一封标题为《(Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika》的邮件。乍一看以为是欢迎Asaf Mesika成为 Committer，但仔细一看不太对劲，这内容也太多了，以往的欢迎都是简单的Congratulations!作为回复，这篇内容明显有点多了，于是便仔细看了下。争论大概的意思是这封邮件的作者Kalwit对成为 Committer 的标准产生了疑问：他觉得本次提名成为 Committer 的大部分贡献都是一些文档相关的内容，还有少部分是与监控相关的提案。他们团队使用 Pulsar 有一段时间了，但目前还未发现稳定的 Pulsar 版本；大部分的 Review 都是来自同一公司（streamnative）。看起来是整个 Pulsar 项目由某一家公司控制了，他们当初选择从 Kafka 切换到 Pulsar 就是因为 Kafka 由 Confluent 控制，才选择一个更加开放的社区。这样的一封有着“讨伐”意味的邮件一经发出，自然是一石激起千层浪，社区里很多成员都发表了回复。这里我挑选了几个代表性的回复：大概意思就是 Pulsar 是一个开放性项目，任何人都可以参加，每两周也有 Zoom 会议，也是每个人都可以参加。在远程的社区异步沟通过程中 ...继续阅读 (76)

技术阅读周刊，每周更新。历史更新20231122：第十一期20231129：第十二期20240105：第十三期：一些提高生产力的终端命令20240112：第十四期：Golang 作者 Rob Pike 在 GopherConAU 上的分享How I write HTTP services in Go after 13 years使用NewServer函数构建服务实例,利用依赖注入方式将所有的依赖参数包含进来。1234567891011121314151617181920funcNewServer(logger *Loggerconfig *ConfigcommentStore *commentStoreanotherStore *anotherStore)http.Handler {mux := http.NewServeMux()addRoutes(mux,Logger,Config,commentStore,anotherStore,)varhandler http.Handler = muxhandler = someMiddleware(handler)handler = someMiddleware2(handler)handler = someMiddleware3(handler)returnhandler}在routes.go文件中统一定义所有路 ...继续阅读 (95)

原文链接Pulsar3.2.0 于 2024-02-05 发布，提供了一些新特性和修复了一些 bug ，共有 57 位开发者提交了 88 次 commit。以下是一些关键特性介绍.速率限制在 3.2 中对速率限制做了重构：PIP-322 Pulsar Rate Limiting Refactoring.速率限制器是 Pulsar 服务质量（Qos）保证的重要渠道，主要解决了以下问题：速率限制器的高 CPU 复制大量的锁竞争会影响 Netty IO 线程，从而增加其他 topic 的发送延迟更好的封装代码Topic 压缩时会删除 Null-key 消息Pulsar 支持Topic 压缩，在 3.2 之前的版本中 topic 压缩时会保留 Null key 的消息。从 3.2.0 开始将会修改默认行为，默认不会保留，这可以减少存储。如果想要恢复以前的策略可以在 broker.conf 中新增配置：1topicCompactionRetainNullKey=true具体信息请参考：PIP-318.WebSocket 的新特性支持多个 topic 消费：PIP-307.端对端加密PIP-290.CLI 的用户体验改进CLI 可以配置内存限制允许通过正则或者是文件批量删除 topic通过pulsar-admin clusters list可以打印当前使用的 cluster构建系统的改进3.2 ...继续阅读 (71)

今天是春节的最后一天，因为工作上临时有点事，很不情愿的打开电脑看着也就 10 天没看代码觉得非常陌生。之后便准备将迟迟未写的 2023 总结补完，这个传统从16年至今已经坚持将近 7 年时间了，今年当然也不能意外。健身今年要说最让我印象深刻的事就是健身了，为此我投入了大量的时间。我记得是在 22 年四月份当时是因为确实长胖太明显了，下定决心找个教练进行训练，效果确实也有。去年也分享过，最后从 75kg 减到 66kg；但大部分时间都是被动的进行训练，所以到了 23 年初的时候其实就反弹不少了。而今年最大的不同是我由原先的被动健身改为主动了，甚至到后面一天不练还浑身不舒服。所以今年我大部分时间都是自己锻炼，因为我是个 I 人，比较喜欢一个人，所以夏天的时候是每天早上 7 点多去健身房然后再去公司。到了冬天早上确实是起不来，就改为了中午去训练。就这样不知不觉就坚持了大半年，直到现在。训练日志见文末。甚至现在偶尔找教练训练时，他说我比他练的都勤🤣。最终达到的效果就是生活作息更加规律，同时身体素质也是肉眼可见的提升。自重引体从一个不能做->反握->对握->正握->正握做组俯卧撑从 5 个->10个/组->15个/组->25个/组->一次最多做 40 个->钻石俯卧撑 15/组其余的就是胸肌有些轮廓、肩部也比以往更圆润一些，腹肌在某些特定角度也可以若隐 ...继续阅读 (101)

原文链接前两天 Pulsar 社区发布了 2023 年年度回顾，去年我也花了一些时间参与社区，所以其中一些内容感受挺明显的，以下就是对一些重点内容的提炼。2023 年是一个重要的里程碑，参与主仓库贡献的开发者达到了 600 位。自从 Pulsar 从 2018 毕业成为 Apache 顶级项目至今一共又 12K+ 的代码提交次数、639 位贡献者、12.2k star、3.5k fork、10k+ 的 slack 用户。2023 高光时刻第一个 LTS 3.0 里程碑版本社区发布 Apache Pulsar 3.0，这是第一个长期支持 （LTS） 版本，从 Pulsar 3.0 开始，可以满足不同用户对稳定性和新功能的需求，同时减轻维护历史版本的负担。以往的版本发布周期很短，一般是 3～4 个月，为了可以跟上社区新版，往往需要不停的升级，对维护中的负担较大。今后的维护时间表如上图，以稳定为主的团队可以选择 LTS 版本，追求新功能的团队可以选择 feature 版本。新的官方网站https://pulsar.apache.org/官方网站得到了新的设计。Pulsar Admin Go Library提供了 Pulsar Admin Go 的客户端，方便 Go 用户管理 Pulsar 资源使用 OTel 增强 Pulsar 的可观测系统PIP-264提案已经获得了社区批准开始开发，它 ...继续阅读 (153)

背景前段时间无意间看到一篇公众号招贤令：一起来搞一个新开源项目，作者介绍他想要做一个开源项目：cprobe用于整合目前市面上散落在各地的Exporter，统一进行管理。比如我们常用的blackbox_exporter/mysqld_exporter等。以往的每一个 Exporter 都需要单独部署运维。同时又完全兼容Prometheus生态，也可以复用现有的监控面板。恰好这段时间我也在公司从事可观测性相关的业务，发现这确实是一个痛点。于是便一直在关注这个项目，同时也做了些贡献；因为该项目的核心是用于整合 exporter，所以为其编写插件也是非常重要的贡献了。编写插件整个项目执行流程图如下：可以看到编写插件最核心的便是自定义插件解析自定义的配置文件、抓取指标的逻辑。比如我们需要在配置中指定抓取目标的域名、抓取规则等。这里cprobe已经抽象出了两个接口，我们只需要做对应的实现即可。123456typePlugininterface{// ParseConfig is used to parse configParseConfig(baseDirstring, bs []byte) (any,error)// Scrape is used to scrape metrics, cfg need to be cast specific cfgScrape(ctx contex ...继续阅读 (102)

最近我们的 Pulsar 存储有很长一段时间数据一直得不到回收，但消息确实已经是 ACK 了，理论上应该是会被回收的，随着时间流逝不但没回收还一直再涨，最后在没找到原因的情况下就只有一直不停的扩容。最后磁盘是得到了回收，过程先不表，之后再讨论。为了防止类似的问题再次发生，我们希望可以监控到磁盘维度，能够列出各个日志文件的大小以及创建时间。这时就需要对Pulsar的存储模型有一定的了解，也就有了这篇文章。讲到 Pulsar 的存储模型，本质上就是 Bookkeeper 的存储模型。Pulsar 所有的消息读写都是通过 Bookkeeper 实现的。Bookkeeper是一个可扩展、可容错、低延迟的日志存储数据库，基于 Append Only 模型。（数据只能追加不能修改）这里我利用 Pulsar 和 Bookkeeper 的 Admin API 列出了 Broker 和 BK 中 Ledger 分别占用的磁盘空间。关于这个如何获取和计算的，后续也准备提交给社区。背景但和我们实际kubernetes中的磁盘占用量依然对不上，所以就想看看在 BK 中实际的存储日志和Ledger到底差在哪里。知道 Ledger 就可以通过 Ledger 的元数据中找到对应的 topic，从而判断哪些 topic 的数据导致统计不能匹配。Bookkeeper 有提提供一个Admin API 可以返回当前 B ...继续阅读 (149)

技术阅读周刊，每周更新。历史更新20231215：第十期20231122：第十一期20231129：第十二期20240105：第十三期：一些提高生产力的终端命令What We Got Right, What We Got WrongURL:https://commandcenter.blogspot.com/2024/01/what-we-got-right-what-we-got-wrong.html?utm_source=changelog-news本文是Golang核心作者之一Rob Pike去年底在澳大利亚 GopherConAU 会议上的分享；总结了 Go 语言 14 年来的做对了哪些事情、做错了哪些事情。主要包括：语言涉及社区管理项目运营等方面，感兴趣的还可以看油管视频。https://www.youtube.com/watch?v=yE5Tpp2BSGwTop 10 Platform Engineering Tools You Should Consider in 2024 | by Romaric Philogène | Jan, 2024 | MediumURL:https://medium.com/@rphilogene/top-10-platform-engineering-tools-you-should-consider-in-2024-892e6e211 ...继续阅读 (106)

在上一篇Pulsar3.0新功能介绍中提到，在升级到 3.0 的过程中碰到一个致命的问题，就是升级之后 topic 被删除了。正好最近社区也补充了相关细节，本次也接着这个机会再次复盘一下，毕竟这是一个非常致命的 Bug。现象先来回顾下当时的情况：升级当晚没有出现啥问题，各个流量指标、生产者、消费者数量都是在正常范围内波动。事后才知道，因为只是删除了很少一部分的 topic，所以从监控中反应不出来。早上上班后陆续有部分业务反馈应用连不上 topic，提示topic nof found.1org.springframework.beans.factory.BeanCreationException: Error creating bean with name'Producer': Invocation of init method failed; nested exception is org.apache.pulsar.client.api.PulsarClientException$TopicDoesNotExistException: Topic Not Found.因为只是部分应用在反馈，所以起初怀疑是 broker 升级之后导致老版本的 pulsar-client 存在兼容性问题。所以我就拿了平时测试用的 topic 再配合多个老版本的 sdk 进行测试， ...继续阅读 (109)

技术阅读周刊，每周更新。历史更新20231201：第八期20231215：第十期20231122：第十一期20231129：第十二期more生存还是毁灭？一文带你看懂 Pulsar 的消息保留和过期策略-腾讯云开发者社区-腾讯云URL:https://cloud.tencent.com/developer/article/2245703本文分析了 Pulsar 消息的生命周期，主要是如何保留和回收消息TTL（Time To Live）：使得未 ACK 的消息进入 ACK 状态，供后续回收的时候使用Retention保留策略：默认情况下已经被所有订阅者 ACK 的消息会被立即回收掉，配置保留策略可以保留一定时间、一定数量的 ACK 消息，利用这个时间差可以做消息回查Backlog: 未被确认消息的集合，也就是积压消息；也可以配置只保留一定时间、数量的消息，从而减少磁盘压力；当超过我们配置的阈值时，有以下几种选择：这些流行的K8S工具，你都用上了吗URL:https://mp.weixin.qq.com/s/EC-YLm71YB4cMDoTjrdfyg推荐了一些常用的 kubernetes 管理工具Helm: kubernetes 平台的必备的包管理工具本地运行的 kubernetes 工具：有时候需要在本地进行开发和测试，这类工具就很有用：Docker Desktopminikube ...继续阅读 (133)

在上一篇文章Pulsar3.0 升级指北讲了关于升级 Pulsar 集群的关键步骤与灾难恢复，本次主要分享一些Pulsar3.0的新功能与可能带来的一些问题。升级后所遇到的问题先来个欲扬先抑，聊聊升级后所碰到的问题吧。其中有两个问题我们感知比较明显，特别是第一个。topic被删除我们在上个月某天凌晨从2.11.2升级到3.0.1之后，进行了上一篇文章中所提到的功能性测试，发现没什么问题，觉得一切都还挺顺利的，半个小时搞定后就下班了。结果哪知道第二天是被电话叫醒的，有部分业务反馈业务重启之后就无法连接到 Pulsar 了。最终定位是 topic 被删除了。其中的细节还蛮多的，修复过程也是一波三折，后面我会单独写一篇文章来详细梳理这个过程。在这个 issue 和 PR 中有详细的描述：https://github.com/apache/pulsar/issues/21653https://github.com/apache/pulsar/pull/21704感兴趣的朋友也可以先看看。监控指标丢失第二个问题不是那么严重，是升级后发现 bookkeeper 的一些监控指标丢失了，比如这里的写入延迟：我也定位了蛮久，但不管是官方的 docker 镜像还是源码编译都无法复现这个问题。最终丢失的指标有这些：bookkeeper_server_ADD_ENTRY_REQUESTbookkeepe ...继续阅读 (118)

技术阅读周刊，每周更新。历史更新20231201：第八期20231215：第十期20231122：第十一期moreDeno vs Go: Native hello world performance | Tech TonicURL:https://medium.com/deno-the-complete-reference/deno-vs-go-native-hello-world-performance-c57d8fc13c75使用 Deno 和 Go 进行基本的接口对比MacBook Pro M2 with 16GB of RAMDenov1.38.0Go v1.21.3都是最简单的 httpServer:12345678910111213Deno.serve({port:3000,},(req) =>{try{constpathName =newURL(req.url).pathname;if(pathName !=="/") {returnnewResponse(null, {status:404});}returnnewResponse("Hello world!");}catch(e) {returnnewResponse(null, {status:500&# ...继续阅读 (108)