spring、dubbo的扩展机制与微内核架构

Spring扩展体系

spring 扩展体系

BeanFactoryPostProcessor 接口

这个接口作用在容器实例化bean之前，可以读取bean的定义，并可以修改它、可以添加bean的定义，是之作用与容器。
spring最早的推荐使用的配置方式是XML，后来对javaconfig配置方式的支持，就是通过ConfigurationClassPostProcessor实现的。
对ImportSelector和ImportBeanDefinitionRegistrar这两个接口的支持，就是spring boot自动配置的基础。
如果spring要支持其他的配置方式只要添加另外的ConfigurationXXXPostProcessor即可。

BeanPostProcessor 接口

BeanPostProcessor会在Bean实例化完毕后执行，所以任何BeanPostProcessor都是在BeanFactoryPostProcessor之后执行的。通过这个接口可以修改bean实例的属性，甚至可以替换bean的实例（AOP）。
对AOP动态代理的支持是通过AnnotationAwareAspectJAutoProxyCreator实现的。
对Autowired依赖注入是通过RequiredAnnotationBeanPostProcessor实现的。
对JSR-255注入的支持是通过CommonAnnotationBeanPostProcessor实现的。
等等很多个BeanPostProcessor造就了spring强大的功能，如果spring 支持其他的注入方式也只需要添加一个XXXAnnotationBeanPostProcessor即可。

Post-Processor扩展机制

在spring中这类接口叫做"后置处理器"，BeanFactoryPostProcessor是容器的后置处理器，BeanPostProcessor是Bean的后置处理器。
比如AOP的实现，容器会在实例化Bean的时候给BeanPostProcessor多次机会来修改Bean的属性或者返回Bean代理，在实例化前，实例化后，Bean属性填充后多个切入点调用BeanPostProcessor。最终在Bean属性填充后AnnotationAwareAspectJAutoProxyCreator返回了Bean的代理。
这种扩展机制其实就是一种回调机制，在适当的时机通过回调来改变自身的状态、属性、和行为，甚至可以把自己干掉，重新替换一个。

dubbo扩展体系

dubbo扩展体系

抽象

要想实现扩展抽象是必不可少的，以dubbo的传输协议包dubbo-remoting看看其抽象的层级。
第一层、接口层 抽象出了服务端server、客户端client、链接Channel、消息处理器ChannelHandler等。
第二层、传输层 抽象出了AbstractServer、AbstractClient、CodecAdapter等，包含了对线程池的处理实现，链接的处理实现、编码器的适配等。
第三层、交换层 抽象出了Response、Request 这一层开始涉及到一些传输的细节，同时实现了心跳机制。
netty、mina只需要实现第二层就行了，因为在netty、mina的世界里只有链接和编码。
上游的消费者RCP层只要关注第三层交换层就行了，因为在RPC的世界里只有Response、Request 。
在dubbo里对应传输协议、RPC协议、注册协议等问题域的抽象是很值得学习的。
因此你会发现如果要扩展一个传输工具或者一个RPC协议，只要按照dubbo抽象出来的接口实现就行了。

SPI扩展机制

Service Provider Interface 简称SPI ，是JDK内置的一种服务提供发现机制。 它就是一种动态发现并替换服务实现的机制。
服务描述的方式是，在JAR包的"src/META-INF/services/"目录下建立一个文件，文件名是接口的全限定名，文件的内容可以有多行，每行都是该接口对应的具体实现类的全限定名。
一个简单的例子：

接口
package org.jsets.test;
public interface IService {
    void doSomething();
}
实现一：
package org.jsets.test;
public class DogService implements IService{
    public void doSomething() {
        System.out.println("汪汪 ... ");
    }
}
实现二：
public class CatService implements IService{
    public void doSomething() {
        System.out.println("喵喵 ... ");
    }
}
服务配置：在resources目录下建立META-INF/services目录，
在里面建立org.jsets.test.IService文件
文件里面的内容是：org.jsets.test.CatService

测试：
package org.jsets.test;
import java.util.ServiceLoader;
public class IServiceTest {
    public static void main(String[] args) {
        ServiceLoader<IService> loaders = ServiceLoader.load(IService.class);
        for (IService d : loaders) {
            d.doSomething();
        }
    }
}
您会看到输出的是：喵喵 ...
修改org.jsets.test.IService文件里面的内容为：org.jsets.test.DogService
再次运行测试代码，您会看到输出的是：汪汪 ...

dubbo中对SPI机制进行了封装，支持注解的方式实现，但是原理是一样的。

微内核架构

看了上面的Spring和dubbo的扩展机制，您对微内核架构应该有了一个大概的认识了。

微内核架构，先实现系统的最小可用版本，提供特定的扩展机制，使用扩展机制可以向内核添加不同的扩展服务(插件)，并且可以替换和卸载这些扩展。

最小化核心的微内核架构，内核不做任何业务逻辑，只负责扩展服务（插件）的组装。所有的功能均有插件实现，比如“Maven”。

即最小化核心的微内核

带有内核的微内核架构，内核包含了最基本服务，微内核加载内核里的基本服务。即使没有插件也能提供基本功能，如“Eclipse”。

微内核架构

您可能会发现好多系统是采用这样的设计思想，没错，可能您从来没注意过它们，下一个系统或许可以多思考下如何来设计您的微内核和插件体系。设计一个高扩展性的系统并非那么遥不可及。

码字不易，转载请保留原文连接[https://www.jianshu.com/p/2f1a316185b1)