背景之前陆续写过一些和 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 ...继续阅读 (45)

背景前段时间公司领导让我排查一个关于在 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，所以我们只需要编写一个第三方包，任何项目依赖它之后在发 ...继续阅读 (65)

背景最近在给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 测试框架，提供了声明式的方式定义测试用例，也有着丰富断言功能。他们的安装都很简单 ...继续阅读 (70)

背景前两天收到业务反馈有一个 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 查看下线程的运行情 ...继续阅读 (65)

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

前言前段时间我们从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 的写 ...继续阅读 (64)

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

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

背景在整个大环境的降本增效的熏陶下，我们也不得不做好应对方案。根据对线上流量、存储以及系统资源的占用，发现我们的 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 扩容前先简单介绍些 ...继续阅读 (63)

起因因为订阅了 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 会议，也是每个人都可以参加。在远程的社区异步沟通过程中 ...继续阅读 (63)

技术阅读周刊，每周更新。历史更新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文件中统一定义所有路 ...继续阅读 (77)

原文链接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 ...继续阅读 (58)

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

原文链接前两天 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提案已经获得了社区批准开始开发，它 ...继续阅读 (135)

背景前段时间无意间看到一篇公众号招贤令：一起来搞一个新开源项目，作者介绍他想要做一个开源项目：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 ...继续阅读 (87)

最近我们的 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 ...继续阅读 (133)

技术阅读周刊，每周更新。历史更新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 ...继续阅读 (89)

在上一篇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 进行测试， ...继续阅读 (92)

技术阅读周刊，每周更新。历史更新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 ...继续阅读 (118)

在上一篇文章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 ...继续阅读 (103)

技术阅读周刊，每周更新。历史更新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&# ...继续阅读 (91)

Pulsar3.0 介绍Pulsar3.0 是 Pulsar 社区推出的第一个 LTS 长期支持版本。如图所示，LTS 版本会最长支持到 36 个月，而 Feature 版本最多只有六个月；类似于我们使用的JDK11,17,21都是可以长期使用的；所以也推荐大家都升级到 LTS 版本。作为首个 LTS 版本，3.0 自然也是自带了许多新特性，这个会在后续介绍。升级指南先来看看升级指南：在官方的兼容表中会发现：不推荐跨版本升级。也就是说如果你现在还在使用的是 2.10.x，那么推荐是先升级到 2.11.x 然后再升级到 3.0.x.而且根据我们的使用经验来看，首个版本是不保险的，即便是 LTS 版本；所以不推荐直接升级到 3.0.0，而是更推荐 3.0.1+，这个小版本会修复 3.0 所带来的一些 bug。先讲一下我们的升级流程，大家可以用做参考。升级前准备根据我们的使用场景，为了以防万一，首先需要将我们的插件依赖升级到对应的版本。其实简单来说就是更新下依赖，然后再重新打包，在后续的流程进行测试。预热镜像之后是预热镜像，我们使用harbor搭建了自己的 docker 镜像仓库，这样在升级重启镜像的时候可以更快的从内网拉取镜像。毕竟一个 pulsar-all 的镜像也不小，尽量的缩短启动时间。预热的过程也很简单：12345docker pull apachepulsar/pulsar- ...继续阅读 (80)

技术阅读周刊，每周更新。历史更新20231124：第七期20231201：第八期20231215：第十期moreA Comprehensive guide to Spring Boot 3.2 with Java 21, Virtual Threads, Spring Security, PostgreSQL, Flyway, Caching, Micrometer, Opentelemetry, JUnit 5, RabbitMQ, Keycloak Integration, and More! (10/17) | by Jonathan Chevalier | Nov, 2023 | MediumURL:https://medium.com/@jojoooo/exploring-a-base-spring-boot-application-with-java-21-virtual-thread-spring-security-flyway-c0fde13c1eca#551c本文讲解了基于最新的 Spring Boot3.2 和 Java 21 所使用到的技术栈数据库数据库使用Postgres15和 flyway 来管理数据库 schema 的迁移。异常处理Spring6 实现了新的RFC9457规范，实现以下接口：123456789101112131415161718 ...继续阅读 (107)

