二、何为Spring Boot整合Spring Cloud?

题语:学习方法之多思考:正向、逆向、跳跃
作者:A哥(YourBatman)
wx号:fsx641385712(备注“Java群”字样)
公众号:BAT的乌托邦(ID:BAT-utopia)

代码下载地址:https://github.com/f641385712/netflix-learning

前言

各位小伙伴大家好,我是A哥。通过上文 为何我决定写Spring Cloud专栏 一方面了解了A哥的“创作背景”;另一方面,当然也是最主要的便是我们已经初步了解了Spring Cloud Context工程,并且对它的spring.factories文件做了介绍,从中是能窥探出SC的核心组成“元素”的。

天若有情天亦老,人间正道是沧桑。接下来会进入到“枯燥乏味”的修行当中,坚持下来的都是英雄。准备深入去了解Spring Cloud,BootstrapApplicationListener无疑是它的第一入口,然而在这之前,我们依旧需要扫除一些“障碍”。

学习去...


正文

关于Spring Boot整合,请看我在度娘上的搜索推荐结果:

在这里插入图片描述


Spring Boot整合Spring Cloud

众所周知,Spring Cloud是构建在一个Spring Boot应用的基础之上的,广义上说可以认为是SB应用把Spring Cloud整合进来了。谈到技术整合相信各位小伙伴轻车熟路:Redis整合、ElasticSearch整合、MyBatis整合…Spring Cloud的整合方式有点不太一样。SC它并非作为一个组件那么直接的加入到Spring Boot的ApplicationContext上下文/容器里即可,而是拥有自己一套独立的ApplicationContext上下文,然后通过上下文之间的关系(父子关系)完成和Spring Boot的“整合”。

如果说Mybatis、Redis这种整合方式是单个、直接方式;那么Spirng Cloud这种便是批量的、间接的方式,而正因为Spring Cloud有自己的Context上下文,所以它自己也就拥有整合其它组件的能力,这是非常重要的。

其实把Eureka、Hystrix、Ribbon等和Spring Boot直接整合也是可行的,但是这并不符合SB单应用的定位,并且Spring Framework和Spring Boot团队并不擅长解决和网络、云计算相关的技术,因此专门开设Spring Cloud子项目负责“接管”,保证了Spring Boot的纯粹性


概念辨析

在正式开始Spring Cloud内容学习之前,我觉得有几个概念性的知识点需要先辨析一下,这个工作很有必要。


应用 vs 上下文 vs 容器

作为一个Java coder,这三个概念应该是常绕耳边的。不可否认,这三个概念非常重要,它亦会在本系列文章中贯穿始终,因为它就是用来沟通的“语言”嘛。但是,常常听见并不代表真的理解,特别这种“近义词”,本处就对这几个概念作出辨析。

以个人理解作出的小总结,若有误请留言指正,A哥一直都是个虚心向任何人学习的好孩纸


应用Application

应用是个比较大概念,比如一个QQ、微信我们均可称为是一个应用,而此处我们一般指的是Spring应用。比如我们一个Spring Boot工程就是一个SpringApplication实例,也就是一个Spring应用,另外它也称为主应用,一个工程主应用只会有一个

通常来讲,一个应用只有一个上下文,所以应用和上下文这两个概念常常被误以为是对等的,其实非也,他俩并非同一层面的东东。举个例子:以Spring Boot为例,有些监听器注册在SpringApplication应用上作用于监听应用的变化(如生命周期监听器、初始化器等),它们并没有放进Spring容器内所以对上下文无感;而有些监听器是被放进容器里的,它的作用区域便就是和容器、Bean相关喽

另外,需要知道的是SB和SC的context上下文均是通过SpringApplication来构建的,但该SpringApplication实例在构建出Context后一般随即就“消失了”,这也是很多小伙伴误认为应用 == 上下文的原因之一吧;另外,父子容器概念属于context上下文级别非应用级别


上下文Context

同理,我们一般指的是Spring上下文,也就是ApplicationContext。在SB/SC里,实际使用的是ConfigurableApplicationContext的子类:AnnotationConfigServletWebServerApplicationContextAnnotationConfigApplicationContext(前者由Spring Boot提供,后者由Spring Framework提供)。ApplicationContext是具有层级关系(父子关系)的,ApplicationContext#getParent()证明了这一点。

