蒋先森のBlog

spring boot 源码版本 2.0.9.RELEASE。spring boot 高版本，没有走AutoConfigurationImportSelector#selectImports方法。

Spring Boot 自动装配

先看下Spring Boot 启动类注释 @SpringBootApplication。在这些注解中，重要的就是两个 @SpringBootConfiguration 和 @EnableAutoConfiguration。从下图可以看到该注解是个组合注解，本文关于自动装配，用了到里面的 @EnableAutoConfiguration 里面的 @Import(AutoConfigurationImportSelector.class)。

@Import({AutoConfigurationImportSelector.class}) 主要功能就是自动配置导入选择器。

AutoConfigurationImportSelector#selectImports

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@Override
public String[] selectImports(AnnotationMetadata annotationMetadata) {
	if (!isEnabled(annotationMetadata)) {
		return NO_IMPORTS;
	}
	AutoConfigurationMetadata autoConfigurationMetadata = AutoConfigurationMetadataLoader
			.loadMetadata(this.beanClassLoader);
	AnnotationAttributes attributes = getAttributes(annotationMetadata);
       // 所以的配置存放在configuration中，获取所有依赖的配置
	List<String> configurations = getCandidateConfigurations(annotationMetadata,
			attributes);
	configurations = removeDuplicates(configurations);
	Set<String> exclusions = getExclusions(annotationMetadata, attributes);
	checkExcludedClasses(configurations, exclusions);
	configurations.removeAll(exclusions);
	configurations = filter(configurations, autoConfigurationMetadata);
	fireAutoConfigurationImportEvents(configurations, exclusions);
	return StringUtils.toStringArray(configurations);
}

参数含义：

• AnnotationMetadata：SpringBoot启动类上的注释的全限定名，比如 @com.springboot.sample.starter.annotation.EnableSampleServer()
• AutoConfigurationMetadata：依赖的AutoConfiguration类的元数据

AutoConfigurationImportSelector#getCandidateConfigurations

源码版本是 2.7.8

Dubbo 服务导出过程始于 Spring 容器发布刷新事件，Dubbo 在接收到事件后，会立即执行服务导出逻辑。整个逻辑大致可分为三个部分，第一部分是前置工作，主要用于检查参数，组装 URL。第二部分是导出服务，包含导出服务到本地 (JVM)，和导出服务到远程两个过程。第三部分是向注册中心注册服务，用于服务发现。本篇文章将会对这三个部分代码进行详细的分析。

在 2.7.8 版本中，服务导出的入口已经在 DubboBootstrapApplicationListener onApplicationContextEvent方法是在 onApplicationEvent中引用的，onApplicationEvent 是一个事件响应方法，该方法会在收到 Spring 上下文刷事件后执行服务导出操作。

在DubboBootstrap.start调用中，会调用一个exportServices方法，这个方法中，会调用 export 方法，这是就开始服务导出流程了。

前置工作

export

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

public synchronized void export() {
    if (bootstrap == null) {
        bootstrap = DubboBootstrap.getInstance();
        bootstrap.initialize();
    }

    checkAndUpdateSubConfigs();

    //init serviceMetadata 初始化服务元数据
    serviceMetadata.setVersion(getVersion());
    serviceMetadata.setGroup(getGroup());
    serviceMetadata.setDefaultGroup(getGroup());
    serviceMetadata.setServiceType(getInterfaceClass());
    serviceMetadata.setServiceInterfaceName(getInterface());
    serviceMetadata.setTarget(getRef());

    //如果不允许暴露，直接放过 <dubbo:provider export="false" />
    if (!shouldExport()) {
        return;
    }
    // 如果需要延迟，则延迟暴露
    if (shouldDelay()) {
        DELAY_EXPORT_EXECUTOR.schedule(this::doExport, getDelay(), TimeUnit.MILLISECONDS);
    } else {
        // 直接暴露
        doExport();
    }
    exported();
}

ServiceConfig.export是继承重写了父类ServiceConfigBase.export方法。在export方法中，主要是以下逻辑：

