技术总结

这两个URL只有schema不一样，一个是service-discovery-registry，一个是registry，而registry是Dubbo3之前就存在的，也就代表接口级服务注册，而service-discovery-registry就表示应用级服务注册。   在服务注册相关的源码中，当调用RegistryProtocol的export()方法处理registry://时，会利用ZookeeperRegistry把服务URL注册到Zookeeper中去，这个我们能理解，这就是接口级注册。   而类似，当调用RegistryProtocol的export()方法处理service-discovery-registry://时，会利用ServiceDiscoveryRegistry来进行相关逻辑的处理，那是不是就是在这里把应用信息注册到注册中心去呢？并没有这么简单。

• 注册一个名称为internalCachingMetadataReaderFactory, 类型为SharedMetadataReaderFactoryBean的bean, 用于读取bean的元数据Metadata
• 获取名称为internalConfigurationAnnotationProcessor, 类型为ConfigurationClassPostProcessor的bean定义, 为其添加name为metadataReaderFactory, value为internalCachingMetadataReaderFactory的internalCachingMetadataReaderFactory

protected void prepareRefresh() {
  //记录容器启动时间，然后设立对应的标志位
  this.startupDate = System.currentTimeMillis();
  this.closed.set(false);
  this.active.set(true);

  // 打印info日志：开始刷新this此容器了
  if (logger.isInfoEnabled()) {
   logger.info("Refreshing " + this);
  }

  // Initialize any placeholder property sources in the context environment
  // 这是扩展方法，由子类去实现，可以在验证之前为系统属性设置一些值可以在子类中实现此方法
  // 因为我们这边是AnnotationConfigApplicationContext，可以看到不管父类还是自己，都什么都没做，所以此处先忽略
  initPropertySources();

  // Validate that all properties marked as required are resolvable
  // see ConfigurablePropertyResolver#setRequiredProperties
  //这里有两步，getEnvironment()，然后是是验证是否系统环境中有RequiredProperties参数值 如下详情
  // 然后管理Environment#validateRequiredProperties 后面在讲到环境的时候再专门讲解吧
  // 这里其实就干了一件事，验证是否存在需要的属性
  getEnvironment().validateRequiredProperties();

  // Allow for the collection of early ApplicationEvents,
  // to be published once the multicaster is available...
  // 初始化容器，用于装载早期的一些事件
  this.earlyApplicationEvents = new LinkedHashSet<>();
 }

@Override
 protected final void refreshBeanFactory() throws BeansException {
  // 判断是否已经存在BeanFactory，存在则销毁所有Beans，并且关闭BeanFactory
  // 避免重复加载BeanFactory
  if (hasBeanFactory()) {
   destroyBeans();
   closeBeanFactory();
  }
  try {
   // 创建具体的beanFactory，这里创建的是DefaultListableBeanFactory，最重要的beanFactory spring注册及加载bean就靠它
   // createBeanFactory()这个方法，看下面，还有得说的
   DefaultListableBeanFactory beanFactory = createBeanFactory();
   beanFactory.setSerializationId(getId());
  
   // 这句比较简单，就是把当前旧容器的一些配置值复制给新容器 
   // allowBeanDefinitionOverriding属性是指是否允对一个名字相同但definition不同进行重新注册，默认是true。
   // allowCircularReferences属性是指是否允许Bean之间循环引用，默认是true.
   // 这两个属性值初始值为空：复写此方法即可customizeBeanFactory
   customizeBeanFactory(beanFactory);
   
   // 这个就是最重要的了，加载所有的Bean配置信息，具体如下详细解释
   // 它属于模版方法，由子类去实现加载的方式
   loadBeanDefinitions(beanFactory);
   synchronized (this.beanFactoryMonitor) {
    this.beanFactory = beanFactory;
   }
  }
  catch (IOException ex) {
   throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);
  }
 }

protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
  // 设置beanFactory的classLoader为当前context的classLoader
  beanFactory.setBeanClassLoader(getClassLoader());
  // 设置EL表达式解析器（Bean初始化完成后填充属性时会用到）
  // spring3增加了表达式语言的支持，默认可以使用#{bean.xxx}的形式来调用相关属性值
  beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));
  // 设置属性注册解析器PropertyEditor 这个主要是对bean的属性等设置管理的一个工具
  beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));
  
  // 将当前的ApplicationContext对象交给ApplicationContextAwareProcessor类来处理，从而在Aware接口实现类中的注入applicationContext等等
  // 添加了一个处理aware相关接口的beanPostProcessor扩展，主要是使用beanPostProcessor的postProcessBeforeInitialization()前置处理方法实现aware相关接口的功能
  // 类似的还有ResourceLoaderAware、ServletContextAware等等等等
  beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));
  // 下面是忽略的自动装配（也就是实现了这些接口的Bean，不要Autowired自动装配了）
  // 默认只有BeanFactoryAware被忽略,所以其它的需要自行设置
  // 因为ApplicationContextAwareProcessor把这5个接口的实现工作做了（具体你可参见源码） 所以这里就直接忽略掉
  beanFactory.ignoreDependencyInterface(EnvironmentAware.class);
  beanFactory.ignoreDependencyInterface(EmbeddedValueResolverAware.class);
  beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);
  beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);
  beanFactory.ignoreDependencyInterface(MessageSourceAware.class);
  beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);

  // 设置几个"自动装配"规则======如下：
  // 如果是BeanFactory的类，就注册beanFactory
  //  如果是ResourceLoader、ApplicationEventPublisher、ApplicationContext等等就注入当前对象this(applicationContext对象)
  
  // 此处registerResolvableDependency()方法注意：它会把他们加入到DefaultListableBeanFactory的resolvableDependencies字段里面缓存这，供后面处理依赖注入的时候使用 DefaultListableBeanFactory#resolveDependency处理依赖关系
  // 这也是为什么我们可以通过依赖注入的方式，直接注入这几个对象比如ApplicationContext可以直接依赖注入
  // 但是需要注意的是：这些Bean，Spring的IOC容器里其实是没有的。beanFactory.getBeanDefinitionNames()和beanFactory.getSingletonNames()都是找不到他们的，所以特别需要理解这一点
  // 至于容器中没有，但是我们还是可以@Autowired直接注入的有哪些，请看下图：
  beanFactory.registerResolvableDependency(BeanFactory.class, beanFactory);
  beanFactory.registerResolvableDependency(ResourceLoader.class, this);
  beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, this);
  beanFactory.registerResolvableDependency(ApplicationContext.class, this);

  // 注册这个Bean的后置处理器：在Bean初始化后检查是否实现了ApplicationListener接口
  // 是则加入当前的applicationContext的applicationListeners列表 这样后面广播事件也就方便了
  beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));


  // 检查容器中是否包含名称为loadTimeWeaver的bean，实际上是增加Aspectj的支持
  // AspectJ采用编译期织入、类加载期织入两种方式进行切面的织入
  // 类加载期织入简称为LTW（Load Time Weaving）,通过特殊的类加载器来代理JVM默认的类加载器实现
  if (beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
   // 添加BEAN后置处理器：LoadTimeWeaverAwareProcessor
         // 在BEAN初始化之前检查BEAN是否实现了LoadTimeWeaverAware接口，
         // 如果是，则进行加载时织入，即静态代理。
   beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
   // Set a temporary ClassLoader for type matching.
   beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
  }

  // 注入一些其它信息的bean，比如environment、systemProperties、SystemEnvironment等
  if (!beanFactory.containsLocalBean(ENVIRONMENT_BEAN_NAME)) {
   beanFactory.registerSingleton(ENVIRONMENT_BEAN_NAME, getEnvironment());
  }
  if (!beanFactory.containsLocalBean(SYSTEM_PROPERTIES_BEAN_NAME)) {
   beanFactory.registerSingleton(SYSTEM_PROPERTIES_BEAN_NAME, getEnvironment().getSystemProperties());
  }
  if (!beanFactory.containsLocalBean(SYSTEM_ENVIRONMENT_BEAN_NAME)) {
   beanFactory.registerSingleton(SYSTEM_ENVIRONMENT_BEAN_NAME, getEnvironment().getSystemEnvironment());
  }
 }