ApplicationContext上下文里的内容非常“丰富”,如Environment环境、BeanFactory工厂、协议解析器等等它都有,毕竟具备这些能力才算一个“合格的”上下文嘛。另外针对于在SC环境下的上下文情况需要有如下共识:

  • SB和SC各自拥有一个独立的上下文,它们之前互相隔离却又有联系:SC上下文是SB的父上下文

容器

容器这个概念就更抽象了,在Java界也有不少如web容器、servlet容器等等,但是大多数情况下(包括本系列文章)我们一般指的是IoC容器,也就是Spring容器。

说明:IoC容器的实现其实不仅仅只有Spring,还有也比较流行的Google的开源库Guice,也是个非常好用轻量级DI管理库,有一些第三方开源组件如Eureka、Ribbon、Druid等都是基于它构建的,有兴趣可自己玩玩,也可参考我文章有写到~

对于Spring容器,我们有时候也叫它Bean工厂,也即是BeanFactory嘛。实际上ApplicationContext继承了BeanFactory接口,所以也是个容器(高级别容器),因此在概念上:上下文和容器这两个概念一般是可以对等的

  • 槽点:Spring的Bean容器为毛命名为BeanFactory而不是BeanContainer呢?

对于一个应用(如SB应用),ApplicationContext上下文/容器是可以有多个的。上下文之间的“隔离性”是很好的,后面会看到Ribbon、Feign等它们均会有自己的上下文,也就是学SC一样,通过上下文级别间接的完成和Spring Boot应用的整合。

那么问题来了:何时直接整合?何时需要自己创建一个上下文来管理呢?该问题就作为课后作业,留给读者你自行思考哈~


父容器 vs 子容器

父子关系是一种分层思想,被广泛应用于Spring容器/上下文的组织中,如HierarchicalBeanFactoryApplicationContext#getParent()能证明Spring的上下文也是具有层级结构的。

同义词:父上下文、子上下文。但是切记不可说成父应用和子应用,因为一个Spring Boot工程只会有一个应用,而一个应用内可以有N多个上下文,它们之间可以有关,亦可无关,这是合理的。


Environment环境

一般我喜欢叫它Spring的环境抽象,该“实例”代表着上下文的运行环境,主要包含如下三部分内容:

  1. PropertySource:属性源。key-value属性对抽象。环境内会有多个属性源,使用MutablePropertySources来组织
  2. PropertyResolver:属性解析器。用于解析相应key的value,比如你熟悉的PropertySourcesPropertyResolver就是实现
  3. Profile:配置(资料里翻译为剖面、侧面,也是阔仪的)。只有激活的配置profile的组件/配置才会注册到Spring容器,类似于maven中profile

Environment抽象Spring一共提供了三个实现类:

  • 用于非web环境的:StandardEnvironment
  • 用于web环境的:StandardServletEnvironmentStandardReactiveWebEnvironment,他俩均为StandardEnvironment的子类。
    • 需要注意的是:后者StandardReactiveWebEnvironment由Spring Boot提供,而非Spring Framework源生

这里小带一句:很多同学把属性和配置傻傻分不清楚,其实他俩就是Properties(k-v)和Profile概念上的差异,但口头上经常混用,一般可认为讲的是同一回事,但是你心里必须清楚哈。毕竟和专业人士聊起来的时候,还是需要这些细节掌握的

尴尬爆料:今天猛然发现,之前好多文章里我把Environment单词写错了,写为了Enviroment,特此提醒各位不要“学我”哦


属性源

Spring通过Environment建模Spring应用运行的环境,这其中最为重要的非属性源莫属。一个属性源就是一个PropertySource,它可以来自任意地方,如常用的有:

  • systemProperties -> 来自 system.getProperties()
  • systemEnvironment -> system.getenv()
  • random -> 来自一个Random对象,可用于生成随机数(SB提供)
  • applicationConfig: [classpath:/application.yaml] -> SB主配置,这个太常见了吧

属性源的优先级决定了配置的优先级。Spring Boot对其外部化配置优先级有文档说明:Spring Boot外部化配置


我该如何记忆Spring Boot属性优先级?

答案:不要记。精确答案:不要强记,因为“记不住”的。我见过不少(非常多)小伙伴一遇到需要考虑Spring Boot属性优先级问题时,整头就大了,立马拿出自己的小本本,又或者去度娘里查,或许那会还在内心里骂自己:怎么老是记不住呢?甚至质疑自己:是不是真的老了?

