初识微服务与Springboot及其自动装配原理

最新推荐文章于 2022-08-24 18:11:20 发布

Deeeelete

最新推荐文章于 2022-08-24 18:11:20 发布

阅读量387

点赞数

分类专栏： springboot 文章标签： spring boot

本文链接：https://blog.csdn.net/Deeeelete/article/details/106241721

版权

springboot 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

微服务马丁福勒英文原文：https://martinfowler.com/articles/microservices.html
微服务马丁福勒英文译文：https://blog.csdn.net/u013970991/article/details/53333921

技术进步的首要目的就是解放生产力，其应用的表现形式是解耦。

而微服务就是这样一种用于提高生产效率的架构。

在“封建社会”中，项目代码以war包的形式打包到服务器，个体服务器实行封建独裁政治，代码的全部控制权都被集中在“天子”手里，若是明君，天下福泽；如遇暴君，万民苦命。而当项目开始向复杂化走深的时候，其维护成本也在变得复杂且低效，一旦处理错误，整个服务器都会喑哑失声。

于是起义军起，群雄逐鹿，天下割据，以暴力瓜分，资源不再被单体侵占，而是被多人享有，但因为其行为过于野蛮，对资源的侵占过于盲目，如果一台机器上的内容进行了修改，他们提出了一套更优秀的解决方法，于是其他服务器纷纷效仿，但因为距离之遥远，他们并不能在同一时间内快速完成修改，因此天下松散无章，混沌无序，则民不聊生。

到头来是既要统一且不独裁，既要分化又不敌对，于是就衍生了民主政治，也就是微服务。他们本质上是一个集合，却又各司其职，往来之间靠着http，rpc请求相互联系，如一张大网互相分散但又齐心协力，且独立程度非常之高，一旦某个模块损坏，很快就能有其他模块在不影响总体进度的情况下进行替换，易于维护。老有所依，幼有所长，鳏寡孤独者皆有所养，是为大同。

一：第一个SpringBoot项目

方式一：可以去官网生成项目

网址：https://start.spring.io/内容跟编译器里创建项目一个模式，开头的maven和java默认，填写一下组名包名项目名，选一下web项目，jdk这里用的8，然后下载即可
点击后会提示你下载，这样一个springboot项目大体框架就搭建好了，可以直接在IDEA中导入打开，但因为这边打包的非常缓慢就不再具体演示了，而且一般情况下我们用IDEA进行创建。

方式二：IDEA生成
在这里插入图片描述

项目会自动下载大量的jar包

结构如下

run进行启动

服务运行在8080端口，浏览器访问

生成后我们可以建立对应的包结构，注意，建立的包必须要与入口文件同级，一旦建立的位置错误必然无法访问

这里Controller层的写法还是跟以前一样

重启后访问接口

由此可见，我们的spring boot项目居然连视图解析器，springmvc，以及spring一系列复杂而恶心的配置都没有编写一点项目都能跑的通，那实际上我们的Controller层还是使用的以前的写法，那说明springboot把以前那些恶心的配置环节全都托管了。这也就解释了为什么我们建立的包必须要跟入口文件同级，因为boot既然是自动托管，那就必然要按照一定的规则去执行扫描和载入，这些规则是在底层我们不会去修改，所以要遵守其规范。

而这些关键的东西，都是在pom.xml中进行引入的。
在这里插入图片描述诸如这种的配置依赖，他们之中就包含了springmvc相关，并且内嵌了tomcat作为默认嵌入式容器，下方的bulid可以用来打jar包，也提供了单元测试。
而且在右侧maven这里可以双击进行打jar包。

以及我们可以在properties文件中进行修改端口的操作

在这里插入图片描述
重启后我们就可以在8044端口访问到

springboot的自动装配原理

首先我们去瞅一眼pom.xml，以往我们ssm框架的搭建都要通过冗长的坐标导入来进行进行统一协调，而这次的pom.xml相对来说却非常干净，但我们注意到的是，此配置文件好像存在了这么一个父项目。
在这里插入图片描述
发现此项目还有一个父项目，继续深入

