（转载请注明作者和出处‘https://fourthringroad.com/’，请勿用于任何商业用途）

之前整理过spring bean管理和web mvc什么的，一直也想写一篇整理整理spring cloud的知识。

在Amazon工作时，搭建微服务有不少技术方案可供选择，Amazon内部有团队对Spring Framework做了一层封装和适配，也成为微服务搭建的选项之一。不过内部对spring别的产品使用较少，我想主要原因是内部存在同类产品，且针对Amazon的技术架构做了一些定制化，更灵活，onboard成本和难度也都控制的不错，所以就只是按需从spring产品中选择了一些纳入进来（当然可能也有商用版权的问题）。18年我所在的团队做的一个CMS系统，使用这个整合Spring Framework的框架搭建了一个Rest风格的服务后端。

在来到京东云后，接手的中间件服务配置中心和调度服务使用了springboot，spring framework和spring cloud，同时在跟应用方打交道过程中，发现90%的客户也都是用的spring全家桶在搭建微服务。

关于Spring团队和产品

从04年发布spring1.0到现在，spring也有快20年的历史了。公司从最早的Interface 21（后改名SpringSource），到12年被VMware收购，再到后来成立Pivotal接着独立上市。相关团队一直致力于java领域的开源开发。现在spring在行业内的流程程度不用赘述，大部分web开发也不用再参照臃肿的J2EE规范。

spring的相关产品也从最初的基础的spring framework发展出spring boot, spring data, spring cloud, spring security…link（https://spring.io/projects）。

关于Spring Cloud

关于Spring Cloud，我理解其实就是将搭建分布式系统中遇到的问题抽象为一些固定模式（pattern），譬如分布式系统如何进行配置管理，服务发现，服务熔断，负载均衡等等。在此基础上给每个模式提供实现的boiler plate。

Boiler Plate类似Template，但是又有区别，template可以理解成参数化的框架，来引导工程师完成系统搭建；但是Boiler Plate在框架上还包括了实现；基本上Spring Cloud的模块我们拿来就可以直接部署，有一个词非常适合形容-开箱即用（out of box ）。

题外话，在亚马逊工作的时候boiler plate，out of box都是常见词汇，从侧面也印证了，给用户提供服务时的易用性（容易onboard）是非常重要的考量标准。

spring cloud也跟各个大的云服务厂商有合作，针对不同的托管服务有定制化的功能，譬如针对AWS的定制化：https://spring.io/projects/spring-cloud-aws

先来看看下面这个demo

利用Eureka实现服务发现

云原生的微服务体系里面有一个重要的原则：铭记所有都是不断变化的。在这种背景下，应该避免所有硬编码的服务地址和端口，于是便有了服务发现的需求。

服务发现本身可抽象成一个数据存储服务，用来注册其他服务的信息，并提供查询功能，Eureka就是这样一个服务；从另一个方面讲，可以提供数据存储查询的服务都具备提供服务发现的能力；事实也是这样，ZK和Consul也可以提供类似服务，Spring Cloud也兼容这两种底层实现。

当然，在所有服务中，也都至少要保留‘服务发现服务’的硬编码地址，同时另一个缺点是这给请求增加了一个额外访问，也给系统增加了一个single point of failure；

首先是如何搭建Eureka这个拆箱即用的服务：

@EnableEurekaServer
@SpringBootApplication
public class EurekaTestServerApplication {
	public static void main(String[] args) {
		SpringApplication.run(EurekaTestServerApplication.class, args);
	}
}

配置：

server:
  port: 8761

eureka:
  client:
    registerWithEureka: false
    fetchRegistry: false
    serviceUrl: #Eureka集群配置，单机配置自己，默认8761
      defaultZone: http://localhost:8761/eureka/

上面就是所有需要的代码。

启动并注册两个服务：

Service-1

@EnableDiscoveryClient
//@EnableEurekaClient
@SpringBootApplication
public class EurekaTestClientApplication {

	public static void main(String[] args) {
		SpringApplication.run(EurekaTestClientApplication.class, args);
	}

}

