《SpringBoot揭秘:快速构建微服务体系》—第2章2.3节 了解一点儿JavaConfig

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 本节书摘来自华章出版社《SpringBoot揭秘:快速构建微服务体系》一书中的第2章,第2.2节了解一点儿JavaConfig,作者王福强,更多章节内容可以访问云栖社区“华章计算机”公众号查看。 2.3 了解一点儿JavaConfig Java 5的推出,加上当年基于纯Java Annotation的依赖注入框架Guice的出现,使得Spring框架及其社区也“顺应民意”,推出并持续完善了基于Java代码和Annotation元信息的依赖关系绑定描述方式,即JavaConfig项目。

本节书摘来自华章出版社《SpringBoot揭秘:快速构建微服务体系》一书中的第2章,第2.2节了解一点儿JavaConfig,作者王福强,更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.3 了解一点儿JavaConfig
Java 5的推出,加上当年基于纯Java Annotation的依赖注入框架Guice的出现,使得Spring框架及其社区也“顺应民意”,推出并持续完善了基于Java代码和Annotation元信息的依赖关系绑定描述方式,即JavaConfig项目。
基于JavaConfig方式的依赖关系绑定描述基本上映射了最早的基于XML的配置方式,比如:
(1)表达形式层面
基于XML的配置方式是这样的:


08f73fff8c5914b2d838d3bc29a27148734e2578


7de69f0a7bf46912dea33b712c9680f75a93d6d4
<!-- bean定义 -->


而基于JavaConfig的配置方式是这样的:
@Configuration
public class MockConfiguration{

// bean定义

}
任何一个标注了@Configuration的Java类定义都是一个JavaConfig配置类。
(2)注册bean定义层面
基于XML的配置形式是这样的:

...


而基于JavaConfig的配置形式是这样的:

@Configuration
public class MockConfiguration {
    @Bean
    public MockService mockService() {
        return new MockServiceImpl();
    }
}

任何一个标注了@Bean的方法,其返回值将作为一个bean定义注册到Spring的IoC容器,方法名将默认成为该bean定义的id。
(3)表达依赖注入关系层面
为了表达bean与bean之间的依赖关系,在XML形式中一般是这样的:

<bean id="mockService" class="..MockServiceImpl">
    <property name="dependencyService" ref="dependencyService"/>
</bean>


而在JavaConfig中则是这样的:

@Configuration
public class MockConfiguration {

    @Bean
    public MockService mockService() {
        return new MockServiceImpl(dependencyService());
    }

    @Bean
    public DependencyService dependencyService() {
        return new DependencyServiceImpl();
    }
}

如果一个bean的定义依赖其他bean,则直接调用对应JavaConfig类中依赖bean的创建方法就可以了。
在JavaConfig形式的依赖注入过程中,我们使用方法调用的形式注入依赖,如果这个方法返回的对象实例只被一个bean依赖注入,那也还好,如果多于一个bean需要依赖这个方法调用返回的对象实例,那是不是意味着我们就会创建多个同一类型的对象实例?
从代码表述的逻辑来看,直觉上应该是会创建多个同一类型的对象实例,但实际上最终结果却不是这样,依赖注入的都是同一个Singleton的对象实例,那这是如何做到的?
笔者一开始以为Spring框架会通过解析JavaConfig的代码结构,然后通过解析器转换加上反射等方式完成这一目的,但实际上Spring框架的设计和实现者采用了另一种更通用的方式,这在Spring的参考文档中有说明,即通过拦截配置类的方法调用来避免多次初始化同一类型对象的问题,一旦拥有拦截逻辑的子类发现当前方法没有对应的类型实例时才会去请求父类的同一方法来初始化对象实例,否则直接返回之前的对象实例。
所以,原来Spring IoC容器中有的特性(features)在JavaConfig中都可以表述,只是换了一种形式而已,而且,通过声明相应的Java Annotation反而“内聚”一处,变得更加简洁明了了。
2.3.1 那些高曝光率的Annotation
至于@Configuration,我想前面已经提及过了,这里不再赘述,下面我们看几个其他比较常见的Annotation,便于为后面更好地理解SpringBoot框架的奥秘做准备。

  1. @ComponentScan
    @ComponentScan对应XML配置形式中的元素,用于配合一些元信息Java Annotation,比如@Component和@Repository等,将标注了这些元信息Annotation的bean定义类批量采集到Spring的IoC容器中。

我们可以通过basePackages等属性来细粒度地定制@ComponentScan自动扫描的范围,如果不指定,则默认Spring框架实现会从声明@ComponentScan所在类的package进行扫描。
@ComponentScan是SpringBoot框架魔法得以实现的一个关键组件,大家可以重点关注,我们后面还会遇到它。

  1. @PropertySource与@PropertySources
    @PropertySource用于从某些地方加载*.properties文件内容,并将其中的属性加载到IoC容器中,便于填充一些bean定义属性的占位符(placeholder),当然,这需要PropertySourcesPlaceholderConfigurer的配合。

如果我们使用Java 8或者更高版本开发(本书写作期间Java 9还没发布),那么,我们可以并行声明多个@PropertySource:

@Configuration
@PropertySource("classpath:1.properties")
@PropertySource("classpath:2.properties")
@PropertySource("...")
public class XConfiguration{
    ...
}