我说的此现象,你是否躺枪?授之以鱼不如授之以渔,对于这种“高难度、易出错”的知识点,浮于表面总觉浅,掌握其本质才是永恒。当然我这里不会去详讲Spring Boot这块的知识点,但我还是呕心沥血的整理出一堆截图,告诉你为何你强行记忆是记不住的(如果你是“天才”你就可以跳过本文了):


附:Spring Boot所有版本外部化配置一览

Spring Boot从它的1.0.x版本到现在的2.2.x版本,对于外部化配置的支持几乎是一直在变化/增加的,这种不确定性也无疑在一定程度上增加了我们记忆的难度。下面我从其官方文档截图出了它所有版本(请忽略小版本号)对应的支持的外部化配置情况:

说明:以下所有截图都来自Spring Boot官方文档的外部化配置Externalized Configuration部分,优先级从高到低

1.0.0.RELEASE(7个):

在这里插入图片描述
1.1.0.RELEASE(9个):@PropertySource优先级有调整,增加了JNDI和random属性源支持
在这里插入图片描述
1.2.0.RELEASE(9个):

在这里插入图片描述
1.3.0.RELEASE(12个):增加了JSON格式配置、支持-{profile}.xxx格式的配置

在这里插入图片描述
1.4.0.RELEASE(15个):增加了@TestPropertySource支持、ServletConfig和ServletContext属性源的支持

在这里插入图片描述
1.5.0.RELEASE(17个):增加了对调试工具@Devtools配置的支持、@SpringBootTest#properties的支持

在这里插入图片描述
2.0.0.RELEASE(17个):

在这里插入图片描述

2.1.0.RELEASE(17个):

在这里插入图片描述

2.2.0.RELEASE(17个):从2.2.0版本后,官方文档采用H5来重写了,所以页面风格整体上有所改变(更高级些了有木有)

在这里插入图片描述

此处对@PropertySource属性源增加了文字解释:它在refresh()容器之前,该属性源是不会放进Environment里面的,也就是说在容器启动之前请不要使用它里面的k-v,这在日常使用请你务必注意~

从这能看出Spring Boot对外部化配置发展的脉络。即使从1.5.0版本后,外部化配置趋于稳定,但谁知道以后呢?对吧~况且,17个耶,你真记得住?最为致命的是:如果你的工程接入配置中心来获取配置,又或者你二次开发自定位你配置的位置,它们都还不在这17个行列里,那肿么办?怎么判断属性优先级呢?所以嘛,像这种case,不要强记,不要强记,不要强记。


application.yaml vs bootstrap.yaml

对于它俩的比较理应放在最后,但这里先睹为快。

  • application.yaml/properties被Spring Boot容器读取,也常常被我们称为主配置
  • bootstrap.yaml/properties被Spring Cloud容器读取,也常常被我们称为引导配置

bootstrap.yaml优先于application.yaml被加载。虽然前者是给Spring Cloud专用的,但是这个属性源最终也会“合并”到Spring Boot的属性源里面去,并且优先级高于application.yaml,所以Spring Boot里也可以使用。

说明:application.yaml里的属性,SC可是完全触碰不到的~


总结

本文有种复习Spring Framework的赶脚,因为大部分概念都是“老的”,但也是最为核心的。以上概念多多少少都会和整合扯上点关系,后面会有所体现。

为何我觉得概念理解如此重要?我觉得概念就像是用于沟通的语言,只有做到感念一致性沟通起来才能顺畅,因此我才觉得在系列开头穿插着书写本文是很有必要的,磨刀不误砍柴工嘛。

尴尬爆料:今天猛然发现,之前好多文章里我把Environment单词写错了,写为了Enviroment,特此提醒各位不要“学我”哦
分隔线

关注我

本号所有“享学xxx”系列文章/视频,和什么“享学课堂”、“享学科技”无任何关系。只因笔者名字和其重名,仅此而已

  • 原创不易,码字更不易,请勿白嫖,你的三连是对A哥的最大支持
  • 关注我吧:一个前25年还不会写Hallo World的半残程序猿,中文名:A哥,英文名:YourBatman

在这里插入图片描述
往期精选

展开阅读全文
©️2020 CSDN 皮肤主题: 代码科技 设计师: Amelia_0503 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值