需要说明@EnableDiscoveryClient相比于@EnableEurekaClient可以兼容更多底层实现。

配置

server:
  port: 8090

spring:
  application:
    name: Service-1

eureka:
  client:
    registerWithEureka: true
    fetchRegistry: true
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/
  instance:
    instance‐id: ${spring.application.name}

在Eureka的管理界面上就可以看到这两个服务的信息了：

上面的过程可以很好的解释了，

为什么使用Spring Cloud？

当工程师需要构建云原生应用时，会发现自己需要在整套分布式系统中实现以下功能：

• 配置管理
• 服务发现
• CircuitBreaker
• 路由和消息通信(Routing and messaging)
• API网关
• 分布式追踪

等等

当你在FAANG这样的公司工作的时候，你可能发现有足够的底层服务提供上述功能，而且你可以用很小的代价就将其集成进来。但是事实上，有更多的公司不具备这样的条件，而是需要工程师重复的构造这些轮子。于是spring cloud就将这些功能做了上层抽象，并提供了相应的，非常容易集成的，解决方案，

• 配置管理：springconfig，可以与Git，SVN，FS或DB结合来管理配置
• 服务发现： Eureka， Zookeeper， Consul
• CircuitBreaker:Hystrix
• 路由和消息通信(Routing and messaging):
  • Routing and LB:Ribbon(实现client side LB) & Feign
  • Messaging:: RabbitMQ or Kafka
• API网关：Zuul/Spring Cloud Gateway
• 分布式追踪：Spring Cloud Sleuth / Zipkin

Spring Cloud的组件在设计时就已经考虑了云原生应用的特性：跨故障域，动态，高可用，高拓展…所以用户可以将设计的重心放在实现业务的组件上面。

利用OpenFeign进行服务间通信

接着上面的demo，当我启动两个服务之后，服务2对服务1的调用流程就是：

• 服务2用注册中心client向注册中心发起请求：查找服务1地址
• 服务2用远程调用client向服务1发起调用请求。

假设服务1对外暴露的接口为

@RestController
public class ServiceController {
    @GetMapping("/ping")
    public String ping() {
        return "service started.";
    }
}

引入Spring Cloud的服务间通信的组件OpenFeign后的实现代码为：

//定义访问Service-1的client与Rest接口的映射
@FeignClient("Service-1")
public interface Service1Client {
    @GetMapping("/ping")
    public String ping();
}

//注入
@Autowired
private Service1Client service1Client;

//使用
Object result = service1Client.ping();

代码非常简洁，启动和初始化过程几乎都被隐藏，用户只需要定义方法映射以及执行调用。同时Feign Client的底层还利用了ribbon，所以具备客户端负载均衡的能力。

这是使用Spring Cloud生态的另一个好处：它不仅仅功能完善，不同组件之间也能够很好的配合衔接。用户能够以非常小的代价集成一个新的功能模块。

