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

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

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

背景最近公司将我们之前使用的链路工具切换为了 OpenTelemetry.我们的技术栈是： {代码...} 其中客户端使用 OpenTelemetry 提供的 Java Agent 进行埋点收集数据，再由 Agent 通过 OTLP(OpenTelemetry Protocol) 协议将数据发往 Collector，在 Collector 中我们可以自行任意处理数据，并决定将这些数据如何存储（这点在以...

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

最近我们的 Pulsar 存储有很长一段时间数据一直得不到回收，但消息确实已经是 ACK 了，理论上应该是会被回收的，随着时间流逝不但没回收还一直再涨，最后在没找到原因的情况下就只有一直不停的扩容。

在上一篇 Pulsar3.0新功能介绍中提到，在升级到 3.0 的过程中碰到一个致命的问题，就是升级之后 topic 被删除了。正好最近社区也补充了相关细节，本次也接着这个机会再次复盘一下，毕竟这是一个非常致命的 Bug。现象先来回顾下当时的情况：升级当晚没有出现啥问题，各个流量指标、生产者、消费者数量都是在正常范围内波...

在上一篇文章 Pulsar3.0 升级指北讲了关于升级 Pulsar 集群的关键步骤与灾难恢复，本次主要分享一些 Pulsar3.0 的新功能与可能带来的一些问题。升级后所遇到的问题先来个欲扬先抑，聊聊升级后所碰到的问题吧。其中有两个问题我们感知比较明显，特别是第一个。topic被删除我们在上个月某天凌晨从 2.11.2 升级到 3.0.1 之...

如图所示，LTS 版本会最长支持到 36 个月，而 Feature 版本最多只有六个月；类似于我们使用的 JDK11,17,21 都是可以长期使用的；所以也推荐大家都升级到 LTS 版本。

背景前段时间在使用 Pulsar 的 admin API 时，发现其中的一个接口响应非常慢： {代码...} 使用 curl 拿到的响应结果非常大，同时也非常耗时：具体的 issue 在这里：[链接]后面经过分析，是因为某些 topic 的生产者和消费者非常多，导致这个查询 topic 统计的接口数据量非常大。但在我这个场景其实是不需要这些生产者和消...

而其中的关键的埋点信息是通过 Pulsar 的 BrokerInterceptor 实现的，后面就有朋友咨询这块代码是否开源，目前是没有开源的，不过借此机会可以聊聊如何实现一个 BrokerInterceptor 插件，当前还没有相关的介绍文档。

今天进入 kubernetes 的运维部分（并不是运维 kubernetes，而是运维应用），其实日常我们大部分使用 kubernetes 的功能就是以往运维的工作，现在云原生将运维和研发关系变得更紧密了。

最近在测试将 Pulsar 2.11.2 升级到 3.0.1的过程中碰到一个鉴权问题，正好借着这个问题充分了解下 Pulsar 的鉴权机制是如何运转的。

这里有一张功能对比图，可以明显的看出 Istio-gateway 支持的功能会更多，如果是一个中大型企业并且已经用上 Istio 后还是更推荐是有 Istio-gateway，使用同一个控制面就可以管理内外网流量。

今天我们更进一步，深入了解使用 Istio 的功能。从 Istio 的流量模型中可以看出：Istio 支持管理集群的出入口请求（gateway），同时也支持管理集群内的 mesh 流量，也就是集群内服务之间的请求。

背景终于进入大家都比较感兴趣的服务网格系列了，在前面已经讲解了：如何部署应用到 kubernetes服务之间如何调用如何通过域名访问我们的服务如何使用 kubernetes 自带的配置 ConfigMap基本上已经够我们开发一般规模的 web 应用了；但在企业中往往有着复杂的应用调用关系，应用与应用之间的请求也需要进行管理。比如常见...

最近在升级服务网格 Istio，升级后有个必要的流程就是需要重启数据面的所有的 Pod，也就是业务的 Pod，这样才能将这些 Pod 的 sidecar 更新为新版本。

前段时间写过一篇 gRPC 的入门文章，在最后还留了一个坑没有填：也就是 gRPC 的负载均衡问题，因为当时的业务请求量不算大，再加上公司没有对 Istio 这类服务网格比较熟悉的大牛，所以我们也就一直拖着没有解决，依然只是使用了 kubernetes 的 service 进行负载，好在也没有出什么问题。

Helm 是一个 Kubernetes 的包管理工具，有点类似于 Mac 上的 brew，Python 中的 PIP；可以很方便的帮我们直接在 kubernetes 中安装某个应用。

现在我们需要更进一步，使用 k8s 提供的一些其他对象来标准化我的应用开发。首先就是 ConfigMap，从它的名字也可以看出这是用于管理配置的对象。

看这个标题的就是修复了 Go 循环的 bug，这真的是史诗级的更新；我身边接触到的大部分 Go 开发者都犯过这样的错误，包括我自己，所以前两年我也写过类似的博客：简单的 for 循环也会踩的坑

背景前段时间给 VictoriaLogs 提交了一个 PR：[链接]本来一切都很顺利，只等合并了，但在临门一脚的时候社区维护人员问我可否给 git commit 加上签名。于是我就默默的调试到了凌晨四点😭以前我也没怎么注意过这个选项，经过 Google 后发现 Idea 在提交的时候可以自行设置。当我勾选了这个提交新的代码后，依然被告知没有...

通过这个描述其实也能看出 Ingress 是偏运维的工作，但也不妨碍我们作为研发去了解这部分的内容；了解整个系统是如何运转的也是研发应该掌握的技能。

这几年随着云原生的兴起，大部分后端开发者，特别是 Java 开发者都或多或少的想学习一些 Go 相关的技能，所以今天分享的内容比较初级，适合 Go 语言初学者。

在做传统业务开发的时候，当我们的服务提供方有多个实例时，往往我们需要将对方的服务列表保存在本地，然后采用一定的算法进行调用；当服务提供方的列表变化时还得及时通知调用方。

背景最近这这段时间更新了一些 k8s 相关的博客和视频，也收到了一些反馈；大概分为这几类：公司已经经历过服务化改造了，但还未接触过云原生。公司部分应用进行了云原生改造，但大部分工作是由基础架构和运维部门推动的，自己只是作为开发并不了解其中的细节，甚至 k8s 也接触不到。还处于比较传统的以虚拟机部署的传统...

为了让业务团队可以更好的跟踪自己消息的生产和消费状态，需要一个类似于表格视图的消息列表，用户可以直观的看到发送的消息；同时点击详情后也能查到消息的整个轨迹。

背景前段时间我们想实现 Pulsar 消息的追踪流程，追踪实现的效果图如下：实现其实比较简单，其中最重要的就是如何存储消息。消息的读取我们是通过 Pulsar 自带的 BrokerInterceptor 实现的，对这个感兴趣的朋友后面会单独做一个分享。根据这里的显示内容我们大概需要存储这些信息：客户端地址消息发布时间分发消费者、订...

前段时间在这个视频中分享了 [链接] 这个知识仓库。[链接]这次继续分享里面的内容，本次主要以 k8s 相关的问题为主。k8s 是什么，为什么企业选择使用它k8s 是一个开源应用，给用户提供了管理、部署、扩展容器的能力，以下几个例子更容易理解：你可以将容器运行在不同的机器或节点中，并且可以将一些变化同步给这些容器，...

近期由于工作的原因，我需要经常和 Apache Pulsar 社区沟通，同时也会将日常碰到的问题反馈给社区，包括一些 bug ，一些我能修的也是顺带就提了一些 PR。