public static void invokeBeanFactoryPostProcessors(
   ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {

  // Invoke BeanDefinitionRegistryPostProcessors first, if any.
  // 这个doc说明很清楚：不管怎么样，先执行BeanDefinitionRegistryPostProcessors 
  // 需要注意的是BeanDefinitionRegistryPostProcessors 为 BeanFactoryPostProcessor 的子接口 它新增了方法：void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry)
  // BeanFactoryPostProcessor 的方法为;void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;
  // 所以BeanDefinitionRegistryPostProcessors，它可以我们介入，改变Bean的一些定义信息
  Set<String> processedBeans = new HashSet<>();

  // 只有此beanFactory 是BeanDefinitionRegistry  才能执行BeanDefinitionRegistryPostProcessor，才能修改Bean的定义嘛~
  if (beanFactory instanceof BeanDefinitionRegistry) {
   BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;

   // 此处安放了两个容器，一个装载普通的BeanFactoryPostProcessor
   // 另外一个装载和Bean定义有关的 BeanDefinitionRegistryPostProcessor
   // 另外都是LinkedList，所以执行顺序和set进去的顺序是保持一样的
   List<BeanFactoryPostProcessor> regularPostProcessors = new LinkedList<>();
   List<BeanDefinitionRegistryPostProcessor> registryProcessors = new LinkedList<>();

   // 这里是我们自己的set进去的，若没set，这里就是空(若是Sprng容器里的，下面会处理，见下面)
   // 从此处可以看出，我们手动set进去的，最最最最有限执行的
   for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) {
    if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) {
     BeanDefinitionRegistryPostProcessor registryProcessor =
       (BeanDefinitionRegistryPostProcessor) postProcessor;
     
     // 这里执行post方法，然后然后吧它缓冲起来了，放在了registryProcessors里
     registryProcessor.postProcessBeanDefinitionRegistry(registry);
     registryProcessors.add(registryProcessor);
    }
    else {
     // 缓冲起来常规的处理器
     regularPostProcessors.add(postProcessor);
    }
   }

   // Do not initialize FactoryBeans here: We need to leave all regular beans
   // uninitialized to let the bean factory post-processors apply to them!
   // Separate between BeanDefinitionRegistryPostProcessors that implement
   // PriorityOrdered, Ordered, and the rest.
   // 接下来，就是去执行Spring容器里面的一些PostProcessor了。他们顺序doc里也写得很清楚：
   // 先执行实现了PriorityOrdered接口的，然后是Ordered接口的，最后执行剩下的
   List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>();

   // First, invoke the BeanDefinitionRegistryPostProcessors that implement PriorityOrdered.
   // 先从容器中拿出来所有的BeanDefinitionRegistryPostProcessor 然后先执行PriorityOrdered
   // 本例中有一个这个类型的处理器：ConfigurationClassPostProcessor（显然是处理@Configuration这种Bean的）
   // 至于这个Bean是什么时候注册进去的，前面有。在loadBeanDefinitions()初始化AnnotatedBeanDefinitionReader的时候调用的AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry)方法的时候，注册了6个Bean
   String[] postProcessorNames =
     beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
   for (String ppName : postProcessorNames) {
    if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
     
     // processedBeans也顺带保存了一份，保存的是bean的Name哦~
     currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
     processedBeans.add(ppName);
    }
   }
   // 排序
   sortPostProcessors(currentRegistryProcessors, beanFactory);
   
   // 此处缓冲起来（需要注意的是，是排序后，再放进去的 这样是最好的）
   registryProcessors.addAll(currentRegistryProcessors);

   // 这个方法很简单，就是吧currentRegistryProcessors里面所有的处理器for循环一个个的执行掉(本处只有ConfigurationClassPostProcessor，详见我的另一篇专门博文讲解)
   invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
   // 此处把当前持有的执行对象给清空了，需要注意。以方便装载后续执行的处理器们
   currentRegistryProcessors.clear();

   // Next, invoke the BeanDefinitionRegistryPostProcessors that implement Ordered.
   // 此处逻辑完全同上  处理实现Order接口的RegistryProcessors
   postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
   for (String ppName : postProcessorNames) {
    if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) {
     currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
     processedBeans.add(ppName);
    }
   }
   sortPostProcessors(currentRegistryProcessors, beanFactory);
   registryProcessors.addAll(currentRegistryProcessors);
   invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
   currentRegistryProcessors.clear();

   // Finally, invoke all other BeanDefinitionRegistryPostProcessors until no further ones appear.
   // 最后执行，两个排序接口都没有实现的BeanDefinitionRegistryPostProcessor们，并且也缓存起来
   boolean reiterate = true;
   while (reiterate) {
    reiterate = false;
    postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
    for (String ppName : postProcessorNames) {
     if (!processedBeans.contains(ppName)) {
      currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
      processedBeans.add(ppName);
      reiterate = true;
     }
    }
    sortPostProcessors(currentRegistryProcessors, beanFactory);
    registryProcessors.addAll(currentRegistryProcessors);
    invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
    currentRegistryProcessors.clear();
   }

   // Now, invoke the postProcessBeanFactory callback of all processors handled so far.
   // 现在，这里很明显：去执行BeanDefinitionRegistryPostProcessor的postProcessBeanFactory方法
   // 以及 顶层接口BeanFactoryPostProcessor的postProcessBeanFactory方法
   // 我们当前环境regularPostProcessors长度为0.registryProcessors有一个解析@Configuration的处理器
   invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);
   invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory);
  } else {
   // Invoke factory processors registered with the context instance.
   // 若是普通的Bean工厂，就直接执行set进来的后置处理器即可（因为容器里就没有其它Bean定义了）
   invokeBeanFactoryPostProcessors(beanFactoryPostProcessors, beanFactory);
  }

  // Do not initialize FactoryBeans here: We need to leave all regular beans
  // uninitialized to let the bean factory post-processors apply to them!
  // 下面就是开始执行BeanFactoryPostProcessor 基本也是按照上面的顺序来执行的
  // 上面9个Bean，我们知道 也就ConfigurationClassPostProcessor是实现了此接口的。因此本环境下，只有它了，并且它在上面还已经执行了
  String[] postProcessorNames =
    beanFactory.getBeanNamesForType(BeanFactoryPostProcessor.class, true, false);

  // Separate between BeanFactoryPostProcessors that implement PriorityOrdered,
  // Ordered, and the rest.
  List<BeanFactoryPostProcessor> priorityOrderedPostProcessors = new ArrayList<>();
  List<String> orderedPostProcessorNames = new ArrayList<>();
  List<String> nonOrderedPostProcessorNames = new ArrayList<>();
  for (String ppName : postProcessorNames) {

   // 这里面注意，已经执行过的后置处理器，就不要再执行了
   if (processedBeans.contains(ppName)) {
    // skip - already processed in first phase above
   }
   else if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
    priorityOrderedPostProcessors.add(beanFactory.getBean(ppName, BeanFactoryPostProcessor.class));
   }
   else if (beanFactory.isTypeMatch(ppName, Ordered.class)) {
    orderedPostProcessorNames.add(ppName);
   }
   else {
    nonOrderedPostProcessorNames.add(ppName);
   }
  }

  // First, invoke the BeanFactoryPostProcessors that implement PriorityOrdered.
  sortPostProcessors(priorityOrderedPostProcessors, beanFactory);
  invokeBeanFactoryPostProcessors(priorityOrderedPostProcessors, beanFactory);

  // Next, invoke the BeanFactoryPostProcessors that implement Ordered.
  List<BeanFactoryPostProcessor> orderedPostProcessors = new ArrayList<>();
  for (String postProcessorName : orderedPostProcessorNames) {
   orderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class));
  }
  sortPostProcessors(orderedPostProcessors, beanFactory);
  invokeBeanFactoryPostProcessors(orderedPostProcessors, beanFactory);

  // Finally, invoke all other BeanFactoryPostProcessors.
  List<BeanFactoryPostProcessor> nonOrderedPostProcessors = new ArrayList<>();
  for (String postProcessorName : nonOrderedPostProcessorNames) {
   nonOrderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class));
  }
  invokeBeanFactoryPostProcessors(nonOrderedPostProcessors, beanFactory);

  // Clear cached merged bean definitions since the post-processors might have
  // modified the original metadata, e.g. replacing placeholders in values...
  beanFactory.clearMetadataCache();
 }

