当我们没有使用云原生方案部署应用时采用的日志方案往往是 ELK 技术栈。

这套技术方案比较成熟，稳定性也很高，所以几乎成为了当时的标配。

可是随着我们使用 kubernetes 步入云原生的时代后， kubernetes 把以往的操作系统上的许多底层都屏蔽，再由他提供了一些标准接口。

同时在 kubernetes 中的日志来源也比传统虚拟机多，比如可能有容器、kubernetes 自身的事件、日志等。

前言

前段时间我们从 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 年年度回顾，去年我也花了一些时间参与社区，所以其中一些内容感受挺明显的，以下就是对一些重点内容的提炼。