本系列为之前系列的整理重启版,随着项目的发展以及项目中的使用,之前系列里面很多东西发生了变化,并且还有一些东西之前系列并没有提到,所以重启这个系列重新整理下,欢迎各位留言交流,谢谢!~
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。源码是:
我们这一节详细分析了 Spring Cloud 的基础 NamedContextFactory,搞清楚了其中的原理,并且举了一个简单的例子。接下来我们会详细分析下如何使用以及分析改造一个 Spring Cloud 组件。