在这里插入图片描述
在这个项目里就可以看到冗长的配置信息，我们常见的jdbc，dbcp等配置也在这里，也就是说我们需要的配置文件都是从这里拿到并导入的。

接着我们退出来找到其核心的入口文件，发现存在一个叫@SpringBootApplication的注解，点进去看源码。
在这里插入图片描述
进入后上面四个元注解就是老面孔了，然后下面的包扫描我们也在springmvc中见识过，至于包扫描的东西从哪儿来，那就应该将目光移交给两个生面孔上，即@SpringBootConfiguration和@EnableAutoConfiguration

在这里插入图片描述
点入第一个@SpringBootConfiguration的源码。

在这里插入图片描述
作为springboot配置注解，我们自然也在源码中看到的对方注有的configuration字样

继续点源码，熟悉的component注解出现，那也就说明其本质是一个组件了，但我们并不能单从这个组件中得到过多的解读，所以回到开始。

在这里插入图片描述
上面的注解我们知道其本质是组件，还有下面的@EnableAutoConfiguration，自动配置注解。

有两个重点项，自动包配置的注解和一个导入的选择器类似的东西。

在这里插入图片描述
选择@AutoConfigurationPackage进行深入，这里看到对方是一个AutoConfigurationPackages.Registrar注册器，而这里的注册时跟我们之前见到的包扫描所对应的，被Registrar了的包信息才会被scan扫描到。

在这里插入图片描述
这样一来这个@AutoConfigurationPackage的粗略作用就稍微清楚点了，回到上一级，我们的AutoConfigurationImportSelector到底选择了些什么东西我们仍然不清楚，所以继续深入源码。

点入源码后向下翻，因为知道这里是选择器，选择的肯定是一个名词，于是走到99行左右的位置发现了一个叫做getAutoConfigurationEntry获取实体的方法。

在这里插入图片描述
接着走到118行这个方法存在的地方，获取的是配置实体，自然跟configurations有关，而找到configurations就得找源头，这也就是说还有个getCandidateConfigurations获取候选配置方法需要进一步探寻。

在这里插入图片描述
getCandidateConfigurations在177行左右的位置，我们看到了一个getBeanClassLoader的加载器，而紧跟在类加载器前面的是一个getSpringFactoriesLoaderFactoryClass()，查看源码。

在这里插入图片描述
源码中赫然有一个EnableAutoConfiguration，而这里的EnableAutoConfiguration恰恰是我们SpringBootApplication中的唯二两个重要注解其中之一，所以说程序兜兜转转，最终目的还是要拿到前面进行的配置。

在这里插入图片描述
目光回到上级，还有一个关键内容loadFactoryNames。

在这里插入图片描述

点进去源码，选择器到底选择并加载了个什么东西的答案需要在这里找寻，我们可以在这里看到两个classLoader，它们一个加载了当前资源，一个加载了系统资源。

在这里插入图片描述
而且彼此加载的都是一个常量，我们点入getResources里的常量FACTORIES_RESOURCE_LOCATION

在这里插入图片描述
发现这里出现了一个文件的路径地址META-INF/spring.factories

在这里插入图片描述
而这个文件想要遁迹而训需要找到External Libraries下的spring-boot.autoconfigure.jar包，在这里的META-INF文件夹下有一个spring.factories文件。

在这里插入图片描述
而在这个配置文件中已经有大量的地址被规划好了，资源引用的对象自然也是从这个文件中被查询到的，即选择器就加载了这么一个核心配置，而spring-boot的启动也是从这里来获取限定值，得到内容后方才执行了自动配置。

在这里插入图片描述
且当我们点入一个应用的时候，发现这些东西其实就是在配置一些对应的bean，bean配置自始至终就是spring绕不开的一个话题，只不过会一步一步的进化并简化，从手动变为自动，为开发节省时间。
当然，也不是说只要spring.factories文件里有的，spring-boot在启动的时候就会全部加载进去，这些与Conditional有关的注解就是在验证项目需不需要开启此功能，如果项目不需要则默认不会开启。