05、Sentinel 源码分析之 SPI 机制

痛定思痛。 2022-10-29 10:26 311阅读 0赞

我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块的方案，xml解析模块、jdbc模块的方案等。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。

为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。java spi 就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。

## 1、什么是SPI ##

这里先说下SPI的一个概念，SPI 英文为 Service Provider Interface 单从字面可以理解为Service提供者接口，正如从 SPI 的名字去理解 SPI 就是 Service 提供者接口；我对 SPI 的定义：提供给服务提供厂商与扩展框架功能的开发者使用的接口。

很多框架都使用了 java 的 SPI 机制，如 JDBC4 中的 **java.sql.Driver** 的 SPI 实现 (mysql驱动、oracle驱动等)、**common-logging** 的日志接口实现、dubbo 的扩展实现等等框架;

当服务的提供者，提供了服务接口的一种实现之后，在jar包的 `META-INF/services/` 目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包`META-INF/services/`里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定。

## 2、Sentinel 加载 SPI 接口 ##

在 Sentinel 中也是通过对 Java 中原生 SPI 接口进行包装，而不是像 dubbo 或者 Spring 自己重新定义一套。Sentinel 通过 ServiceLoaderUtil 包装 `java.util.ServiceLoader` 来加载位于 `META-INF/services/` 目录下的 SPI 接口。

public final class ServiceLoaderUtil { 
    
        private static final String CLASSLOADER_DEFAULT = "default";
        private static final String CLASSLOADER_CONTEXT = "context";
    
        public static <S> ServiceLoader<S> getServiceLoader(Class<S> clazz) { 
            if (shouldUseContextClassloader()) { 
                return ServiceLoader.load(clazz);
            } else { 
                return ServiceLoader.load(clazz, clazz.getClassLoader());
            }
        }
    
        public static boolean shouldUseContextClassloader() { 
            String classloaderConf = SentinelConfig.getConfig(SentinelConfig.SPI_CLASSLOADER);
            return CLASSLOADER_CONTEXT.equalsIgnoreCase(classloaderConf);
        }
    
        private ServiceLoaderUtil() { }
    }

然后通过 `SpiLoader` 这个接口来对外进行 SPI 接口的最终加载。它对外提供了 6 个接口：

*  `loadFirstInstance(Class<T> clazz)`：加载 clazz 这个类型所有的 SPI 实现类，如果能够找到就返回第一个 SPI 接口实现类，否则返回 null。
 *  `loadFirstInstanceOrDefault(Class<T> clazz, Class<? extends T> defaultClass)`：加载 clazz 这个类型所有的 SPI 实现类，首先r找返回非 `defaultClass` 这个 SPI 实现类，如果能够找到直接返回，否则返回 `defaultClass` 这个 SPI 实现类。
 *  `loadHighestPriorityInstance(Class<T> clazz)`：加载 clazz 这个类型所有的 SPI 实现类，然后遍历所有的实现类如果类如果类上没有标注 `@SpiOrder` 注解说明这个类的优先级最低。如果标注了 `@SpiOrder` 注解，它的值越低优先级越高。这个方法会返回SPI 实现类优先级最高的类。
 *  `loadInstanceList(Class<T> clazz)`：加载 clazz 这个类型所有的 SPI 实现类，并返回这个 SPI 实现类的列表
 *  `loadInstanceListSorted(Class<T> clazz)`：加载 clazz 这个类型所有的 SPI 实现类，并按照优先级从高到低返回 SPI 实现类列表(每次返回都是同样的实例，因为是单例模式)
 *  `loadPrototypeInstanceListSorted(Class<T> clazz)`：加载 clazz 这个类型所有的 SPI 实现类，并按照优先级从高到低返回 SPI 实现类列表(每次返回都是不同的实例，因为是非单例模式)

## 3、Sentinel 中 SPI 接口 ##

