今天收到球友的问题，让推荐一些值得看的开源项目，觉得 netty 这些太复杂了不太好上手。确实如此，我们日常常用的 Spring、Netty 确实由于发展了多年，看起来比较头大。下面我来推荐一些我看过同时觉得不错的项目(几乎都是我参与过的），由易到难，其中也会包含 Java 和 Go 的项目，包含主流的中间件和云原生项目。Java 项目xxl-job难度：🌟🌟推荐指数：🌟🌟🌟xxl-job是一个很经典的调度框架，目前在 GitHub 上也有 27k star 的关注，因为功能不复杂所以最近也没有怎么更新了。大家日常都会使用这类调度框架，所以理解难度非常低，加上他的实现也比较简单，比如：使用 MySQL 的锁来简单粗暴的解决分布式锁的问题线程池的使用：因为每个任务的调度都需要尽可能的互相不影响，所以里面大量使用了线程池，同时对如何获取异步任务结果也有一些最佳实践。RPC 调用：里面内置了一个RPC框架，也是作者编写的，其中的实现原理也不复杂，建议看看源码，可以更好的理解我们在工作中用到 rpc 框架。cim难度：🌟🌟🌟推荐指数：🌟🌟🌟这里夹了一点私货，就是我自己开源的一个分布式即时通讯系统，其实现在来看上一个版本的代码写的挺烂的，不过好在最近发布了 v2.0.0，提升了不少代码质量。它具备 IM 即时通讯的基本功能，同时基于它可以实现：即时通讯消息推送IOT 消息平台通过 cim 你 ...继续阅读 (1)

前段时间给 StarRocks 的物化视图新增了一个特性，那也是我第一次接触 StarRocks，因为完全不熟悉这个数据库，所以很多东西都是从头开始了解概念。为了能顺利的新增这个特性（具体内容可以见后文），我需要把整个物化视图的流程串联一遍，于是便有了这篇文章。在开始之前简单了解下物化视图的基本概念：简单来说，视图和 MySQL 这类传统数据库的概念类似，也是用于解决大量消耗性能的 SQL 的，可以提前将这些数据查询好然后放在一张单独的表中，这样再查询的时候性能消耗就比较低了。刷新条件为了保证视图数据的实时性，还需要在数据发生变化的时候能够及时刷新视图里的数据，目前有这几个地方会触发视图刷新：手动刷新视图，使用REFRESH MATERIALIZED VIEW order_mv;语句将视图设置为 active 状态：ALTER MATERIALIZED VIEW order_mv ACTIVE;基表数据发生变化时触发刷新。truncate 基表时触发刷新：truncate table trunc_db.t1;drop partition 时触发：ALTER TABLEDROP PARTITION(S) p0, p1 [, ...];这里的 truncate table 和 drop partition 目前的版本还存在 bug：当基表和物化视图不在一个数据库时不会触发自动刷新，目 ...继续阅读 (2)

背景最近在排查starrocks线上的一个告警日志：每隔一段时间都会打印base-table也就是物化视图的基表被删除了，但其实表还在，也没人去删除；我们就怀疑是否真的表被删除了（可能是 bug）。与此同时还有物化视图 inactive 的日志，也怀疑如果视图是 inactive 之后会导致业务使用有问题。为了确认这个日志是否对使用影响，就得需要搞清楚它出现的原因；于是我就着手从日志打印的地方开始排查。问题排查从这个代码可以看出，是在查询表的信息的时候没有查到，从而导致日志打印 base-table 被 dropped 了。而我查询了几天的drop table的日志，依然没有找到可能是程序 bug 导致被删除的痕迹。好在 starrocks 的日志打印非常详细，包含了线程名称、类+方法名称，还有具体的代码函数，很容易就定位日志输出的地方。元数据只是为何会调用到这里还需要阅读源码从而找到原因，在开始之前需要先了解一下 starrocks 元数据的一些基本概念。其实在这篇文章：StarRocks 元数据管理及 FE 高可用机制中已经有全面的介绍，只是这篇文章有点早了，和现在最新的代码不太匹配。在 StarRocks 元数据中会保存 Database、Table 等信息。这些数据定期保存在fe/meta目录中。StarRocks 对元数据的每一次操作（增删改查数据库、表、物化视图）都会生 ...继续阅读 (2)

最近业余时间花了小三个月重构了cim，也将版本和升级到了v2.0.0，合并了十几个 PR 同时也新增了几位开发者。其中有两位也是咱们星球里的小伙伴🎉介绍上次发版还是在五年前了：因为确实已经很久没有更新了，在开始之前还是先介绍cim是什么。这里有一张简单的使用图片：同时以前也有录过相关的视频：通过cim这个名字和视频可以看出，它具备 IM 即时通讯的基本功能，同时基于它可以实现：即时通讯消息推送IOT 消息平台现在要在本地运行简单许多了，前提是有 docker 就可以了。12345678docker run --rm--name zookeeper -d -p 2181:2181 zookeeper:3.9.2docker run --rm--name redis -d -p 6379:6379 redis:7.4.0gitclonehttps://github.com/crossoverJie/cim.gitcdcimmvn clean package -DskipTests=truecdcim-server && cim-client && cim-forward-routemvn clean package spring-boot:repackage -DskipTests=true架构cim的架构图如下：主要分为三个部分：Client 基本交互功能消息收发消息查询延迟消息Ro ...继续阅读 (4)

前几天排查了一个业务接口执行高延迟的问题，也挺有参考意义的，分享一下排查过程。现象是业务反馈有一个接口业务逻辑其实很简单，但是调用一次耗时，如下图所示：排查应用运行状态首先第一步需要查看当时的应用运行状态，包含当时的日志、JVM 的各种监控等。因为我们接入了OpenTelemetry，所以trace和日志是可以关联起来的。点击链路系统旁边的日志按钮可以直接跳转。可以通过trace_id查询到相关日志：通过日志可以看出耗时大约在 4s 多一点，然后结合代码发现这两段日志分别是在进入一个核心业务方法之前和方法内打印的。而第一行日志是在一个自定义限流器中打印的，这个限流器是使用Guava的RateLimiter实现的。我的第一反应是不是这个限流器当时限流了，从而导致阻塞了；但查看了当时的 QPS 发现完全低于限流器的配置，所以基本可以排除它的嫌疑了。JVM 监控之后我们查询当时的 JVM 监控发现当时的 GC 频繁，而堆内存也正好发生了一次回收，初步判断是 GC 导致的本次问题。但为啥会导致频繁的 GC 呢，还需要继续排查。内存排查我们在应用诊断中集成了Pyroscope的持续剖析，可以实时查看内存的占用情况。通过内存分析发现有大量的 JSON 序列化占用了大量的内存，同时还发现 Pod 已经被重启好几次了：查看原因发现是 Pod OOM 导致的。因此非常有可能是 GC 导致的，恰好那 ...继续阅读 (8)

SDK 设计在之前提到了cim在做集成测试的时候遇到的问题，需要提供一个 SDK 来解决，于是我花了一些时间编写了 SDK，同时也将 cim-client 重构了。重构后的代码长这个样子：12345678910111213141516171819202122@BeanpublicClientbuildClient(@Qualifier("callBackThreadPool")ThreadPoolExecutor callbackThreadPool,Event event){OkHttpClientokHttpClient=newOkHttpClient.Builder().connectTimeout(3, TimeUnit.SECONDS).readTimeout(3, TimeUnit.SECONDS).writeTimeout(3, TimeUnit.SECONDS).retryOnConnectionFailure(true).build();returnClient.builder().auth(ClientConfigurationData.Auth.builder().userName(appConfiguration.getUserName()).userId(appConfiguration.getUserId()).build()).routeUr ...继续阅读 (17)

背景最近这段时间在处理一个StarRocks的关于物化视图优化的一个问题，在此之前其实我也没有接触过StarRocks这类主要处理数据分析的数据库，就更别提在这上面做优化了。在解决问题之前我先花了一两天时间熟悉了一下StarRocks的一些概念和使用方法，然后又花了一些时间搭建环境然后复现了该问题。之后便开始阅读源码，大概知道了相关代码的执行流程，但即便是反复阅读了多次代码也没有找到具体出现问题的地方。所以便考虑在本地 Debug 源码，最终调试半天之后知道了问题所以，也做了相关修改，给社区提交了 PR，目前还在推进过程中。环境搭建这里比较麻烦的是如何在本地 debug 代码。根据官方的架构图会发现StarRocks主要分为两个部分：FE：也就是常说的前端部分，主要负责元数据管理和构建执行计划。BE：后端存储部分，执行查询计划并存储数据。其中 FE 是 Java 写的，而存储的 BE 则是 C++ 写的，我这次需要修改的是 FE 前端的部分，所以本篇文章主要讨论的是 FE 相关的内容。好在社区已经有关于如何编译和构建源码的教程，这里我列举一些重点，FE 首先需要安装以下一些工具：ThriftProtobufPython3JDK8+12345brew install alberttwong/thrift/thrift@0.13$ thrift -versionThrift versi ...继续阅读 (9)

最近有时间又把以前开源的IM 消息系统捡起来继续开发了（确实这些年经常有朋友催更）。没错，确实是这些年，因为上次发版还是再 2019 年的八月份。这段时间比较重大的更新就是把元数据中心抽离出来了，以前是和 zookeeper 的代码强耦合在一起的，重构之后可以有多种实现了。今后甚至可以提供一个 jar 包就可以把后端服务全部启动起来用于体验，此时就可以使用一个简单的基于内存的注册中心。除此之外做的更多的就是新增了一个集成测试的模块，没有完善的集成测试功能在合并代码的时候都要小心翼翼，基本的功能需求都没法保证。加上这几年我也接触了不少优秀的开源项目（比如 Pulsar、OpenTelemetry、HertzBeat 等），他们都有完整的代码合并流程；首先第一点就得把测试流水线跑通过。这一点在 OpenTelemetry 社区更为严格：他们的构建测试流程非常多，包括单元测试、集成测试、代码风格、多版本兼容等。所以在结合了这些优秀项目的经验后我也为 cim 项目新增相关的模块cim-integration-test，同时也在 github 上配置了相关的 action，最终的效果如下：在“Build with Maven”阶段触发单元测试和集成测试，最终会把测试结果上传到 Codecov，然后会在 PR 的评论区输出测试报告。相关的 action 配置如下：就是配置了几个 Job，重点是 ...继续阅读 (15)

背景因为公司内部在使用PowerJob作为我们的分布式调度系统，同时又是使用 OpenTelemetry 作为可观测的底座，但目前 OpenTelemetry 还没有对 PowerJob 提供支持，目前社区只对同类型的 XXL-JOB 有支持。恰好公司内部也有一些开发同学有类似的需求：于是在这个背景下我便开始着手开发 PowerJob 的 instrumentation，最终的效果如下：从这个链路图中可以看到 grpc-consumer 提供了调度的入口函数，然后在内部发送了 Pulsar 消息，最终又调用了 grpc-provider 的gRPC接口。这样就可以把整个链路串起来，同时还能查看PowerJob调度的 JobId、以及调用参数等数据，这样排查问题时也更加直观。开发 Instrumentation 的前置知识在正式开发 Instrumentation 之前还需要了解一些前置知识点。这里我们以现有的gRPC和我编写的 PowerJob instrumentation 为例，可以看到gRPC的 instrumentation 中多了一个 library 的模块。这里就引申出了两种埋点方式：Library instrumentationJava agent instrumentation通常我们对一个框架或者一个库进行埋点时，首先需要找到它的埋点入口。以grpc为例，我们首先 ...继续阅读 (28)

23 年在 ChatGPT 刚出来的时候就在V 站上看到有一个看到有大佬用自己的微信聊天记录和博客文章生成了一个 AI 替身：当时就想着自己做一个，不过当时实现起来还比较复杂，直到如今 AI 已经越来越普及，想做一个自己的 AI 替身成本也非常低了。于是就有了下图里的效果：和自己的内容这么对话还挺有意思的，现在大家就可以直接在我公众号回复消息和”他“聊天。也可以通过小程序来使用：如何搭建这里使用的数据源全都是我发布在公众号里的 260 篇文章。能够直接获取到微信公众号的数据一定是腾讯自己的产品，其实这个产品叫做：腾讯元器，是腾讯大模型团队基于混元大模型推出的智能创作工具。我们可以自定义 prompt、数据源、插件来实现自己的 AI 机器人，或者类似的交互产品。直接创建一个智能体，然后编写对应的提示词即可，使用起来非常简单，官方也提供了一些prompt的示例：根据自己的需求来填写就可以了。最主要的还是创建一个知识库，也就是你的数据源，好在这里直接整合了公众号的数据；直接授权就可以使用，同时还可以每天定时更新，非常方便。它会根据你的问题来判断是否用知识库的内容来回答，所以即便是问一些知识库不存在的内容也能拿到结果。除此之外还可以上传你本地的文件，所以即便是你没有写公众号也可以上传自己整理的内容。有兴趣的朋友可以试试尝尝鲜，后续我可以持续完善这个知识库，比如输入一些代码，之后再有向我咨询 ...继续阅读 (11)

可观测性概念当一个软件或系统出于运行状态时，如果我们不对他加以观测，那它的运行状态对我们来说就是一个黑盒。如上图所示。我们只能通过业务的表象来判断它是否正常运行，无法在故障发生前进行预判，从而只能被动解决问题。这类问题在微服务时代体现的更加明显，即便是业务已经出现问题，在没有可观测性系统的前提下想要定位问题更是难上加难。好在可观测性这个概念由来已久，已经由一些业界大佬抽象出几个基本概念：Logs：离散的日志信息Metrics：聚合的指标Trace：请求基本的链路追踪结合这三个指标，我们排查问题的流程一般如下：首先根据 metrics 来判断是否有异常，这点可以通过在 Prometheus 的 AlertManager 配置一些核心的告警指标。比如当 CPU、内存使用率超过 80% 或者某个应用 Down 机后就发出告警。1234567891011121314groups:-name:AllInstancesrules:-alert:InstanceDown# Condition for alertingexpr:up==0for:1m# Annotation - additional informational labels to store more informationannotations:title:'Instance{{ $labels.i ...继续阅读 (12)

前言在前面两篇实战文章中：OpenTelemetry 实战：从零实现分布式链路追踪OpenTelemetry 实战：从零实现应用指标监控覆盖了可观测中的指标追踪和metrics监控，下面理应开始第三部分：日志。但在开始日志之前还是要先将链路追踪和日志结合起来看看应用实际使用的实践。通常我们排查问题的方式是先查询异常日志，判断是否是当前系统的问题。如果不是，则在日志中捞出trace_id再到链路查询系统中查询链路，看看具体是哪个系统的问题，然后再做具体的排查。类似于这样：日志中会打印trace_id和span_id。如果日志系统做的比较完善的话，还可以直接点击trace_id跳转到链路系统里直接查询链路信息。MDC这里的日志里关联 trace 信息的做法有个专有名词：MDC:(Mapped Diagnostic Context)。简单来说就是用于排查问题的上下文信息，通常是由键值对组成，类似于这样的数据：12345678910111213{"timestamp":"2024-08-05 17:27:31.097","level":"INFO","thread":"http-nio-9191-exec-1","mdc":{"trace_id":"26242f945af80b044a60226af00211fb","trace_flags":"01","span_id ...继续阅读 (11)

前言最近在给opentelemetry-java-instrumentation提交了一个PR，是关于给 gRPC 新增四个 metrics：rpc.client.request.size: 客户端请求包大小rpc.client.response.size：客户端收到的响应包大小rpc.server.request.size：服务端收到的请求包大小rpc.server.response.size：服务端响应的请求包大小这个 PR 的主要目的就是能够在指标监控中拿到RPC请求的包大小，而这里的关键就是如何才能拿到这些包的大小。首先支持的是gRPC（目前在云原生领域使用的最多），其余的 RPC 理论上也是可以支持的：在实现的过程中我也比较好奇OpenTelemetry框架是如何给gRPC请求创建span调用链的，如下图所示：这是一个 gRPC 远程调用，java-demo 是 gRPC 的客户端，k8s-combat 是 gRPC 的服务端在开始之前我们可以根据OpenTelemetry的运行原理大概猜测下它的实现过程。首先我们应用可以创建这些链路信息的前提是：使用了OpenTelemetry提供的javaagent，这个 agent 的原理是在运行时使用了byte-buddy增强了我们应用的字节码，在这些字节码中代理业务逻辑，从而可以在不影响业务的前提下增强我们的代码（只要就是创建 ...继续阅读 (23)

前言在上一篇文章：OpenTelemetry 实战：从零实现分布式链路追踪讲解了链路相关的实战，本次我们继续跟进如何使用 OpenTelemetry 集成 metrics 监控。建议对指标监控不太熟的朋友可以先查看这篇前菜文章：从 Prometheus 到 OpenTelemetry：指标监控的演进与实践名称作用语言版本java-demo发送 gRPC 请求的客户端Javaopentelemetry-agent: 2.4.0/SpringBoot: 2.7.14k8s-combat提供 gRPC 服务的服务端Golanggo.opentelemetry.io/otel: 1.28/ Go: 1.22Jaegertrace 存储的服务端以及 TraceUI 展示Golangjaegertracing/all-in-one:1.56opentelemetry-collector-contribOpenTelemetry 的 collector 服务端，用于收集 trace/metrics/logs 然后写入到远端存储Golangotel/opentelemetry-collector-contrib:0.98.0Prometheus作为 metrics 的存储和展示组件，也可以用VictoriaMetrics等兼容 ...继续阅读 (22)

背景之前写过一篇从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅的文章，主要是从概念上讲解了 Trace 在 OpenTelemetry 的中的场景和使用。也写过一篇实操 OpenTelemetry：通过 Demo 掌握微服务监控的艺术：如何从一个 demo 开始集成 OpenTelemetry。但还是有不少小伙伴反馈说无法快速上手（可能也是这个 demo 的项目比较多），于是我准备从 0 开始从真实的代码一步步带大家集成OpenTelemetry，因为 OpenTelemetry 本身是跨多种语言的，所以也会以两种语言为（Java、Golang）主进行讲解。使用这两种语言主要是因为 Java 几乎全是自动埋点，而 Golang 因为语言特性，大部分都得硬编码埋点；覆盖到这两种场景后其他语言也是类似的，顶多只是 API 名称有些许区别。在这个过程中也会穿插一些 OpenTelemetry 的原理，希望整个过程下来大家可以在项目中实际运用起来，同时也能知其所以然。项目结构在这个过程中会涉及到以下项目：名称作用语言版本java-demo发送 gRPC 请求的客户端Javaopentelemetry-agent: 2.4.0/SpringBoot: 2.7.14k8s-combat提供 gRPC 服务的服务端Golanggo.opentelemetry.i ...继续阅读 (34)

之前分享过如何快速上手开源项目以及如何在开源项目里做集成测试，但还没有讲过具体的实操。今天来详细讲讲如何写单元测试。🤔什么情况下需要单元测试这个大家应该是有共识的，对于一些功能单一、核心逻辑、同时变化不频繁的公开函数才有必要做单元测试。对于业务复杂、链路繁琐但也是核心流程的功能通常建议做 e2e 测试，这样可以保证最终测试结果的一致性。💀具体案例我们都知道单测的主要目的是模拟执行你写过的每一行代码，目的就是要覆盖到主要分支，做到自己的每一行代码都心中有数。下面以Apache HertzBeat的一些单测为例，讲解如何编写一个单元测试。先以一个最简单的org.apache.hertzbeat.collector.collect.udp.UdpCollectImpl#preCheck函数测试为例。这里的preCheck函数就是简单的检测做参数校验。测试时只要我们手动将metrics设置为null就可以进入这个 if 条件。123456789101112131415@ExtendWith(MockitoExtension.class)classUdpCollectImplTest{@InjectMocksprivateUdpCollectImpl udpCollect;@TestvoidtestPreCheck(){ListaliasField =newArrayLi ...继续阅读 (33)

背景由于我在公司内部负责维护Pulsar，需要时不时的升级Pulsar版本从而和社区保持一致。而每次升级过程都需要做相同的步骤：安装一个新版本的集群触发功能性测试触发性能测试查看监控是否正常应用有无异常日志流量是否正常各个组件的内存占用是否正常写入延迟是否正常命令行工具以上的流程步骤最好是全部一键完成，我们只需要人工检测下监控是否正常即可。于是我便写了一个命令行工具，执行流程如下：12345678910111213141516171819pulsar-upgrade-cli -h ok | at 10:33:18A cli app for upgrading PulsarUsage:pulsar-upgrade-cli [command]Available Commands:completion Generate the autocompletion script for the specified shellhelp Help about any commandinstall install a target versionscale scale sta ...继续阅读 (39)

前段时间在pulsar-client-go社区里看到这么一个issue：1234567891011121314151617181920212223242526import"github.com/apache/pulsar-client-go/pulsar"client, err := pulsar.NewClient(pulsar.ClientOptions{URL:"pulsar://localhost:6650",})iferr !=nil{log.Fatal(err)}consumer, err := client.Subscribe(pulsar.ConsumerOptions{Topic:"persistent://public/default/mq-topic-1",SubscriptionName:"sub-1",Type: pulsar.Shared,ReceiverQueueSize:0,})iferr !=nil{log.Fatal(err)}// 小于等于 0 时会设置为 1000const(defaultReceiverQueueSize =1000)ifoptions.ReceiverQueueSize <=0{options.Receive ...继续阅读 (35)

前段时间接到一个需求，希望可以监控 Nginx 的运行状态。我们都知道 Nginx 作为一个流行的 Web 服务器提供了多种能力，包括反向代理、负载均衡；也支持了许多协议，包括：gRPChttpWebSocket 等作为一个流量入口的中间件，对其的监控就显得至关重要了。市面上也有一些现成的产品可以监控 Nginx，比如知名的监控服务商datadog也提供了 Nginx 的监控。但是我这是一个内网服务，并不能使用这些外部的云厂商，所有就只能在内部搭建 Nginx 的监控服务了。不过 Nginx 默认情况下并没有提供/metrics的 endpoint，但好在它提供了一个额外的模块：stub_status可以用于获取监控数据。12345678910111213server{listen80;server_name_;location/status{stub_statuson;access_logoff;}location/{root/usr/share/nginx/html;indexindex.htmlindex.htm;}}这样访问http://127.0.0.1:80/status就可以拿到一些基本的运行数据。但这个格式明显不是 Prometheus 所支持的 metrics 格式，无法直接将数据采集到 Promethe ...继续阅读 (36)

背景Pulsar 有提供一个查询 Broker 负载的接口：1234567891011121314151617181920/*** Get load for this broker.**@return*@throwsPulsarAdminException*/LoadManagerReportgetLoadReport()throwsPulsarAdminException;publicinterfaceLoadManagerReportextendsServiceLookupData{ResourceUsagegetCpu();ResourceUsagegetMemory();ResourceUsagegetDirectMemory();ResourceUsagegetBandwidthIn();ResourceUsagegetBandwidthOut();}可以返回一些 broker 的负载数据，比如 CPU、内存、流量之类的数据。我目前碰到的问题是目前会遇到部分节点的负债不平衡，导致资源占用不均衡，所以想要手动查询所有节点的负载数据，然后人工进行负载。理论上这些数据是在运行时实时计算的数据，如果对于单机的倒还好说，每次请求这个接口直接实时计算一次就可以了。但对于集群的服务来说会有多个节点，目前 Pulsar 提供的这个接口只能查询指定节点的负载数据，也就是 ...继续阅读 (43)

最近收到了Apache Pulsar和Apache HertzBeat社区的邀请邮件，成为了这两个项目的Committer。一路走来我从最开始的打游击战的闲散人员到如今活跃在各个开源项目里的“老兵”，用现在流行的话来说Apache的这两个Committer就相当于是拿到了编制，进入了正规军。下面就分享一下我的个人开源经历，希望对想要参与开源或者已经在其中的开发者有所帮助。我的 GitHub 开源故事初识 GitHub我这个Github账号是在 15 年 9月份注册的，那时候刚出来参与工作。其实在这之前我压根没有听说过 GitHub、对开源也是知之甚少；只是知道老师和同事经常让我在网上可以下载到一些第三方包（现在回想起来几乎都是好 Apache 的提供的包）来解决日常的一些常见需求。当时只是觉得非常方便，没想到大部分的工作互联网上都有相关的解决方案。直到第二年也就是 16 年我才提交第一行代码，记得当时是需要和同学共享一些代码。在学校的时候大家都是把文件打包然后通过 QQ 发送的，因为我之前在 GitHub 上看到大家都是把源码公开的，所以当时的想法是不是可以直接使用 GitHub 把代码发给同学，这样就省去了打包解压的步骤了。现在想想还好都是一些非业务代码，不然就违反公司安全规定了。所以其实自己没有任何开源的概念，只是觉得分享代码很方便。后续在网上看了Richard Matthew ...继续阅读 (32)

之前有朋友问如何做集成测试，今天就重点讲讲这个集成测试在开源项目中是如何做的。通常是需要对外提供服务的开源项目都需要集成测试：PulsarKafkaDubbo 等而只提供本地类库的项目通常只需要编写单元测试即可：HutoolApache Commmon以我接触到的服务型应用主要分为两类：一个是 Java 应用一个是 Golang 应用。🐳GolangGolang 因为工具链没有 Java 那么强大，所以大部分的集成测试的功能都是通过编写 Makefile 和 shell 脚本实现的。还是以我熟悉的 Pulsar 的 go-client 为例，它在 GitHub 的集成测试是通过 GitHub action 触发的，定义如下：最终调用的是 Makefile 中的 test 命令，并且把需要测试的 Golang 版本传入进去。Dockerfile：这个镜像简单来说就是将 Pulsar 的镜像作为基础运行镜像（这里面包含了 Pulsar 的服务端），然后将这个 pulsar-client-go 的代码复制进去编译。接着运行：1cd /pulsar/pulsar-client-go && ./scripts/run-ci.sh也就是测试脚本。测试脚本的逻辑也很简单：启动 pulsar 服务端运行测试代码因为所有的测试代码里连接服务端的地址都是localhost，所以可以直接连接。通过这里的 ...继续阅读 (42)

🧰Helm 的作用在开始前需要先对 kubernetes Operator 有个简单的认识。以为我们在编写部署一些简单Deployment的时候只需要自己编写一个 yaml 文件然后kubectl apply即可。123456789101112131415161718192021222324252627apiVersion:apps/v1kind:Deploymentmetadata:labels:app:k8s-combatname:k8s-combatspec:replicas:1selector:matchLabels:app:k8s-combattemplate:metadata:labels:app:k8s-combatspec:containers:-name:k8s-combatimage:crossoverjie/k8s-combat:v1imagePullPolicy:Alwaysresources:limits:cpu:"1"memory:300Mirequests:cpu:"0.1"memory:30Mi1kubectl apply -f deployment.yaml这对于一些并不复杂的项目来说完全够用了，但组件一多就比较麻烦了。这里以 Apache Pulsar 为例：它的核心组件有:BrokerProxyZookeeperBookkeeperProme ...继续阅读 (41)

原文链接：https://medium.com/@andreiboar/5-small-tips-i-recently-learned-in-go-cf52d50cf129让编译器计算数组数量我们在 Go 通常很少使用数组 arrays，一般使用切片 Slice 来代替；但是当你需要使用的时候，如果你对需要指定数量大小感到很烦时可以使用[...]让编译器自动帮我们计算数组大小：123456789101112packagemainimport"fmt"funcmain(){arr := [3]int{1,2,3}sameArr := [...]int{1,2,3}// Use ... instead of 3// Arrays are equivalentfmt.Println(arr)fmt.Println(sameArr)}使用 go run . 替换 go run main.go每当我用 Go 写第一行代码时，我都习惯于开始写main.go:1234567891011packagemainimport"fmt"funcmain(){sayHello()}funcsayHello(){fmt.Println("Hello!")}但是当main ...继续阅读 (40)

以前有写过两篇文章来简单聊过如何做开源的事情，最近我自己组了一个社区里面也有不少朋友对开源感兴趣，于是我便根据自己的经验系统的梳理了一些关于开源的事情。新手如何快速参与开源项目手把手教你为开源项目贡献代码有兴趣的可以先看看之前这两篇。🔎如何找到自己感兴趣的开源项目首先第一步先想清楚自己搞开源的目的是什么：参考社区大佬的代码，提升技术丰富个人履历，提高面试通过率更功利一点就是想成为某个项目的Committer/PMC单纯喜欢分享，热爱开源，认可开源改变世界💪。我人为前面三种都是一个目的，提升自己获得后续的好处；最后一种则是妥妥的纯热爱。以我个人来说，我两者都沾一点；我相信大部分人都是前面三类的目的，到这里我可能要先浇点冷水。往往一个开源项目从你熟悉它开始到提第一个 PR 然后到合并中间经历的时间可能是大大超出你的预期的。特别是越大型越专业的项目（我相信你也是想加入这类有一定知名度的项目）。因为开源社区大部分都是执行异步沟通，与即时通讯的快速反馈不同，甚至还有不少 reviewer 处于不同的时区。所以一开始就想做好心理预期，不要指望着我给某个项目提交一个很牛逼的功能，然后他们快速 review 合并，然后给你 commit 权限。而且有不少开源项目是由某一个公司主导的，比如（Pulsar、Golang、Kafka），他们可能对于外部社区来的新手并不那么上心，一个 PR 晾在 ...继续阅读 (42)

背景在上一篇《从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅》中在最后提到在做一些 Trace 的定制开发。到现在差不多算是完成了，可以和大家分享一下。我们的需求是这样的：假设现在有三个服务：ServiceA、ServiceB、ServiceCServiceA对外提供了一个 http 接口request，在这个接口会调用ServiceB的order订单接口创建订单，同时serviceB调用serviceC的 pay 接口。整个调用关系如上图所示。默认情况下 span 中的 attribute 会记录当前 span 的一些信息，比如：这些都是当前一些当前 span 内置的信息，比如当前 gRPC 接口的一些基本数据：服务名、ip、端口等信息。但这里并没有上游的一些信息，虽然我们可以通过 Jaeger 的树状图得知上游是哪个应用调用过来的，但是一旦某个 span 下有多个子 span 的调用，就没办法很直观知道这个子 span 的上游是由谁发起的调用。比如如下这个链路：当一个调用链非常长，同时也非常复杂时，没办法第一时间知道某一个 span 的上游到底是谁发起的，需要手动一层层的去折叠，或者全靠眼睛去找。预期效果为此我们希望的效果是可以通过给每一个子 span 中加入两个 attribute，来标明它的父调用来源。比如在 serviceB 中的所有 span 中 ...继续阅读 (45)

在上一篇：从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅我们讲解了 Trace 的一些核心概念：TraceSpanContextBaggage 等这次我们来讲另一个话题Metrics。背景关于 metrics 我最早接触相关概念的就是 prometheus，它是第二个加入 CNCF（云原生）社区的项目（第一个是 kubernetes），可见在云原生领域 Metrics 指标监控从诞生之初就是一个非常重要的组件。现实也确实如此，如今只要使用到了 kubernetes 相关的项目，对其监控就是必不可少的。当然也不止是云原生的项目才需要 Metrics 指标监控，我们任何一个业务都是需要的，不然我们的服务运行对开发运维来说都是一个黑盒，无法知道此时系统的运行情况，因此才需要我们的业务系统将一些关键运行指标暴露出来。业务数据：比如订单的增长率、销售金额等业务数据；同时还有应用自身的资源占用情况：QPSLatency内存CPU 等信息。在使用 OpenTelemetry 之前，因为 prometheus 是这部分的绝对标准，所以我们通常都会使用 prometheus 的包来暴露这些指标：123456789101112The clientio.prometheussimpleclient0.16.0Hotspot JVM metricsio.prometheussimp ...继续阅读 (46)

在之前写过两篇比较系统的关于 OpenTelemetry 的文章：OpenTelemetry 实践指南：历史、架构与基本概念实操 OpenTelemetry：通过 Demo 掌握微服务监控的艺术从基本概念到如何部署 demo 实战了解 OpenTelemetry，从那个 demo 中也可以得知整个 OpenTelemetry 体系的复杂性，包含了太多的组件和概念。为了能更清晰的了解每个关键组件的作用以及原理，我打算分为几期来讲解 OpenTelemetry 的三个核心组件：TraceMetricsLogs首先以 Trace 讲起。Trace开始之前还是先复习一下 Trace 的历史背景。如今现代的分布式追踪的起源源自于 Google 在 2010 年发布的一篇论文：Dapper, a Large-Scale Distributed Systems Tracing Infrastructure在这篇论文中提出了分布式追踪的几个核心概念：TraceSpanSpan 的一些基础数据结构可视化追踪以及展示之后 Twitter 受到了 Dapper 的启发开源了现在我们熟知的Zipkin，包含了存储和可视化 UI 展示我们的追踪链路。Uber 也在 2015 年开源了Jaeger项目，它的功能和 Zipkin 类似，但目前我们用的较多的还是 Jaeger；现在已经成为 CNCF 的托管项目。 ...继续阅读 (60)

原文链接:https://overcast.blog/13-kubernetes-tricks-you-didnt-know-647de6364472使用 PreStop 优雅关闭 Pod123456789101112apiVersion:v1kind:Podmetadata:name:graceful-shutdown-examplespec:containers:-name:sample-containerimage:nginxlifecycle:preStop:exec:command:["/bin/sh","-c","sleep 30 && nginx -s quit"]PreStop 允许 Pod 在终止前执行一个命令或者是脚本，使用它就可以在应用退出前释放一些资源，确保应用可以优雅退出。比如可以在 Nginx 的 Pod 退出前将当前的请求执行完毕。使用临时容器调试 Pod临时容器可以不修改一个运行的容器的前提下调试容器，可以很方便的调试一些生产环境的 bug，可以避免重启应用。1kubectl alpha debug -it podname --image=busybox --target=containername生产环境谨慎使用，只有在当前环境下无法排查问题的时候才使用。基于自定义的 Metrics 自动扩容Podkubernetes 是提供了 HPA 机制可以 ...继续阅读 (46)

前言在上一篇文章OpenTelemetry 实践指南：历史、架构与基本概念中回顾了可观测性的历史以及介绍了一些 OpenTelemetry 的基础概念，同时也介绍了 OpenTelemetry 社区常用的开源项目。基础背景知识了解后，这篇就来介绍一下使用 OpenTelemetry 如何实战部署应用，同时在一个可视化页面查看 trace、metric 等信息。项目介绍我们参考官方文档构建几个 spring boot 、Golang 项目再配合 Agent 其实也可以很方便的集成 OpenTelemetry。但是要完整的体验 OpenTelemetry 的所有功能，包含 trace、logs、metrics，还有社区这么多语言的支持其实还是比较麻烦的。我们还需要单独部署 collector、存储的 backend service 等组件、包括 trace UI 展示所需要的 Jaeger，metric 所需要的 grafana 等。这些所有东西都自己从头弄的话还是比较费时，不过好在社区已经将这些步骤都考虑到了。特地为大家写了一个opentelemetry-demo。这个项目模拟了一个微服务版本的电子商城，主要包含了以下一些项目：ServiceLanguageDescriptionaccountingserviceGo处理和计算订单数据adserviceJava广告服务cartserv ...继续阅读 (48)