// 发现它又是委托给PostProcessorRegistrationDelegate 去做的
 protected void registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory) {
  PostProcessorRegistrationDelegate.registerBeanPostProcessors(beanFactory, this);
 }


 public static void registerBeanPostProcessors(
   ConfigurableListableBeanFactory beanFactory, AbstractApplicationContext applicationContext) {
  
  // 从所与Bean定义中提取出BeanPostProcessor类型的Bean，显然，最初的6个bean，有三个是BeanPostProcessor：
  // AutowiredAnnotationBeanPostProcessor  RequiredAnnotationBeanPostProcessor  CommonAnnotationBeanPostProcessor
  String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanPostProcessor.class, true, false);

  // Register BeanPostProcessorChecker that logs an info message when
  // a bean is created during BeanPostProcessor instantiation, i.e. when
  // a bean is not eligible for getting processed by all BeanPostProcessors.
  // 此处有点意思了，向beanFactory又add了一个BeanPostProcessorChecker，并且此事后总数设置为了getBeanPostProcessorCount和addBeanPostProcessor的总和（+1表示自己）
  int beanProcessorTargetCount = beanFactory.getBeanPostProcessorCount() + 1 + postProcessorNames.length;
  // 此处注意：第一个参数beanPostProcessorTargetCount表示的是处理器的总数，总数（包含两个位置离的，用于后面的校验）
  beanFactory.addBeanPostProcessor(new BeanPostProcessorChecker(beanFactory, beanProcessorTargetCount));

  // Separate between BeanPostProcessors that implement PriorityOrdered,
  // Ordered, and the rest.
  // 同样的 先按优先级，归类了BeanPostProcessor
  List<BeanPostProcessor> priorityOrderedPostProcessors = new ArrayList<>();
  List<BeanPostProcessor> internalPostProcessors = new ArrayList<>();
  List<String> orderedPostProcessorNames = new ArrayList<>();
  List<String> nonOrderedPostProcessorNames = new ArrayList<>();
  for (String ppName : postProcessorNames) {
   if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
    BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
    priorityOrderedPostProcessors.add(pp);
    // MergedBeanDefinitionPostProcessor则是在合并处理Bean定义的时候的回调。这个东东按我的理解也基本是框架内部使用的，用户不用管
    if (pp instanceof MergedBeanDefinitionPostProcessor) {
     internalPostProcessors.add(pp);
    }
   }
   else if (beanFactory.isTypeMatch(ppName, Ordered.class)) {
    orderedPostProcessorNames.add(ppName);
   }
   else {
    nonOrderedPostProcessorNames.add(ppName);
   }
  }

  // First, register the BeanPostProcessors that implement PriorityOrdered.
  sortPostProcessors(priorityOrderedPostProcessors, beanFactory);
  registerBeanPostProcessors(beanFactory, priorityOrderedPostProcessors);

  // Next, register the BeanPostProcessors that implement Ordered.
  List<BeanPostProcessor> orderedPostProcessors = new ArrayList<>();
  for (String ppName : orderedPostProcessorNames) {
   BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
   orderedPostProcessors.add(pp);
   if (pp instanceof MergedBeanDefinitionPostProcessor) {
    internalPostProcessors.add(pp);
   }
  }
  sortPostProcessors(orderedPostProcessors, beanFactory);
  registerBeanPostProcessors(beanFactory, orderedPostProcessors);

  // Now, register all regular BeanPostProcessors.
  List<BeanPostProcessor> nonOrderedPostProcessors = new ArrayList<>();
  for (String ppName : nonOrderedPostProcessorNames) {
   BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
   nonOrderedPostProcessors.add(pp);
   if (pp instanceof MergedBeanDefinitionPostProcessor) {
    internalPostProcessors.add(pp);
   }
  }
  registerBeanPostProcessors(beanFactory, nonOrderedPostProcessors);

  // Finally, re-register all internal BeanPostProcessors.
  sortPostProcessors(internalPostProcessors, beanFactory);
  registerBeanPostProcessors(beanFactory, internalPostProcessors);

  // Re-register post-processor for detecting inner beans as ApplicationListeners,
  // moving it to the end of the processor chain (for picking up proxies etc).
  // 最后此处需要注意的是：Spring还给我们注册了一个Bean的后置处理器：ApplicationListenerDetector  它的作用：用来检查所有得ApplicationListener
  // 有的人就想问了：之前不是注册过了吗，怎么这里又注册一次呢？其实上面的doc里面说得很清楚：
  // Re-register重新注册这个后置处理器。把它移动到处理器连条的最后面，最后执行（小技巧是：先remove，然后执行add操作~~~ 自己可以点进addBeanPostProcessor源码可以看到这个小技巧）
  beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(applicationContext));
 }

 // 把类型是BeanPostProcessor的Bean，注册到beanFactory里面去
 private static void registerBeanPostProcessors(
   ConfigurableListableBeanFactory beanFactory, List<BeanPostProcessor> postProcessors) {

  for (BeanPostProcessor postProcessor : postProcessors) {
   beanFactory.addBeanPostProcessor(postProcessor);
  }
 }