下在我们就拿几个 Sentinel 框架与我们关系最紧密，与我们分析 Sentinel 框架最重要的几个 SPI 接口进行讲解一下。

### 3.1 InitFunc ###

它的作用是在 Sentinel 在资源进行规则保护调用之前进行初始化功能的。下面是这个接口的定义：

public interface InitFunc { 
    
        void init() throws Exception;
    }

这个接口只有一个 `init` 方法，这个接口的作用就是初始化资源。在调用 Sentinel 资源保护之前会调用这个接口。它是通过由 `InitExecutor` 类调用 `doInit` 进行初始化的。

### 3.2 SlotChainBuilder ###

Sentinel 框架对于资源进行保护的时候其实是通过一个一个类这种责任链的模式对保护的资源进行拦截来达到资源保护的作用。而 SlotChainBuilder 就是构建这个拦截器链的类。

这个接口的定义如下：

public interface SlotChainBuilder { 
    
        /** * Build the processor slot chain. * * @return a processor slot that chain some slots together */
        ProcessorSlotChain build();
    }

它是由 `SlotChainProvider` 这个类通过 `newSlotChain` 来加载拦截器默认构建类 `DefaultSlotChainBuilder` 并调用 `SlotChainBuilder#build` 完成对拦截器链的构建。在它的内部其实也是通过 SPI 来加载 `ProcessorSlot` 这个拦截器处理类。

### 3.3 ProcessorSlot ###

它的作用是在调用资源之前，对资源进行保护增强，有点类似于 Spring AOP 的概念。下面就是这个接口的定义：

public interface ProcessorSlot<T> { 
    
        void entry(Context context, ResourceWrapper resourceWrapper, T param, int count, boolean prioritized,
                   Object... args) throws Throwable;
    
        void fireEntry(Context context, ResourceWrapper resourceWrapper, Object obj, int count, boolean prioritized,
                       Object... args) throws Throwable;
                       
        void exit(Context context, ResourceWrapper resourceWrapper, int count, Object... args);
    
        void fireExit(Context context, ResourceWrapper resourceWrapper, int count, Object... args);
    }

它是由 `DefaultSlotChainBuilder` 进行触发加载的。在我们进行资源规则保护的时候是调用 `SphU.entry("规则名称")` 与 `entry.exit()` 这两个方法来包裹资源就可以了。`SphU.entry("规则名称")` 这个其实是 Sentinel 简化了我们的使用以及对概念的理解。而 `ProcessorSlot` 这个接口里面定义的方法才是真正对资源保护的处理。这个章节我们只需要分析 SPI 接口的加载，对于 Sentinel 对于保护资源的拦截的处理，我们下一个章节再进行讨论。

### 3.4 HeartbeatSender ###

这个功能是与 Sentinel 的 dashboard 进行心跳连接。它的接口定义如下：

public interface HeartbeatSender { 
    
        /** * Send heartbeat to Sentinel Dashboard. Each invocation of this method will send * heartbeat once. Sentinel core is responsible for invoking this method * at every {@link #intervalMs()} interval. * * @return whether heartbeat is successfully send. * @throws Exception if error occurs */
        boolean sendHeartbeat() throws Exception;
    
        /** * Default interval in milliseconds of the sender. It would take effect only when * the heartbeat interval is not configured in Sentinel config property. * * @return default interval of the sender in milliseconds */
        long intervalMs();
    }

它首先由 `InitFunc` 这个 SPI 的实现类 `HeartbeatSenderInitFunc` 进行触发的。

## 4、其它 ##

当然 Sentinel 框架中还包括(但不限于)以下 SPI 接口，我就不一一分析了：

*  CommandMapping：由 CommandHandlerProvider 类触发
 *  EmbeddedClusterTokenServer：由 EmbeddedClusterTokenServerProvider 类触发
 *  ClusterTokenClient：由 TokenClientProvider 类触发
 *  TokenService：由 TokenServiceProvider 类触发