背景前段时间在使用 Pulsar 的 admin API 时，发现其中的一个接口响应非常慢：1admin.topics().getPartitionedStats(topic);使用 curl 拿到的响应结果非常大，同时也非常耗时：具体的 issue 在这里：https://github.com/apache/pulsar/issues/21200后面经过分析，是因为某些 topic 的生产者和消费者非常多，导致这个查询 topic 统计的接口数据量非常大。但在我这个场景其实是不需要这些生产者和消费者信息的，甚至导致业务无法正常使用，所以就建议新增两个参数可以过滤这两个字段。流程因为涉及到新增 API 了，所以社区维护者就建议我起草一个提案试试：什么时候需要提案此时就涉及到什么情况下需要给社区发起一个提案了。在官方的提案指南中有着详细的说明，简单来说就是：对任何模块新增了 API、或者是重大改动的新特性、监控指标、配置参数时都需要发起提案对应的如果只是对现有 bug 的修复、文档等一些可控的变更时，是不需要发起提案的，直接提交 PR 即可。提案步骤起草首先第一步就是根据官方模版起草一个提案：并发起一个 PR，如果不确定怎么写的话可以参考已经合并了的提案。邮件讨论之后则是将这个 PR 发送到开发组邮箱中，让社区成员参与讨论。这一步可能会比较耗时，提案内容可能会被反复修改。发起提案的一 ...继续阅读 (94)

技术阅读周刊，每周更新。历史更新20231117：第六期20231124：第七期20231201：第八期20231215：第九期moreGolang: 14 Shorthand Tricks You Might Not Know! | by Nidhi D | Dec, 2023 | CanopasURL:https://blog.canopas.com/golang-14-shorthand-tricks-you-might-not-know-8d8d21954c49同时声明和初始化变量123456// Long formvarmessagestringmessage ="Hello, Golang!"// Shorthandmessage :="Hello, Golang!"声明和初始化多个变量12345678// Long formvara, b, cinta =1b =2c =3// Shorthanda, b, c :=1,2,3交换变量123456789a, b :=1,2// Long formtemp := aa = bb = temp// Shorthanda, b = b, aDefer 函数调用12345678910// Long formfunccleanup(){// Cleanup logic}defercleanup()// Sho ...继续阅读 (102)

背景之前写过一篇文章VictoriaLogs：一款超低占用的 ElasticSearch 替代方案讲到了我们使用Victorialogs来存储 Pulsar 消息队列的消息 trace 信息。而其中的关键的埋点信息是通过 Pulsar 的BrokerInterceptor实现的，后面就有朋友咨询这块代码是否开源，目前是没有开源的，不过借此机会可以聊聊如何实现一个BrokerInterceptor插件，当前还没有相关的介绍文档。其实当时我在找BrokerInterceptor的相关资料时就发现官方并没有提供对应的开发文档。只有一个additional servlet的开发文档，而BrokerInterceptor只在YouTube上找到了一个社区分享的视频。虽说看视频可以跟着实现，但总归是没有文档方便。在这之前还是先讲讲BrokerInterceptor有什么用？其实从它所提供的接口就能看出，在消息到达 Broker 后的一些关键节点都提供了相关的接口，实现这些接口就能做很多事情了，比如我这里所需要的消息追踪。创建项目下面开始如何使用BrokerInterceptor：首先是创建一个Maven项目，然后引入相关的依赖：123456org.apache.pulsarpulsar-broker${pulsar.version}provided实现接口然后我们便可以实现 ...继续阅读 (85)

技术阅读周刊，每周更新。历史更新20231103：第四期20231107：第五期20231117：第六期20231124：第七期morePrometheus vs. VictoriaMetrics (VM) | Last9URL:https://last9.io/blog/prometheus-vs-victoriametrics/?ref=dailydev对比了 Prometheus 和 VM 的区别考虑到和云原生的环境的兼容性，那 Prometheus 可能更合适些，毕竟是 CNCF 组织下的项目。但如果考虑到性能、存储、资源占用性，VM 会更合适一些。28 - Rust in Action: 10 Project Ideas to Elevate Your SkillsURL:https://rust-trends.com/newsletter/rust-in-action-10-project-ideas-to-elevate-your-skills/?ref=dailydev这是一个 Rust 的 newsletter，介绍了十个项目 idea 可以提高你的 Rust 的水平，我看了下这些项目也不怎么限制语言，任何语言都可以尝试下。简易版的 grep 命令简单：读取文件根据搜索条件输出搜索结果，涉及到的技术栈：文件 IO正则表达式命令行工具短域名服务中等：接收一个长域名， ...继续阅读 (81)

