赖小明

在 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，是一种服务自发现机制，本质是将接口实现类的全限定名配置在文件中，在使用中，通过运行时加载，并动态地替换为具体的接口实现类。

原文：The Log: What every software engineer should know about real-time data’s unifying abstraction

作者：Jay Kreps

我大约在六年前加入了领英，那是一个特别有趣的时间点。那时我们正面临着单体集中式数据库极限的挑战，需要开始向专门的分布式系统转变。这真是一个有趣的经历：我们构建、部署和运行了分布式图数据库、分布式搜索后端、Hadoop套件、一代及二代键值数据库，并运行至今。

在这个过程中，我学到的最有用的一件事情是，我们在这里构建的大多数组件，其核心都有一个简单的概念：日志，有时也被称作先写日志、提交日志或者事务日志，日志几乎与计算机的历史一样悠久，它是许多分布式数据系统和实时应用架构里面的核心。

如果你不了解日志，你也就不可能完全了解数据库、NoSQL存储、键值存储、副本、paxos、hadoop、版本控制、甚至几乎任何软件系统，然而大多数软件工程师都不熟悉它，我希望改变这个现状。在这篇文章中，我将告诉你一切你需要知道的关于日志的事情，包括什么是日志、如何在数据集成、实时处理和系统构建中使用日志。

前言

业务开发时，轮询可以被用于许多场景中，但把握轮询的频次不是一件容易的事情，频次过高会对服务端产生不小的压力，频次过低时，则无法保证实时性。而随着Servlet 3.0异步请求处理的特性支持，DeferredResult的出现很好的解决了这个问题。