赖小明

前言

在 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**注解即可，那它内部是如何实现的呢，我们一起来看下。

我们都知道，在Dubbo微服务项目开发中，只需要通过**@EnableDubbo和@DubboService**注解就可以把服务注册到注册中心，那整个过程是怎么发生的呢？

SPI全称是Service Provider Interface，是一种服务自发现机制，本质是将接口实现类的全限定名配置在文件中，在使用中，通过运行时加载，并动态地替换为具体的接口实现类。