赖小明

前言

在使用 Dubbo 进行服务间的调用时，如果 Provider 服务端抛出了特定异常，但在 Consumer 调用端可能拿到的并不是我们预期的异常类型，那Dubbo 对于服务端的异常是如何处理的呢？如果我们希望在调用端也能获取到对应的异常信息，可以怎么做呢？本文一起来看下。

问题的出现和定位

测试环境中，有测试同学反馈说接口请求慢，超时了也没有数据返回。

首先从测试同学那里了解到具体慢的接口，排查了对应的服务的状态，确定了服务的状态是正常在线的。

进入该服务对应的容器内，用 jstat -gctil 命令查看了服务进程的 GC 情况，发现不管是内存占用，或是 GC 的频率和时间占比，都不高。

然后又通过 top 看了下 CPU 的使用率，发现服务的进程整体使用率到了 90% 以上，随即通过 top -Hp 1 指定进程，定位到了占用的的具体线程id是 196：

前言

在 Kafka 中，有许多地方都需要用到延时操作，如延时生产、延时拉取等。Kafka 作为一个高性能的消息队列，并没有使用 JDK 中自带的 DelayQueue 来实现延时的功能，而是基于时间轮的概念实现了一个更高效的数据结构。

前言

在微服务架构中，为了避免单点故障，一个服务通常会部署多个实例，而对于服务消费者而言，则需要考虑如何选择一个可用的实例，以及调用失败的情况如何处理。在 Dubbo 中，针对这些问题，Dubbo 也提供了多种集群容错策略。

在 Spring Boot/Cloud 中，配置是应用环境的一部分，而环境有一个专属的类 —— “Environment”。

Environment 是 Spring 对环境的抽象，它封装了应用运行时的所有配置属性，这些属性可以来自不同的来源，如本地配置文件、系统属性、环境变量、命令行参数、配置中心等，而 Environment 则提供了一个统一的接口来访问这些属性。

那这些不同来源的配置文件是如何加载并生效的呢？本文一起来看看。

在 Spring Cloud 微服务开发中，我们都知道，要想在不重启应用的前提下，修改的配置能动态刷新并且生效，我们只需要在对应的类上加上 @RefreshScope 注解即可。

但最近一次项目开发过程中，我们却遇到了一个动态刷新不生效的问题

在之前的文章中，我们了解到了 Dubbo 服务导出和服务引用的过程。本篇文章一起来看下服务远程调用的过程。

在前一篇 Dubbo源码学习：服务引用 中我们了解到，在Dubbo服务消费端，Invoker对象具有远程调用的功能，但服务消费端是如何感知服务端的地址呢？在实际使用时，同一个服务提供者往往具有多个实例，在服务提供者实例上下线或实例数量发生变更时，服务消费端会如何做出相应的更新？

在深入了解之前，我们需要先了解下服务目录的概念。

问题描述

某日告警群突发OOM日志告警：

1

java.lang.OutOfMemoryError: unable to create new native thread

开发、运维、运营相关人员立马被召集了起来，首先确认了业务未受到明显的影响。

在上一篇中我们学习了Dubbo服务导出的过程，在开发中，如果我们需要引用一个服务的话，只需要在成员或方法上标注**@DubboReference**注解即可，那它内部是如何实现的呢，我们一起来看下。