• 检测 dubbo:service 标签的 interface 属性合法性，不合法则抛出异常
• 检测 ProviderConfig、ApplicationConfig 等核心配置类对象是否为空，若为空，则尝试从其他配置类对象中获取相应的实例。
• 检测并处理泛化服务和普通服务类
• 检测本地存根配置，并进行相应的处理
• 对 ApplicationConfig、RegistryConfig 等配置类进行检测，为空则尝试创建，若无法创建则抛出异常
• 主要是初始化服务元数据
• 对export配置项进行检查，判断是否需要导出服务
• 如果需要延迟，则延迟导出，否则直接导出服务

源码版本是 2.7.8

在以前的文章中，介绍过 Java SPI机制，想了解的可以进去了解下。今天我们要讲的是 Dubbo SPI机制。

Dubbo SPI 实例

本实例参考的是dubbo官方给的官方实例。

首先定义一个接口，名称Robot。

1
2
3

public interface Robot {
    void sayHello();
}

接下来定义两个实现类，分别是 OptimusPrime 和 Bumblebee。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class OptimusPrime implements Robot {

    @Override
    public void sayHello() {
        System.out.println("Hello, I am Optimus Prime.");
    }
}

public class Bumblebee implements Robot {

    @Override
    public void sayHello() {
        System.out.println("Hello, I am Bumblebee.");
    }
}

接下来在META-INF/dubbo文件夹下创建一个文件，名称为Robot 的全限定名 com.dubbo.provider.demo.Robot (根据项目实际的全限定名)，文件配置内容：

1
2

optimusPrime = org.apache.spi.OptimusPrime
bumblebee = org.apache.spi.Bumblebee

源码版本是 2.7.8

什么是注册中心？

服务治理框架中大致分为服务通信和服务管理两部分，服务管理可以分为服务注册、服务发现以及服务被热加工介入，服务提供者Provider会往注册中心注册服务，而消费者Consumer会从注册中心订阅相关服务，并不会订阅全部的服务。

dubbo-registry 模块

在dubbo中，注册中心相关的代码在dubbo-registry模块下，子模块dubbo-registry-api中定义了注册中心相关的基础代码，而在dubbo-registry-xxx模块中则定义了具体的注册中心类型实现代码，例如dubbo-registry-zookeeper模块则存放了zookeeper注册中心的实现代码。

类关系图：

dubbo-registry-api 相关实现

源码版本是 2.7.8

Dubbo 提供一下几种负载均衡

• RandomLoadBalance：加权随机算法
• RoundRobinLoadBalance：加权轮询负载均衡
• LeastActiveLoadBalance：最小活跃数负载均衡。活跃调用数越小，表明该服务提供者效率越高，单位时间内可处理更多的请求。
• ConsistentHashLoadBalance：一致性Hash负载均衡
• ShortestResponseLoadBalance：最短响应负载均衡

Dubbo 的负载均衡代码位于 dubbo-cluster 目录下。抽象类 AbstractLoadBalance 实现了 LoadBalance，然后dubbo提供的几种负载均衡方法，实现了AbstractLoadBalance#doSelect

负载均衡策略

1
2
3
4
5
6

@SPI(RandomLoadBalance.NAME)
public interface LoadBalance {
    @Adaptive("loadbalance")
    <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;

}

负载均衡主要是从服务提供者列表中，选择一个。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

public abstract class AbstractLoadBalance implements LoadBalance {
    static int calculateWarmupWeight(int uptime, int warmup, int weight) {
        int ww = (int) ((float) uptime / ((float) warmup / (float) weight));
        return ww < 1 ? 1 : (ww > weight ? weight : ww);
    }

