背景最近接手维护了公司的指标监控系统，之后踩到坑就没站起来过。。

背景最近真是和 Pulsar 杠上了，业务团队反馈说是线上有个应用消息重复消费。 而且在测试环境是可以稳定复现的，根据经验来看一般能稳定复现的都比较好解决。

背景今天收到业务团队反馈线上有个应用往 Pulsar 中发送消息失败了，经过日志查看得知是发送消息时候抛出了 java.lang.InterruptedException 异常。 和业务沟通后得知是在一个 gRPC 接口中触发的消息发送，大约持续了半个小时的异常后便恢复正常了，这是整个问题的背景。

背景前段时间我们将 istio 版本升级到 1.12 后导致现有的应用监控有部分数据丢失（页面上显示不出来）。 一个是应用基础信息丢失。 再一个是应用 JVM 数据丢失。 接口维度的监控数据丢失。

前言前段时间我们在升级 Pulsar 版本的时候发现升级后最后一个节点始终没有流量。 虽然对业务使用没有任何影响，但负载不均会导致资源的浪费。 和同事沟通后得知之前的升级也会出现这样的情况，最终还是人工调用 Pulsar 的 admin API 完成的负载均衡。 这个问题我尝试在 Google 和 Pulsar 社区都没有找到类似的，不知道是大家都没碰到还是很少升级集群。 我之前所在的公司

一转眼 2022 年又过去了，不多不少距离上次写年终总结过去了 365 天；今年的艰难情况想必大家都亲身经历过了；如果要举行卖惨大会的话今年也许我能排的上号。

前言这段时间在做 MQ（Pulsar）相关的治理工作，其中一个部分内容关于消息队列的升级，比如： 一键创建一个测试集群。 运行一批测试用例，覆盖我们线上使用到的功能，并输出测试报告。 模拟压测，输出测试结果。 本质目的就是想直到新版本升级过程中和升级后对现有业务是否存在影响。

前言最近不出意外的阳了，加上刚入职新公司不久，所以也没怎么更新；这两天好些后分享一篇前段时间的一个案例： 最近在设计一个对某个中间件的测试方案，这个测试方案需要包含不同的测试逻辑，但相同的是需要对各个环节进行记录；比如统计耗时、调用通知 API 等相同的逻辑。 如果每个测试都单独写这些逻辑那无疑是做了许多重复工作了。

前言闭包对于一个长期写 Java 的开发者来说估计鲜有耳闻，我在写 Python 和 Go 之前也是没怎么了解，光这名字感觉就有点”神秘莫测”，这篇文章的主要目的就是从编译器的角度来分析闭包，彻底搞懂闭包的实现原理。

版本更新最近 GScript 更新了 v0.0.11 版本，重点更新了： Docker 运行环境 新增了 byte 原始类型 新增了一些字符串标准库 Strings/StringBuilder 数组切片语法：int[] b = a[1: len(a)]; 具体更新内容请看下文。 前言前段时间发布了 GScript 的在线 playground，