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

本节书摘来自华章出版社《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的配置方式是这样的：

 !-- 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" 

 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框架的奥秘做准备。

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

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

@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{

}

@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 {

使用 JHipster 构建微服务架构 在本文中，我们将着眼于代码生成工具 JHipster 生成和支持的微服务架构。 JHipster 是一个代码生成工具，可以为 Kubernetes 创建 Web 应用程序、微服务、部署文件、云集成和 CI/CD Jenkins 文件。这个工具对于可以快速生成代码并避免创建样板代码的开发人员非常有帮助，可以节省 30% 的工作量。 JHipster 支持 Spring Boot 中的后端代码和 Angular/React/Vue.js 中的前端代码。 在本文中，我们将研究 JHipster 生成和支持的微服务架构。
SpringCloud学习（十二）：Hystrix支付微服务构建 Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
Kratos微服务工程Bazel构建指南 Kratos是一个微服务框架，既然是微服务，那么一个工程下肯定会存在不少的服务，一个服务就是一个二进制可执行程序，那么我们将会面对一个问题：如何去构建（Build）这些服务程序。这件事情，通常都交由构建系统去做。我们能够选择的构建系统有很多：Make、CMake、Bazel……那么，我们又该如何选择一个构建系统呢？