SpringCloud升级之路2020.0.x版-8.理解 NamedContextFactory

本系列为之前系列的整理重启版，随着项目的发展以及项目中的使用，之前系列里面很多东西发生了变化，并且还有一些东西之前系列并没有提到，所以重启这个系列重新整理下，欢迎各位留言交流，谢谢！~

spring-cloud-commons 中参考了 spring-cloud-netflix 的设计，引入了 NamedContextFactory 机制，一般用于对于不同微服务的客户端模块使用不同的 子 ApplicationContext 进行配置。

spring-cloud-commons 是 Spring Cloud 对于微服务基础组件的抽象。在一个微服务中，调用微服务 A 与调用微服务 B 的配置可能不同。比较简单的例子就是，A 微服务是一个简单的用户订单查询服务，接口返回速度很快，B 是一个报表微服务，接口返回速度比较慢。这样的话我们就不能对于调用微服务 A 和微服务 B 使用相同的超时时间配置。还有就是，我们可能对于服务 A 通过注册中心进行发现，对于服务 B 则是通过 DNS 解析进行服务发现，所以对于不同的微服务我们可能使用不同的组件，在 Spring 中就是使用不同类型的 Bean。

在这种需求下，不同微服务的客户端有不同的以及相同的配置，有不同的 Bean，也有相同的 Bean。所以，我们可以针对每一个微服务将他们的 Bean 所处于 ApplicationContext 独立开来，不同微服务客户端使用不同的 ApplicationContext。NamedContextFactory 就是用来实现这种机制的。

编写源码：

结果输出为：

代码中实现了这样一个 Context 结构：

图中的被包含的 ApplicationContext 可以看到外层 ApplicationContext 的 Bean，也就是通过对被包含的 ApplicationContext 调用 getBean(xxx) 可以获取到外层 ApplicationContext 的 Bean （其实外层就是 parent ApplicationContext），但是外层的看不到内层私有的 Bean。

在我们的测试代码中，首先，创建了一个 AnnotationConfigApplicationContext。这个其实就是模拟了我们平常使用 Spring 框架的时候的根核心 ApplicationContext，所以我们将其命名为 parent。我们向里面注册了 BaseConfig，BaseConfig 里面的 BaseBean 会注册到 parent。之后我们 建 testClient1，默认配置使用 ClientCommonConfig。如果我们指定了 testClient1 的 parent ApplicationContext 为 parent，那么 parent 里面的 Bean 都能被 testClient1 里面的子 ApplicationContext 访问到。然后，我们创建 service1 与 service2 以及指定对应额外的配置类。service1 会创建 ClientCommonConfig、Service1Config1 和 Service1Config2 里面配置的 Bean。service2 会创建 ClientCommonConfig 和 Service2Config 里面配置的 Bean。

NamedContextFactory 的核心方法是 public <T> T getInstance(String name, Class<T> type)，通过这个方法获取 NamedContextFactory 里面的子 ApplicationContext 里面的 Bean。源码是：

NamedContextFactory.java

我们这一节详细分析了 Spring Cloud 的基础 NamedContextFactory，搞清楚了其中的原理，并且举了一个简单的例子。接下来我们会详细分析下如何使用以及分析改造一个 Spring Cloud 组件。