如果我们使用低于Java 8版本的Java开发Spring应用,又想声明多个@PropertySource,则需要借助@PropertySources的帮助了:

@PropertySources({
        @PropertySource("classpath:1.properties"),
        @PropertySource("classpath:2.properties"),
        ...
})
public class XConfiguration{
    ...
}
}
  1. @Import与@ImportResource
    在XML形式的配置中,我们通过的形式将多个分开的容器配置合到一个配置中,在JavaConfig形式的配置中,我们则使用@Import这个Annotation完成同样目的:
@Configuration
@Import(MockConfiguration.class)
public class XConfiguration {
    ...
}

@Import只负责引入JavaConfig形式定义的IoC容器配置,如果有一些遗留的配置或者遗留系统需要以XML形式来配置(比如dubbo框架),我们依然可以通过@ImportResource将它们一起合并到当前JavaConfig配置的容器中:

@Configuration
@Import(MockConfiguration.class)
@ImportResource("...")
public class XConfiguration {
相关文章
|
6天前
|
敏捷开发 监控 数据管理
构建高效微服务架构的五大关键策略
【4月更文挑战第20天】在当今软件开发领域,微服务架构已经成为一种流行的设计模式,它允许开发团队以灵活、可扩展的方式构建应用程序。本文将探讨构建高效微服务架构的五大关键策略,包括服务划分、通信机制、数据管理、安全性考虑以及监控与日志。这些策略对于确保系统的可靠性、可维护性和性能至关重要。
|
7天前
|
Java API 微服务
【Spring Boot系列】通过OpenAPI规范构建微服务服务接口
【4月更文挑战第5天】通过OpenAPI接口构建Spring Boot服务RestAPI接口
|
6天前
|
消息中间件 监控 持续交付
构建高效微服务架构:后端开发的进阶之路
【4月更文挑战第20天】 随着现代软件开发的复杂性日益增加,传统的单体应用已难以满足快速迭代和灵活部署的需求。微服务架构作为一种新兴的分布式系统设计方式,以其独立部署、易于扩展和维护的特点,成为解决这一问题的关键。本文将深入探讨微服务的核心概念、设计原则以及在后端开发实践中如何构建一个高效的微服务架构。我们将从服务划分、通信机制、数据一致性、服务发现与注册等方面入手,提供一系列实用的策略和建议,帮助开发者优化后端系统的性能和可维护性。
|
4天前
|
存储 Java 时序数据库
【SpringBoot系列】微服务监测(常用指标及自定义指标)
【4月更文挑战第6天】SpringBoot微服务的监测指标及自定义指标讲解
|
1天前
|
消息中间件 负载均衡 持续交付
构建高效微服务架构:后端开发者的终极指南
【4月更文挑战第25天】在当今软件工程领域,微服务架构已经成为实现可扩展、灵活且容错的系统的首选模式。本文将探讨如何从零开始构建一个高效的微服务系统,涵盖关键组件的选择、通信机制、数据管理以及持续集成和部署策略。通过深入分析与案例研究,我们旨在为后端开发者提供一个全面的微服务实践指南,帮助他们在构建现代化应用时做出明智的架构决策。
|
1天前
|
机器学习/深度学习 负载均衡 Java
【SpringBoot系列】微服务远程调用Open Feign深度学习
【4月更文挑战第9天】微服务远程调度open Feign 框架学习
|
1天前
|
消息中间件 持续交付 数据库
构建高效可靠的微服务架构:策略与实践
【4月更文挑战第25天】 随着现代软件开发的复杂性日益增加,传统的单体应用已难以满足快速迭代和灵活部署的需求。本文深入探讨了如何构建一个高效且可靠的微服务架构,包括关键的设计原则、技术选型以及实践中的挑战和应对策略。通过分析多个成功案例,我们总结了一系列最佳实践,并提出了一套可量化的性能优化方法。文章不仅为开发者提供了具体的技术指导,同时也强调了团队协作和持续学习在微服务转型过程中的重要性。
|
2天前
|
持续交付 API 开发者
构建高效微服务架构:后端开发的新范式
【4月更文挑战第24天】 随着现代软件系统的复杂性日益增加,传统的单体应用已难以满足快速迭代与灵活扩展的需求。微服务架构作为一种新兴的软件开发模式,以其服务的细粒度、独立部署和弹性伸缩等优势,正在逐渐成为后端开发的重要趋势。本文将深入探讨微服务架构的设计原则、关键技术以及在实际业务中的应用实践,旨在为后端开发者提供构建和维护高效微服务架构的参考指南。
|
3天前
|
Java 关系型数据库 数据库
【SpringBoot系列】微服务集成Flyway
【4月更文挑战第7天】SpringBoot微服务集成Flyway
【SpringBoot系列】微服务集成Flyway
|
4天前
|
监控 API 持续交付
构建高效微服务架构:后端开发的新趋势
【4月更文挑战第23天】 随着现代软件开发实践的不断演进,微服务架构已经成为企业追求敏捷、可扩展和弹性解决方案的首选。本文深入探讨了如何构建一个高效的微服务架构,涵盖了关键的设计原则、技术选型以及实践建议。通过分析微服务的独立性、分布式特性和容错机制,我们将揭示如何利用容器化、服务网格和API网关等技术手段,来优化后端系统的可维护性和性能。文章旨在为后端开发人员提供一套全面的指南,以应对不断变化的业务需求和技术挑战。