处理autowire

configure 属性

AOP

    //AutowiredAnnotationBeanPostProcessor(处理被@Autowired注解修饰的bean并注入)     //RequiredAnnotationBeanPostProcessor(处理被@Required注解修饰的方法)     //CommonAnnotationBeanPostProcessor(处理@PreDestroy、@PostConstruct、@Resource等多个注解的作用)等。

protected void initMessageSource() {   ConfigurableListableBeanFactory beanFactory = getBeanFactory();   // 判断是否已经存在名为“messageSource”的Bean了（一般情况下，我们都是没有的）   if (beanFactory.containsLocalBean(MESSAGE_SOURCE_BEAN_NAME)) {    // 从容器里拿出这个messageSource     this.messageSource = beanFactory.getBean(MESSAGE_SOURCE_BEAN_NAME, MessageSource.class);    // Make MessageSource aware of parent MessageSource.    // 设置父属性。。。。。。。。。。。。。    if (this.parent != null && this.messageSource instanceof HierarchicalMessageSource) {     HierarchicalMessageSource hms = (HierarchicalMessageSource) this.messageSource;     if (hms.getParentMessageSource() == null) {      // Only set parent context as parent MessageSource if no parent MessageSource      // registered already.      hms.setParentMessageSource(getInternalParentMessageSource());     }    }   }   else {    // Use empty MessageSource to be able to accept getMessage calls.    DelegatingMessageSource dms = new DelegatingMessageSource();    // 其实就是获取到父容器的messageSource字段（否则就是getParent()上下文自己）    dms.setParentMessageSource(getInternalParentMessageSource());    // 给当前的messageSource赋值    this.messageSource = dms;    // 把messageSource作为一个单例的Bean注册进beanFactory工厂里面    beanFactory.registerSingleton(MESSAGE_SOURCE_BEAN_NAME, this.messageSource);   }  } ———————————————— 版权声明：本文为CSDN博主「YourBatman」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/f641385712/article/details/88118288

protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {
  // Initialize conversion service for this context.
  // 初始化上下文的转换服务，ConversionService是一个类型转换接口
  if (beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) && beanFactory.isTypeMatch(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class)) {
   beanFactory.setConversionService( beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));
  }

  // Register a default embedded value resolver if no bean post-processor
  // (such as a PropertyPlaceholderConfigurer bean) registered any before:
  // at this point, primarily for resolution in annotation attribute values.
  // 设置一个内置的值处理器（若没有的话），该处理器作用有点像一个PropertyPlaceholderConfigurer bean
  if (!beanFactory.hasEmbeddedValueResolver()) {
   beanFactory.addEmbeddedValueResolver(strVal -> getEnvironment().resolvePlaceholders(strVal));
  }

  // Initialize LoadTimeWeaverAware beans early to allow for registering their transformers early.
  // 注意此处已经调用了getBean方法，初始化LoadTimeWeaverAware Bean
  // getBean()方法的详细，下面会详细分解
  // LoadTimeWeaverAware是类加载时织入的意思
  String[] weaverAwareNames = beanFactory.getBeanNamesForType(LoadTimeWeaverAware.class, false, false);
  for (String weaverAwareName : weaverAwareNames) {
   getBean(weaverAwareName);
  }

  // Stop using the temporary ClassLoader for type matching.
  // 停止使用临时的类加载器
  beanFactory.setTempClassLoader(null);

  // Allow for caching all bean definition metadata, not expecting further changes.
  // 缓存（冻结）所有的bean definition数据，不期望以后会改变
  beanFactory.freezeConfiguration();

  // Instantiate all remaining (non-lazy-init) singletons.
  // 这个就是最重要的方法：会把留下来的Bean们  不是lazy懒加载的bean都实例化掉
  //  bean真正实例化的时刻到了
  beanFactory.preInstantiateSingletons();
 }