(转载请注明作者和出处‘https://fourthringroad.com/’，请勿用于任何商业用途)

ooooookay, 整理一下P1-P3里的内容，把它精简成以下需求：

1. 我有一个配置中心服务，托管用户配置信息。
2. 用户能够用一个注解，将配置信息同步到应用运行时内存的配置bean
3. 当配置中心的配置修改发生时，自动将新的配置同步到相关bean

很简单，来写个demo。

客户端

首先是注解的设计，前面已经讲过了，不赘述：

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface ConfigAnnotation {

    //配置的ID
    String value();

    enum Format {XML, JSON, YML, PROPERTIES}

    //配置文件的类型
    Format format() default Format.PROPERTIES;
}

然后是如何获取配置，以及如何解析配置：

获取配置内容的client，先提供client的抽象

public interface ConfigClient {
    String getConfig(String configId);
}

如何解析配置的相关类，这里提供了Properties文件解析器，其实就是转化为一个string-string的键值map

/**
 * 解析配置文件.
 * 出于demo目的，这里只提供将其转化为Map的接口，用于支持K-V配置的解析，例如java Properties文件解析.
 */
public interface Resolver {
    Map<String, String> resolve(String config);
}

public class ResolverFactory {

    private static final Map<Format, Resolver> resolvers = new ConcurrentHashMap<>();

    public static Resolver getResolver(Format format) {
        switch (format) {
            case XML:
                //TBD
                break;
            case JSON:
                //TBD
                break;
            case YML:
                //TBD
                break;
            case PROPERTIES:
                resolvers.putIfAbsent(Format.PROPERTIES, new PropertiesResolver());
                return resolvers.get(Format.PROPERTIES);
        }
        throw new IllegalStateException("不支持这种格式: " + format);
    }

    public static class PropertiesResolver implements Resolver {
        @Override
        public Map<String, String> resolve(String config) {

            final Properties properties = new Properties();
            try {
                properties.load(new ByteArrayInputStream(config.getBytes(StandardCharsets.UTF_8)));
            } catch (IOException e) {
                throw new IllegalStateException("不能解析Config");
            }
            return (Map) properties;
        }
    }
}

然后是最重要的一步，介入bean的生命周期，给bean赋值并动态更新：

可以看到从两个地方介入了bean的构建过程：

首先是postProcessProperties，对bean的初值进行了赋予，从ConfigManager获得配置信息，解析，然后给bean赋值使用

接着是postProcessAfterInitialization，在bean初始化完成之后，注册到ConfigManager，后者用观察者模式，当检测到配置修改后，相应的也会更新bean实例的属性。

@Component
public class ConfigAnnotationBeanPostProcessor implements InstantiationAwareBeanPostProcessor {

    private final ConfigManager configManager;

    public ConfigAnnotationBeanPostProcessor(ConfigManager configManager) {
        this.configManager = configManager;
    }

    @Override
    public PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName) throws BeansException {

        final Class<?> cls = bean.getClass();

        if (cls.isAnnotationPresent(ConfigAnnotation.class)) {
            final ConfigAnnotation configAnnotation = cls.getAnnotation(ConfigAnnotation.class);

            final String config = configManager.getConfig(configAnnotation.value());
            final Map<String, String> resolvedProperties = ResolverFactory.getResolver(configAnnotation.format())
                    .resolve(config);

            //简便起见，不考虑父类的属性
            final Field[] fields = cls.getDeclaredFields();
            final MutablePropertyValues mutablePropertyValues = new MutablePropertyValues(pvs);
            for (Field field : fields) {
                final String fieldName = field.getName();
                final String fieldValue = resolvedProperties.get(fieldName);
                if (fieldValue != null) {
                    mutablePropertyValues.add(fieldName, fieldValue);
                }
            }
            return mutablePropertyValues;
        }

        return null;
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        final Class<?> cls = bean.getClass();
        if (cls.isAnnotationPresent(ConfigAnnotation.class)) {
            final ConfigAnnotation configAnnotation = cls.getAnnotation(ConfigAnnotation.class);
            configManager.register(configAnnotation.value(), bean, configAnnotation.format());
        }
        return bean;
    }

这里提到的ConfigManager其实功能就是上面两个：周期性的调用ConfigClient的接口去获取配置，保证内存cache中是最新的配置；当检测到配置修改后，修改对应bean中的属性。

/**
 * delegate ConfigClient 来更新内存中的配置
 * 当配置发生改变时通知对应的实例
 */
@Component
public class ConfigManager {

    private final ConfigClient configClient;

    private final Map<String, String> cache = new ConcurrentHashMap<>();

    private final Map<String, Map.Entry<Object, Format>> observers = new ConcurrentHashMap<>();

    public ConfigManager(ConfigClient configClient) {
        this.configClient = configClient;

        final ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
        scheduler.scheduleAtFixedRate(() -> {
            try {
                cache.forEach(
                        (configId, oldConfig) -> {
                            final String newConfig = configClient.getConfig(configId);
                            if (!oldConfig.equals(newConfig)) {
                                cache.put(configId, newConfig);
                                notifyObserver(configId, newConfig);
                            }
                        });
            } catch (Throwable t) {
                t.printStackTrace();
            }
        }, 0, 1, TimeUnit.SECONDS);
    }

    public String getConfig(final String configId) {
        if (cache.containsKey(configId)) {
            return cache.get(configId);
        } else {
            final String config = configClient.getConfig(configId);
            cache.put(configId, config);
            return config;
        }
    }

    public void register(final String configId, final Object bean, final Format format) {
        observers.put(configId, new AbstractMap.SimpleEntry<Object, Format>(bean, format));
    }

    private void notifyObserver(String configId, String config) {
        if (observers.containsKey(configId)) {
            Object bean = observers.get(configId).getKey();
            Format format = observers.get(configId).getValue();
            final Map<String, String> resolvedProperties = ResolverFactory.getResolver(format).resolve(config);
            final Class<?> cls = bean.getClass();
            final Field[] fields = cls.getDeclaredFields();
            for (Field field : fields) {
                field.setAccessible(true);
                final String fieldName = field.getName();
                final String fieldValue = resolvedProperties.get(fieldName);
                if (fieldValue != null) {
                    try {
                        field.set(bean, fieldValue);
                    } catch (IllegalAccessException e) {
                        e.printStackTrace();
                    }
                }
                field.setAccessible(false);
            }
        }
    }
}

最后给我们的工具包增加一个对外输出的配置文件

因为没有搭建真的服务，所有在这里ConfigClient提供了一个stub实现，每调用5次接口，就会切换到一个不同响应配置文件，来模拟配置文件改动的情况。

@Configuration
@ComponentScan("com.sihuan.prototype")
public class ConfigClientConfiguration {

    @Bean
    public ConfigClient configClient() {
        return new StubConfigClient();
    }

    /**
     * 出于测试目的，这里提供一个stub来提供ConfigClient的功能
     */
    public static class StubConfigClient implements ConfigClient {
        private final AtomicInteger counter = new AtomicInteger();

        @Override
        public String getConfig(String configId) {
            if ("testConfig".equals(configId)) {
                return counter.addAndGet(1) / 5 % 2 == 0 ?
                        "name=bob\n" +
                                "job=developer\n" +
                                "company=google\n" +
                                "salary=99999" :
                        "name=jack\n" +
                                "job=sales\n" +
                                "company=apple\n" +
                                "salary=88888";
            }
            throw new RuntimeException();
        }
    }
}

OK，完成之后用户就可以使用了。

用户应用使用

直接定义一个bean，并用上我们的注解

/**
 * 真实情况fields不会都是String，出于演示目的，这里简化了复杂类型转换的场景
 */
@Component
@ConfigAnnotation(value = "testConfig", format = ConfigAnnotation.Format.PROPERTIES)
public class ConfigBean {
    private String name;
    private String job;
    private String company;
    private String salary;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getJob() {
        return job;
    }

    public void setJob(String job) {
        this.job = job;
    }

    public String getCompany() {
        return company;
    }

    public void setCompany(String company) {
        this.company = company;
    }

    public String getSalary() {
        return salary;
    }

    public void setSalary(String salary) {
        this.salary = salary;
    }

    @Override
    public String toString() {
        return "ConfigBean{" +
                "name='" + name + '\'' +
                ", job='" + job + '\'' +
                ", company='" + company + '\'' +
                ", salary='" + salary + '\'' +
                '}';
    }
}

写个main函数来测试：

public class App {
    public static void main(String[] args) throws InterruptedException {
        final AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(CustomerConfiguration.class);

        final ConfigBean configBean = (ConfigBean) context.getBean("configBean");

        while (true) {
            TimeUnit.SECONDS.sleep(1);
            System.out.println(configBean);
        }
    }

    @Configuration
    @Import(ConfigClientConfiguration.class)
    @ComponentScan(value = "org.test")
    public static class CustomerConfiguration {
    }
}

打印结果为：

ConfigBean{name='bob', job='developer', company='google', salary='99999'}
ConfigBean{name='bob', job='developer', company='google', salary='99999'}
ConfigBean{name='bob', job='developer', company='google', salary='99999'}
ConfigBean{name='jack', job='sales', company='apple', salary='88888'}
ConfigBean{name='jack', job='sales', company='apple', salary='88888'}
ConfigBean{name='jack', job='sales', company='apple', salary='88888'}
ConfigBean{name='jack', job='sales', company='apple', salary='88888'}
ConfigBean{name='jack', job='sales', company='apple', salary='88888'}
ConfigBean{name='bob', job='developer', company='google', salary='99999'}
ConfigBean{name='bob', job='developer', company='google', salary='99999'}
ConfigBean{name='bob', job='developer', company='google', salary='99999'}
.......

OK，仅仅通过一个注解帮助我们的客户获取了配置，映射到自定义类中，并且可以实现实时的更新。这个实现方案没有考虑性能和很多细节，真实的方案比这个复杂很多，但是也就意味着，在真正的方案中会给用户节省更多的重复开发，降低onboard难度。

（转载请注明作者和出处‘https://fourthringroad.com/’，请勿用于任何商业用途）

我在犹豫是否要给注解单独写一章，毕竟不是项目重点；但是想了想，简单梳理一下吧，当是温故知新了。

注解是简化代码，提高可读性很好的途径，能够以更好隐藏底层逻辑，实现不同模块的低耦合；对于用户来讲，如果你的服务以注解的方式提供支持，显然能够降低onboard的代码量以及对于用户服务的侵入性。

关于注解的一些基础知识，简单列举一下：

• 说白了注解的本质就是给代码对象（类，方法，参数。。。等）加上一些额外信息，这些额外信息会被一些处理器在处理这些代码对象时使用。这里所谓的额外信息，除了注解本身之外，还有注解提供的配置参数，后者类型包括：基本数据类型，其他注解，String，enum和它们的数组等。
• 元注解用于修饰其他注解，常用的有：
  • @Target:定义注解修饰的对象是什么，包括TYPE, x.FIELD, x.METHOD, x.CONSTRUCTOR, x.PARAMETER 等等。
  • @Retention: 定义注解的生命周期，包括SOURCE, x.CLASS, x.RUNTIME
  • @Inherited: 注解关系是否具有继承性，即子类是否继承父类的接口
• 注解本身不支持继承（extends），但是所有的注解在编译后会继承lang.annotaion.Annotation接口。所以如何获取注解提供的额外信息？显然答案是反射；简单的反射API如下
  • 判断某个类，属性，方法时候有某个注解，例如getClass().isAnnorationPresent(XxAnnotation);
  • 读取注解：XxAnnotationxxAnnotation = xx.getClass().getAnnoration(XxAnnotation.class)；进一步可以通过xxAnnoration实例获得注解的配置参数
  • 更多的方法可以参考java.lang.reflect下的接口AnnotatedElement

OK，上面是一些注解基础知识，如果我们想像在文章p1中讲的那样，自定义一个配置解析的注解，需要怎么做？

@配置专用Annotation（配置ID=“xx” 解析格式=“json/xml/yml...”）
@Component
ConfigBean {
    String foo;
    Long bar;
}

首先确定需要什么元注解：

• 我们需要注解在运行时能够使用，那么就需要定义元注解@Retention，并执行RetentionPolicy为RUNTIME
• 我们需要将配置文件映射到ConfigBean，所以注解使用的对象是类，即ElementType=TYPE

然后确定我们的注解需要提供什么信息：

应用需要跟配置中心服务进行交互，所以需要配置中心服务端地址，同时还需要应用名称和配置的ID来定位一个具体的配置文件；如何解析一个配置文件（xml，json，yml…）；配置中心服务端地址和应用名称是公用的，所以可以放置到公共的配置文件中；在注解层面需要提供的就是配置的ID和解析方式。

最后我们需要实现处理器：

在运行时，如何将带有自定义注解的ConfigBean与相应配置文件同步？显然我们需要自定义一个处理器，并且在Bean的合适的生命周期节点执行这个处理器的逻辑，这个处理器的逻辑为：解析注解配置，获得需要同步的配置信息以及解析方式，向配置中心发起获取配置信息，在拿到配置后，用匹配的解析器解析配置文件并赋予ConfigBean。

代码架构如下：

//注解本身
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface ConfigAnnotation {

    //配置的ID
    String value();

    enum Format {XML, JSON, YML, PROPERTIES}

    //配置文件的类型
    Format format() default Format.PROPERTIES;
}

//在实体类使用注解
@ConfigAnnotation(value = "xx.json", format = ConfigAnnotation.Format.JSON)
public class ConfigBean {

    private String foo;

    private Integer bar;
}

//注解处理器的逻辑
public class Processor {

    private ConfigService configService;

    private Resolver resolver;

    public Object getInstance(String reference) throws ClassNotFoundException {
        final Class<?> aClass = Class.forName(reference);

        if (aClass.isAnnotationPresent(ConfigAnnotation.class)) {
            ConfigAnnotation configAnnotation = aClass.getAnnotation(ConfigAnnotation.class);

            //读取配置属性
            final String configID = configAnnotation.value();
            final ConfigAnnotation.Format format = configAnnotation.format();

            //获取配置
            final String config = this.configService.getConfig(configID);

            //解析配置
            return this.resolver.resolve(config, aClass);
        }

        throw new IllegalStateException("处理失败");
    }
}

作为服务的提供方，处理器的逻辑被我完全隐藏了起来，用户只需要简单的利用我定义的注解进行服务接入，OK，世界变得更美好了。

（转载请注明作者和出处‘https://fourthringroad.com/’，请勿用于任何商业用途）

上篇文章大概描述了背景，这篇讲讲spring如何管理bean生命周期以及预留的各种hooks。

在进入正题之前先确认第一个问题：

spring管理bean的容器是在哪儿?

作为最核心的接口，我们可以从ApplicatonContext入手，从类的继承关系上可以看出它具备的能力包括：资源加载（ResourceLoader），事件发布（EventPublisher），消息解析（MessageSource），类工厂（BeanFactory）等等

显然其中的工厂类ListableBeanFactory跟Bean的构造最直接相关：

简单浏览ApplicationContext实现类的代码，就可以发现AC本质上是Delegate一个DefaultListableBeanFactory实例去填充上面BeanFactory和ListableBeanFactory中的方法具体逻辑。例如在下面的实现类中就有一个DefaultListableBeanFactory属性：

我们转向DefaultListableBeanFactory，它涉及功能更多，实现的接口与抽象类也更复杂，拆这么细应该也是遵循了设计模式的接口隔离原则，方便后期的维护拓展。它继承的其中一个类是DefaultSingletonBeanRegistry，我们发现这里有存储单例类实例的Map（prototype显然不需要存储）：singletonObjets & earlySingletonObjects。

所以问题的答案就是众人皆知的BeanFactory，它的实现类具备了创建，查询以及存储上下文中beans的能力。bean生命周期显然跟它的子类息息相关。

Spring Bean的生命周期

我们先从ApplicationContext最常见的实现类ClassPathXmlApplicationContext的构造函数入手，可以很快定位启动的入口函数AbstractApplicationContext#refresh，这个方法的成功执行意味着spring上下文的成功加载。我们对其中的两个个重要方法进行分析：

BeanFactory实例的构造 – obtainFreshBeanFactory()

文章的开头提到了BeanFactory是bean生命周期直接相关的工厂类，显然AC在启动过程中，初始化BeanFactory过程中做了什么操作是很重要的。我们从这个方法进入可以追踪到如下的初始化代码：

可以看到在创建一个DefaultListableBeanFactory实例之后，有一个加载所有BeanDefinition的操作-loadBeanDefinitions(beanFactory)；这个BeanDefinition很好理解，其实就是关于一个Bean的所有定义，BeanFactory会通过这个定义去构造Bean的实例。因为我们使用的是ClassPathXmlApplicationContext，那么假定前提就是我们对bean的定义位于XML配置文件中，这个loadBeanDefinitions方法的实现就位于AbstractXmlApplicationContext类中，如下我们可以看到有构造XML相关的Reader来执行加载过程：

经过了这一步，就拿到了所有bean的定义，那么就可以开始bean的初始化过程了。

普通Bean的初始化 – finishBeanFactoryInitialization(beanFactory)

普通单例类的初始化逻辑的入口位于倒数第二个方法，finishBeanFactoryInitialization(beanFactory)；这个方法调用链的底层，是调用BeanFactory#getBean创建bean实例；进一步深入，BeanFactory的子类AbstractAutowireCapableBeanFactory中的方法createBean以及doCreateBean会被调用，如下：

执行完这个流程之后，一个bean就被初始化完成并放入缓存，等待运行时使用以及最后的销毁，实际上这就是是bean的生命周期，红框中包括了这个流程中的核心逻辑，如果接着上文中加载BeanDefinition之后，把接下来代码用一个流程图来展示：

红框中是四个关键步骤：

• 实例化创建：创建一个bean实例
• 赋值：给bean实例的属性赋值。
• 初始化：执行初始化函数（如果有的话）
• 销毁：执行销毁函数（如果有的话）

其他无色流程框的都是可以自定义的扩展点。spring给四个关键环节提供最简单的接入方法，分别是：默认构造函数，setter方法，init-method， destroy-method。假如使用者完全不介入spring bean的生命周期，显然和new一个对象并进行使用几乎是一样的。

可以看到无色方框是围绕四个关键步骤的扩展点，意味着我们可以在bean的不同阶段进行干预。

除此之外还有一些小的扩展点其实也都是围绕上面的主流程，譬如假如一个bean实现了InitializingBean接：

那么里面的afterPropertiesSet()方法的调用点在哪里呢？实际上就在Initialization步骤里执行init-method之前：

对BeanFactory进行处理的Hooks：

值得一提还有一个针对BeanFactory的钩子：我们在refresh方法中，可以看到在构造BeanFactory的实例之后，有一步：invokeBeanFactoryPostProcessors()，在里面预留了对BeanDefinitionRegistryPostProcessor和BeanFactoryPostProcessor相应方法的调用，用于对BeanFactory实例进行额外处理。

例子 – ApplicationContextAwareProcesser

在refresh的主流程步骤prepareBeanFactory中，注册了一个spring 官方的BeanPostProcessor- ApplicationContextAwareProcesser，我们来看看它对bean的生命周期进行了什么操作

可以看到它在bean的初始化阶段发生前调用了invokeAwareInterfaces方法，在这个方法里面，依次判断了当前bean是否实现/继承了xxAware接口/类，如果是，则调用相应的set方法把xx实例设置到bean的属性中。这实际上解释了为什么我们在日常使用中，一个类实现了ApplicationContextAware接口，在初始化过程中，以及后续runtime时期就可以在bean内部使用ApplicationContext实例。正是因为ApplicationContextAwareProcesser这个处理器在bean初始化过程中做了手脚。

小结

Spring bean的生命周期其实就是由很多扩展点构成，这里把整体梳理了一遍，但是针对每个拓展点没有深入的讲，有一些小的拓展点也没有提及，用的时候再深入研究即可，没有必要死记硬背。

Spring的拓展性一直为人称道，其实就是很好的遵循了一些编程思想，比如面向接口编程，接口隔离，以及采用了类似Service Provider Interface（SPI）的模式。这些方法也常常在一些扩展性好的，所谓的面向插件编程的系统上见到，比如前一阵在做ES插件开发的时候就深有体会。

但是回过头，像前文提到的一样，这些功能用户可以根据说明文档就很好的把它当成黑盒使用吗？显然是很难的，阅读源码基本上是每一个用户必经之路，这也就是Spring框架，至少在bean管理方面，我认为比较繁重的原因。