技术阅读周刊，每周更新。历史更新20231107：第五期20231117：第六期20231124：第七期20231201：第八期more美团技术博客十周年，感谢一路相伴 - 美团技术团队URL:https://tech.meituan.com/2023/12/04/ten-years-of-meituan-technology-blog.html美团技术博客更新十周年了，这个博客确实在广大开发者心中都是有口皆碑的；记得当初在这里看过 HashMap 的原理分析、动态线程池等技术；现在也有加到订阅列表里，有更新时会第一时间阅读CompletableFuture原理与实践-外卖商家端API的异步化 - 美团技术团队URL:https://tech.meituan.com/2022/05/12/principles-and-practices-of-completablefuture.html本文描述了美团对 API 做异步优化的过程，最终选择了 CompletableFuture 的过程CompletableFuture使用起来的坑还是蛮多的，推荐大家都应该阅读下。明确知道自己的代码运行在哪个线程上，如果不传入线程池那就是公共的ForkJoinPool线程池，可能会有阻塞的情况；也可以直接传入自定义的线程池线程池循环使用可能会引起死锁，当 A 线程依赖于 B 线程的执行结果时，如果此时 ...继续阅读 (92)

当我们在生产环境发布应用时，必须要考虑到当前系统还有用户正在使用的情况，所以尽量需要做到不停机发版。所以在发布过程中理论上之前的 v1 版本依然存在，必须得等待 v2 版本启动成功后再删除历史的 v1 版本。如果 v2 版本启动失败 v1 版本不会做任何操作，依然能对外提供服务。滚动更新这是我们预期中的发布流程，要在 kubernetes 使用该功能也非常简单，只需要在 spec 下配置相关策略即可：123456spec:strategy:rollingUpdate:maxSurge:25%maxUnavailable:25%type:RollingUpdate这个配置的含义是：使用滚动更新，当然还有Recreate用于删除旧版本的 Pod，我们基本不会用这个策略。maxSurge：滚动更新过程中可以最多超过预期 Pod 数量的百分比，当然也可以填整数。maxUnavailable：滚动更新过程中最大不可用 Pod 数量超过预期的百分比。这样一旦我们更新了 Pod 的镜像时，kubernetes 就会先创建一个新版本的 Pod 等待他启动成功后再逐步更新剩下的 Pod。优雅停机滚动升级过程中不可避免的又会碰到一个优雅停机的问题，毕竟是需要停掉老的 Pod。这时我们需要注意两种情况：停机过程中，已经进入 Pod 的请求需要执行完毕才能退出。停机之后不能再有请求路由到已经停机的 Pod ...继续阅读 (86)

今天进入kubernetes的运维部分（并不是运维kubernetes，而是运维应用），其实日常我们大部分使用kubernetes的功能就是以往运维的工作，现在云原生将运维和研发关系变得更紧密了。今天主要讲解Probe探针相关的功能，探针最实用的功能就是可以控制应用优雅上线。就绪探针举个例子，当我们的 service 关联了多个 Pod 的时候，其中一个 Pod 正在重启但还没达到可以对外提供服务的状态，这时候如果有流量进入。那这个请求肯定就会出现异常，从而导致问题，所以我们需要一个和kubernetes沟通的渠道，告诉它什么时候可以将流量放进来。比如如图所示的情况，红色Pod在未就绪的时候就不会有流量。使用就绪探针就可以达到类似的效果：123456789readinessProbe:failureThreshold:3httpGet:path:/pingport:8081scheme:HTTPperiodSeconds:3successThreshold:1timeoutSeconds:1这个配置也很直接：配置一个 HTTP 的 ping 接口每三秒检测一次失败 3 次则认为检测失败成功一次就认为检测成功但没有配置就绪探针时，一旦 Pod 的Endpoint加入到 service 中(Pod 进入Running状态)，请求就有可能被转发过来，所以配置就绪探针是非常有必要的。启动探 ...继续阅读 (97)