源码

实例化bean

protected void finishRefresh() {
  // Clear context-level resource caches (such as ASM metadata from scanning).
  // 这个是Spring5.0之后才有的方法
  // 表示清除一些resourceCaches,如doc说的  清楚context级别的资源缓存，比如ASM的元数据
  clearResourceCaches();

  // Initialize lifecycle processor for this context.
  // 初始化所有的LifecycleProcessor  详见下面
  initLifecycleProcessor();

  // Propagate refresh to lifecycle processor first.
  // 上面注册好的处理器，这里就拿出来，调用它的onRefresh方法了
  getLifecycleProcessor().onRefresh();

  // Publish the final event.
  // 发布容器刷新的事件：
  publishEvent(new ContextRefreshedEvent(this));

  // Participate in LiveBeansView MBean, if active.
  // 和MBeanServer和MBean有关的。相当于把当前容器上下文，注册到MBeanServer里面去。
  // 这样子，MBeanServer持久了容器的引用，就可以拿到容器的所有内容了，也就让Spring支持到了MBean的相关功能
  LiveBeansView.registerApplicationContext(this);
 }

当ApplicationContext启动或停止时，它会通过LifecycleProcessor来与所有声明的bean的周期做状态更新，而在LifecycleProcessor的使用前首先需要初始化

