前言

前段时间我们从 SkyWalking 切换到了 OpenTelemetry ，与此同时之前使用 SkyWalking 编写的插件也得转移到 OpenTelemetry 体系下。

我也写了相关介绍文章：
实战：如何优雅的从 SkyWalking 切换到 OpenTelemetry

好在 OpenTelemetry 社区也提供了 Extensions 的扩展开发，我们可以不用去修改社区发行版：opentelemetry-javaagent.jar 的源码也可以扩展其中的能力。

比如可以：

• 修改一些 trace，某些 span 不想记录等。
• 新增 metrics

背景

时间过得很快啊，一转眼已经到了 2024 年，还记得 15 年刚工作那会掌握个 SSM/H(Spring/Struts2/Mybatis/Hibernate) 框架就能应付大部分面试了。

现在 CS 专业的新同学估计都没听说过 SSM😢

恰好从我刚开始工作时的移动互联网热潮到电商->共享经济->toB 大热->如今我都经历了一遍，技术栈也有由最开始的单体应用+物理机发展到现在的 kubernetes 云原生架构。

当然中途也经历了几个大的阶段：
SOA服务化-> 微服务-> 云原生-> 服务网格-> 无服务等几个阶段。

最近一份工作又主要是在做基础架构，我认为了解的还算是比较全面的，所以本文我就以我的视角分享下我们在 2024 年应当使用哪些云原生技术栈，因为涉及到的技术组件比较多，就不过多讨论细节了。

但可以保证的是提到的技术栈都是我所用过的，优缺点都会提到，主打一个真实体验。

背景

最近公司将我们之前使用的链路工具切换为了 OpenTelemetry.

背景

在整个大环境的降本增效的熏陶下，我们也不得不做好应对方案。

根据对线上流量、存储以及系统资源的占用，发现我们的 Pulsar 集群有许多的冗余，所以考虑进行缩容从而减少资源浪费，最终也能省一些费用。

不过在缩容之前很有必要先聊聊扩容，Pulsar 一开始就是存算分离的架构（更多关于 Pulsar 架构的内容本文不做过多介绍，感兴趣的可以自行搜索），天然就非常适合 kubernetes 环境，也可以利用 kubernetes 的能力进行快速扩容。

起因

因为订阅了 Pulsar 的开发者邮件，前段时间看到一封标题为《(Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika》的邮件。

乍一看以为是欢迎 Asaf Mesika 成为 Committer，但仔细一看不太对劲，这内容也太多了，以往的欢迎都是简单的 Congratulations! 作为回复，这篇内容明显有点多了，于是便仔细看了下。

技术阅读周刊，每周更新。

原文链接

Pulsar3.2.0 于 2024-02-05 发布，提供了一些新特性和修复了一些 bug ，共有 57 位开发者提交了 88 次 commit。

以下是一些关键特性介绍.

今天是春节的最后一天，因为工作上临时有点事，很不情愿的打开电脑看着也就 10 天没看代码觉得非常陌生。

原文链接
前两天 Pulsar 社区发布了 2023 年年度回顾，去年我也花了一些时间参与社区，所以其中一些内容感受挺明显的，以下就是对一些重点内容的提炼。

背景

前段时间无意间看到一篇公众号 招贤令：一起来搞一个新开源项目，作者介绍他想要做一个开源项目：cprobe 用于整合目前市面上散落在各地的 Exporter，统一进行管理。

比如我们常用的 blackbox_exporter/mysqld_exporter 等。

以往的每一个 Exporter 都需要单独部署运维。