    @Override
    public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {
        if (CollectionUtils.isEmpty(invokers)) {
            return null;
        }
        if (invokers.size() == 1) {//当只有一个提供者时，直接返回
            return invokers.get(0);
        }
        //选择一个服务
        return doSelect(invokers, url, invocation);
    }
	//具体的负载均衡策略由子类来实现
    protected abstract <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation);

    //权重方法
    protected int getWeight(Invoker<?> invoker, Invocation invocation) {
        int weight = invoker.getUrl().getMethodParameter(invocation.getMethodName(), Constants.WEIGHT_KEY, Constants.DEFAULT_WEIGHT);
        if (weight > 0) {
            long timestamp = invoker.getUrl().getParameter(Constants.REMOTE_TIMESTAMP_KEY, 0L);
            if (timestamp > 0L) {
                int uptime = (int) (System.currentTimeMillis() - timestamp);
                int warmup = invoker.getUrl().getParameter(Constants.WARMUP_KEY, Constants.DEFAULT_WARMUP);
                if (uptime > 0 && uptime < warmup) {
                    weight = calculateWarmupWeight(uptime, warmup, weight);
                }
            }
        }
        return weight >= 0 ? weight : 0;
    }

}

RandomLoadBalance (随机选择算法)

源码版本是 2.7.8

Dubbo 是一款高性能、轻量级基于 Java 开发的 RPC 开源框架，是阿里 SOA 服务化治理方案的核心框架。

什么是 RPC ?

PC英文全名为Remote Procedure Call，也叫远程过程调用，其实就是一个计算机通信协议，它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。计算机通信协议有很多种，对于开发来说，很多熟悉的是HTTP协议，我这里就做个简单的比较，HTTP协议是属于应用层的，而RPC跨越了传输层和应用层。HTTP本身的三次握手协议，每发送一次请求，都会有一次建立连接的过程，就会带来一定的延迟，并且HTTP本身的报文庞大，而RPC可以按需连接，调用结束后就断掉，也可以是长链接，多个远程过程调用共享同一个链接，可以看出来RPC的效率要高于HTTP，但是相对于开发简单快速的HTTP服务,RPC服务就会显得复杂一些。

Dubbo 框架设计

先介绍下Dubbo框架的各个模块

dubbo-registry 注册中心模块

基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。

声明：如果本文有错误，希望指出。

ReentrantLock 位于 java.util.concurrent.locks 包下，它实现了 Lock 接口和 Serializable 接口。

ReentrantLock 默认非公平，但可实现公平的(构造器传true)，悲观，独享，互斥，可重入，重量级锁。ReentrantLock 就是一个普通的类，它是基于 AQS(AbstractQueuedSynchronizer)来实现的。

ReetrantLock 基本用法

构造方法

1
2
3
4
5
6
7

public ReentrantLock() {
    sync = new NonfairSync();
}
//判断是否开启公平锁
public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

ReentrantLock 提供公平锁和非公平锁的构造方法，默认构造方法是非公平锁。

NonfairSync 和 FairSync 都是 ReentrantLock 的内部类，继承 Sync 类。

关于公平锁和非公平锁的区别，主要是在多线程情况下，获取锁的机会是否相同。

kubernetes 是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful），Kubernetes提供了应用部署，规划，更新，维护的一种机制。

Kubernetes 有多种安装方式，比如麻烦无比的二进制安装方式，本篇文章主要讲解如何使用 Kubeadm 来安装 Kubernetes 集群。

前期准备工作

本文搭建的只是 Kubernetes 集群，而不是 Kubernetes 高可用集群，高可用集群需要多台 master 节点来避免 master 节点中某台服务可能宕机。下面这些前期准备，需要在所以服务器上执行一遍。由于本文使用的操作系统是 Centos，其中你是 Ubuntu 用户，请查看官方具体的操作。

根据表格中的信息修改服务器主机名的，具体的主机名请根据自己实际命名修改。需要注意的是，必须保证每台服务器的主机名唯一。

1
2
3
4
5

# 修改主机名
hostnamectl set-hostname k8s-master-11.cn

# 查看主机名
hostname

向每台服务器上的 /etc/hosts 文件添加一下配置。因为只有三台服务器，我们直接修改 hosts 文件来指定，如果是很大的集群，每次添加一个节点，都要修改每台服务器的 hosts 文件，这样会很麻烦，所以可以选择使用dns去解析，但是我们这里只有几台服务器，就直接修改 hosts 文件即可。