@Slf4j
public class NacosRandomWithWeightRule extends AbstractLoadBalancerRule {

    @Autowired
    private NacosDiscoveryProperties nacosDiscoveryProperties;

    @Override
    public Server choose(Object key) {
        DynamicServerListLoadBalancer loadBalancer = (DynamicServerListLoadBalancer) getLoadBalancer();
        String serviceName = loadBalancer.getName();
        NamingService namingService = nacosDiscoveryProperties.namingServiceInstance();
        try {
            //nacos基于权重的算法
            Instance instance = namingService.selectOneHealthyInstance(serviceName);
            return new NacosServer(instance);
        } catch (NacosException e) {
            log.error("获取服务实例异常：{}", e.getMessage());
            e.printStackTrace();
        }
        return null;
    }
    @Override
    public void initWithNiwsConfig(IClientConfig clientConfig) {

    }

2.1）全局配置

2.2）局部配置：

饥饿加载

@GetMapping("/rules")
    @AuthAction(PrivilegeType.READ_RULE)
    public Result<List<FlowRuleEntity>> apiQueryMachineRules(@RequestParam String app,
                                                             @RequestParam String ip,
                                                             @RequestParam Integer port) {

        if (StringUtil.isEmpty(app)) {
            return Result.ofFail(-1, "app can't be null or empty");
        }
        if (StringUtil.isEmpty(ip)) {
            return Result.ofFail(-1, "ip can't be null or empty");
        }
        if (port == null) {
            return Result.ofFail(-1, "port can't be null");
        }
        try {
           // List<FlowRuleEntity> rules = sentinelApiClient.fetchFlowRuleOfMachine(app, ip, port);
            //从配置中心获取规则配置
            List<FlowRuleEntity> rules = ruleProvider.getRules(app, ip, port);
            rules = repository.saveAll(rules);
            return Result.ofSuccess(rules);
        } catch (Throwable throwable) {
            logger.error("Error when querying flow rules", throwable);
            return Result.ofThrowable(-1, throwable);
        }
    }

@PostMapping("/rule")     @AuthAction(PrivilegeType.WRITE_RULE)     public Result<FlowRuleEntity> apiAddFlowRule(@RequestBody FlowRuleEntity entity) {         Result<FlowRuleEntity> checkResult = checkEntityInternal(entity);         if (checkResult != null) {             return checkResult;         }         entity.setId(null);         Date date = new Date();         entity.setGmtCreate(date);         entity.setGmtModified(date);         entity.setLimitApp(entity.getLimitApp().trim());         entity.setResource(entity.getResource().trim());         try {             entity = repository.save(entity);             //publishRules(entity.getApp(), entity.getIp(), entity.getPort()).get(5000, TimeUnit.MILLISECONDS);             //发布规则到配置中心             publishRules(entity.getApp());             return Result.ofSuccess(entity);         } catch (Throwable t) {             Throwable e = t instanceof ExecutionException ? t.getCause() : t;             logger.error("Failed to add new flow rule, app={}, ip={}", entity.getApp(), entity.getIp(), e);             return Result.ofFail(-1, e.getMessage());         }     } /**      * 发布到配置中心      * @param app      * @throws Exception      */     private void publishRules(/*@NonNull*/ String app) throws Exception {         List<FlowRuleEntity> rules = repository.findAllByApp(app);         rulePublisher.publish(app, rules);     }

参见源码：com.alibaba.csp.sentinel.datasource.AbstractDataSource#loadConfig(S) 会解析配置规则。
原因是：改造dashboard，提交到nacos配置中心的数据是ParamFlowRuleEntity类型，微服务拉取配置要解析的是ParamFlowRule类型，会导致规则解析丢失数据，造成热点规则不生效。 其他的规则原理也是一样，存在失效的风险。

[{  "app": "mall-user-sentinel-rule-push-demo",  "gmtCreate": 1616136838785,  "gmtModified": 1616136838785,  "id": 1,  "ip": "192.168.3.1",  "port": 8719,  "rule": {   "burstCount": 0,   "clusterConfig": {    "fallbackToLocalWhenFail": true,    "sampleCount": 10,    "thresholdType": 0,    "windowIntervalMs": 1000   },   "clusterMode": false,   "controlBehavior": 0,   "count": 1.0,   "durationInSec": 1,   "grade": 1,   "limitApp": "default",   "maxQueueingTimeMs": 0,   "paramFlowItemList": [],   "paramIdx": 1,   "resource": "hot"  } }, {  "app": "mall-user-sentinel-rule-push-demo",  "gmtCreate": 1616137178470,  "gmtModified": 1616658923519,  "id": 2,  "ip": "192.168.3.1",  "port": 8719,  "rule": {   "burstCount": 0,   "clusterConfig": {    "fallbackToLocalWhenFail": true,    "sampleCount": 10,    "thresholdType": 0,    "windowIntervalMs": 1000   },   "clusterMode": false,   "controlBehavior": 0,   "count": 3.0,   "durationInSec": 1,   "grade": 1,   "limitApp": "default",   "maxQueueingTimeMs": 0,   "paramFlowItemList": [{    "classType": "int",    "count": 1,    "object": "4"   }],   "paramIdx": 0,   "resource": "findOrderByUserId"  } }]

自定义一个解析热点规则配置的解析器FlowParamJsonConverter，继承JsonConverter，重写convert方法。然后利用后置处理器替换beanName为"param-flow-rules-sentinel-nacos-datasource"的converter属性，注入FlowParamJsonConverter。

2. 改造Sentinel Dashboard控制台，发布配置时将ParamFlowRuleEntity转成ParamFlowRule类型，再发布到Nacos配置中心。从配置中心拉取配置后将ParamFlowRule转成ParamFlowRuleEntity。

1. 首先应用程序（客户端）中配置了事务分组（GlobalTransactionScanner 构造方法的txServiceGroup参数）。若应用程序是SpringBoot则通过seata.tx-service-group 配置。
2. 应用程序（客户端）会通过用户配置的配置中心去寻找service.vgroupMapping .[事务分组配置项]，取得配置项的值就是TC集群的名称。若应用程序是SpringBoot则通过seata.service.vgroup-mapping.事务分组名=集群名称 配置
3. 拿到集群名称程序通过一定的前后缀+集群名称去构造服务名，各配置中心的服务名实现不同（前提是Seata-Server已经完成服务注册，且Seata-Server向注册中心报告cluster名与应用程序（客户端）配置的集群名称一致）
4. 拿到服务名去相应的注册中心去拉取相应服务名的服务列表，获得后端真实的TC服务列表（即Seata-Server集群节点列表）