1
2
3

192.168.60. k8s-master-252.cn
192.168.60.227 k8s-node-227.cn
192.168.60.15 k8s-node-15.cn

关闭防火墙

本文是读《深入剖析 Kubernetes》的笔记

在很久之前写过几篇关于 Docker 的文章，当时也正处于自己接触 Docker 不久，后来一直没在实际环境中使用过。最近公司要搞一套服务，需要使用 Kubernetes 来编排所以的容器。然后就重新拾起 Docker 的内容，最近也在学习 Kubernetes，最近在看极客时间的《深入剖析Kubernetes》，感兴趣的可以从下面地址购买。

在之前知道 Docker 容器使用了 Namespace 和 Ggroups 技术，但是对于这两个东西具体是什么，还真没搞清楚过。真心推荐极客时间的这么课，还是非常不错的。

容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造一个”边界“。

对于Docker等大多数Linux容器来说，Cgroups是用来制造约束的主要手段，Namespace则是用来修改进程试图的主要方法。

Namespace

namespace 是 Linux 内核用来隔离内核资源的方式。通过 namespace 可以让一些进程只能看到与自己相关的一部分资源，而另外一些进程也只能看到与它们自己相关的资源，这两拨进程根本就感觉不到对方的存在。具体的实现方式是把一个或多个进程的相关资源指定在同一个 namespace 中。

Linux namespaces 是对全局系统资源的一种封装隔离，使得处于不同 namespace 的进程拥有独立的全局系统资源，改变一个 namespace 中的系统资源只会影响当前 namespace 里的进程，对其他 namespace 中的进程没有影响。

使用过 Docker 的应该知道，如果我们使用 docker exec -it 进入容器，然后使用ps命令，你会看到以下信息：

最近在测试环境登录的时候，突然出现了下面的异常。

本来这条SQL只查询一条数据的，但是在错误日志中，发现后面莫名其妙的多了一个LIMIT。第一个反应是不是这个查询的前面用错了PageHelper的分页功能，但是查看了项目中的这处查询，发现LIMIT只是在SQL里面写死了LIMIT 1。我就懵逼了，问了下同事，同事说以前项目也出现过这种抽风的现象，然后我一脸黑人问号。

最近几天大致的看了下PageHelper(文章后面给了源码地址)这个分页工具的源码。在项目中，根据PageHelper的文档，一般会使用以下前两种分页方法(官方文档也推荐这样使用，其实我本人使用最多的是第三种)：

1
2
3
4
5
6
7
8

PageHelper.startPage(1, 10);
List<User> list = userMapper.selectIf(1);
//或者
PageHelper.offsetPage(1, 10);
List<User> list = userMapper.selectIf(1);

//jdk8 lambda用法
Page<User> page = PageHelper.startPage(1, 10).doSelectPage(()-> userMapper.selectGroupBy());

从上面我们可以看出，分页的数据和SQL查询是分开的，那么PageHelper是如何做到把分页数据准确的拼接到SQL后面呢？如果你在源码中点开 PageHelper 这个类，你会发现这个类是继承 PageMethod 以及实现 Dialect 接口的。在 PageMethod 中，定义了一个 protected static final ThreadLocal<Page> LOCAL_PAGE = new ThreadLocal<Page>(); 的全局常量，然后在源码中，你会发现PageHelper只是把你的分页数据，放到了ThreadLocal LOCAL_PAGE中了，然后就没然后了。

虽然PageHelper还有别的一些设置，比如数据库方言的选择等，但是我们今天不讨论这些，如果自己感兴趣的话，可以去翻翻源码。如果仔细的看下源码，会发现一个 PageInterceptor 类，这个类实现的是 ibatis 的 Interceptor。在拦截器中，PageHelper 判断是查询语句是否需要分页，是否需要count查询，分页数据拼接查询等操作。下面三个截图大致的说明了一些拦截器中的一些原理(作者源码注释还是挺好理解的)。