SpringBoot和微服务架构
SpringBoot和微服务架构
什么是SpringBoot
什么是Spring
Spirng是一个开源框架，2003年兴起的一个轻量级的Java开发框架，作者：Rod Johnson。
Spring是为了解决企业级应用开发的复杂性而创建的简化开发
Spring是如何简化Java开发的
为了降低Java开发的复杂性，Spring采用了一下4种关键策略：
- 基于POJO的轻量级和最小入侵行编程；
- 通过IOC，依赖注入（DI）和面向接口实现松耦合；
- 基于切面（AOP）和惯例进行声明式编程；
- 通过切面和模板减少样式代码
什么是SpringBoot
我管她是什么，好用就行了啊！！！但是无奈我的简历上写了“精通SpringBoot”。。。那总得大体说得上SpringBoot是个啥东西吧！
Spring相信大家都用过，那一堆的配置，用起来就好比：你要吃饭，饭是熟的，但是你还要自己（配置）加油盐酱醋，还得搅拌均匀，然后才能吃，，，
SpringBoot就不一样了，直接给你端过来一碗香喷喷的牛肉拉面，哇，好香，，，，（好吧，写这个博客的时候没有吃饭，臆想一下，）你可以直接狼吞虎咽了有木有？啥？你想让她帮你嚼碎然后喂你？！！！滚吧你。。。
一、关于Spring Boot
在开始了解Spring Boot之前，我们需要先了解一下Spring，因为Spring Boot的诞生和Spring是息息相关的，Spring Boot是Spring发展到一定程度的一个产物，但并不是Spring的替代品，Spring Boot是为了让程序员更好的使用Spring。说到这里可能有些人会迷糊，那到底Spring和Spring Boot有着什么样的联系呢？
1.Spring发展史
在开始之前我们先了解一下Spring，Spring的前身是interface21，这个框架最初是为了解决EJB开发笨重臃肿的问题，为J2EE提供了另一种简单又实用的解决方案，并在2004年3月发布了Spring 1.0正式版之后，就引起了Java界广泛的关注和热评，从此Spring在Java界势如破竹迅速走红，一路成为Java界一颗璀璨夺目的明星，至今无可替代，也一度成为J2EE开发中真正意义上的标准了，而他的创始人Rod Johnson也在之后声名大噪，名利双收，现在是一名优秀的天使投资人，走上了人生的巅峰。
2.Spring Boot诞生
那既然Spring已经这么优秀了，为什么还有了之后Spring Boot？
因为随着Spring发展的越来越火，Spring也慢慢从一个小而精的框架变成了，一个覆盖面广大而全的框架，另一方面随着新技术的发展，比如nodejs、golang、Ruby的兴起，让Spring逐渐看着笨重起来，大量繁琐的XML配置和第三方整合配置，让Spring使用者痛苦不已，这个时候急需一个解决方案，来解决这些问题。
就在这个节骨眼上Spring Boot应运而生，2013年Spring Boot开始研发，2014年4月Spring Boot 1.0正式发布，Spring Boot诞生之初就受到业界的广泛关注，很多个人和企业陆续开始尝试，随着Spring Boot 2.0的发布，又一次把Spring Boot推向了公众的视野，也有越来越多了的中大型企业把Spring Boot使用到正式的生产环境了。值得一提的是Spring官方也把Spring Boot作为首要的推广项目，放到了官网的首位。
3.Spring Boot介绍
Spring Boot是由Pivotal团队提供的全新框架，其设计目的是用来简化Spring应用初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。Spring Boot其实就是一个整合很多可插拔的组件（框架），内嵌了使用工具（比如内嵌了Tomcat、Jetty等），方便开发人员快速搭建和开发的一个框架。
上面的解释是为了大家方便理解，加深记忆。。。下面看看官方的介绍：
Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run".
We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need very little Spring configuration.
我忍不住想翻译一下：
Spring Boot使创建独立的、基于生产级Spring的应用程序变得很容易，您可以“直接运行”这些应用程序。
我们对Spring平台和第三方库有自己的见解，这样您就可以轻松入门了。大多数Spring引导应用程序只需要很少的Spring配置。
大体意思就是说，她真的很好用，她可以让你在服务的搭建时省去很多繁琐的配置，用过之后的体验：“简直像是日了狗了”。。。
4.Spring Boot特点
- 搭建项目快，几秒钟就可以搭建完成；
- 让测试变的简单，内置了JUnit、Spring Boot Test等多种测试框架，方便测试；
- Spring Boot让配置变的简单，Spring Boot的核心理念：约定大约配置，约定了某种命名规范，可以不用配置，就可以完成功能开发，比如模型和表名一致就可以不用配置，直接进行CRUD（增删改查）的操作，只有表名和模型不一致的时候，配置名称即可；
- 内嵌容器，省去了配置Tomcat的繁琐；
- 方便监控，使用Spring Boot Actuator组件提供了应用的系统监控，可以查看应用配置的详细信息；
二、开发环境
Spring Boot 2.0.4
JDK 1.8
IDE：IntelliJ IDEA 2018.2
注意：Spring Boot 2.x 要求Java8及以上版本，不再支持Java6、Java7.
三、开发工具
IntelliJ IDEA Vs MyEclipse
开发工具的选择是每一个人入门人员要经历和选择的，如果你是老手可以忽略本节。
曾几何时Eclipse和MyEclipse统治了Java使用者，而如今，年复一年，毫不客气的说，十年前我用MyEclipse 6.0到现在的MyEclipse 2017 我没有感觉有任何的变化，还是一样的皮肤，一样的布局，一样卡的起飞使用感受，即使按照Google的指引，优化了一堆配置之后，你也会发现收效甚微。
这让我想起了曾经辉煌一时的诺基亚，到今天为止它依然不知道自己做错了什么，但时过境迁当一个事物跟不上时代变化的节奏，它就会被新来更适合的事物所代替。不得不说我曾经也是MyEclipse的忠实热爱者，并且对一个人来说一旦接受了某种事物，出于习惯的作用，通常改变也是很难的。
然而，到今天，我不得不承认IntelliJ IDEA从外观到运行速度上要比MyEclipse好太多，尤其是对Spring Boot的支持上，更好天作之合，所以IntelliJ IDEA是最好的选择。
四、Spring Boot版本号说明
官网上的SpringBoot版本如下图所列：
那版本号后面的英文代表什么含义呢？
具体含义，如下文所示：
- SNAPSHOT：快照版，表示开发版本，随时可能修改；
- M1（Mn）：M是milestone的缩写，也就是里程碑版本；
- RC1（RCn）：RC是release candidates的缩写，也就是发布预览版；
- Release：正式版，也可能没有任何后缀也表示正式版；
五,springBoot核心功能
☆ ** **独立运行的spring项目：Spring Boot可以以jar包形式直接运行，如java-jar xxxjar优点是：节省服务器资源
☆ ** **内嵌servlet 容器：Spring Boot 可以选择内嵌Tomcat，Jetty，这样我们无须以war包形式部署项目。
☆ ** 提供starter 简化Maven 配置：在Spring Boot 项目中为我们提供了很多的spring-boot-starter-xxx的项目（我们把这个依赖可以称之为起步依赖**），我们导入指定的这些项目 的坐标，就会自动导入和该模块相关的依赖包：
例如我们后期再使用Spring Boot 进行web开发我们就需要导入spring-boot-starter-web这个项目的依赖，导入这个依赖以后！那么Spring Boot就会自动导入web开发所需要 的其他的依赖包，如下图所示：
☆ ** **自动配置 spring:Spring Boot 会根据在类路径中的jar包，类，为jar包里的类自动配置Bean，这样会极大减少我们要使用的配置。
当然Spring Boot只考虑了大部分开发场景，并不是所有的场景，如果在实际的开发中我们需要自动配置Bean，而Spring Boot不能满足，则可以自定义自动配置。
☆ ** **准生产的应用监控：Spring Boot 提供基于http，sh，telnet对运行时的项目进行监控
☆ ** **无代码生成和xml配置：Spring Boot大量使用spring4.x提供的注解新特性来实现无代码生成和xml 配置。spring4.x提倡使用Java配置和注解配置组合，而Spring Boot不需要 任何xml配置即可实现spring的所有配置。
自动化配置是如何做到的？
spring boot给我们提供了很多的条件注解来完成
六、补充内容：
啥玩意！？你还不明白？还想更加“深入”的了解一下她？好吧那我就在给你贴点东西吧（有点乱，你随便翻翻看看吧）：
北京时间 2018 年 3 月 1 日早上，如约发布的 Spring Boot 2.0 在同步至 Maven 仓库时出现问题，导
致在 GitHub 上发布的 v2.0.0.RELEASE 被撤回。在问题修复后，官方重新发布了 Spring Boot 2.0，
并提供了 Maven 中央仓库地址。至此 Spring Boot2.0 正式推出！
官方表示，这个版本经历了 17 个月的开发，有 215 个不同的使用者提供了超过 6800 次的提交。非常感谢提
供贡献的每一位用户，并感谢所有对这些里程碑版本提供重要反馈的早期采用者。
该版本是自 4 年前发布 Spring Boot 1.0 以来的第一次重大修订，也是首个提供对 Spring Framework 5.0
支持的 GA 稳定版本。
那去哪里找SpringBoot呢？
很好，这位同学问得好！：
怎么样？这个地方熟悉吧，没错，这就是Spring家族，SB（SpringBoot，一下以及今后的博客简称SB）也是其中成员之一，你可以把她当做Spring的好朋友(●'◡'●)ﾉ(๑•₃•๑)或者闺蜜什么的，whatever吧。。。总之她让我们在和Spring打交道的时候很方便了。
另外SpringBoot2.X之后真的是大换血了：
新版本值得关注的亮点：
1.基于 Java 8，支持 Java 9，这意味着不是不可以使用JDK7 或更旧的JDK版本运行SpringBoot2而是官方推荐使用JDK8+版本，你自己琢磨琢磨用还是用。。。.
2.支持 Quartz 调度程序
3.大大简化了安全自动配置
4.支持嵌入式 Netty
5.Tomcat, Undertow 和 Jetty 均已支持 HTTP/2
6.全新的执行器架构，支持 Spring MVC, WebFlux 和 Jersey
7.使用 Spring WebFlux/WebFlux.fn 提供响应式 Web 编程支持
8.为各种组件的响应式编程提供了自动化配置，如：Reactive Spring Data、Reactive Spring Security 等
9.用于响应式 Spring Data Cassandra, MongoDB, Couchbase 和 Redis 的自动化配置和启动器 POM
10.引入对 Kotlin 1.2.x 的支持，并提供了一个 runApplication 函数，让你通过惯用的 Kotlin 来运行 Spring Boot 应用程序。更多信息请参阅参考文档中对 Kotlin 的支持部分
11.启动时的 ASCII 图像 Spring Boot banner 现已支持 GIF
举个栗子：
。。。
值得注意的一点是，在 Spring Boot 2.0 中，许多配置属性已被重命名或被删除，为了方便升级，Spring Boot 发布了一个新的 spring-boot-properties-migrator 模块。只要将其作为依赖添加到项目中，它不仅会分析应用程序的环境并在启动时打印诊断信息，而且还会在运行时阶段为项目临时将属性迁移至新的配置方式。
在程序迁移至springboot2.0 期间，这个模块是必备的
微服务架构
什么是微服务
微服务是一种架构风格，它要求我们在开发一个应用的时候，这个应用必须构建成一系列小服务的组合；可以通过http的方式进行互通。要说微服务架构，先得说说过去我们的单体应用架构
单体应用架构
所谓的单体应用架构（all in one）是指，我们将一个应用中的所有应用服务都封装在一个应用中。无论是ERP、CRM或者其他什么系统，你都把数据库访、web访问等等功能都放到一个war包内
优点：
- 易于开发和测试，便于部署；当需要扩展时，只需要将war复制多份，然后放到多个服务器上，再做个负载均衡就可以了
缺点：
- 修改一个非常小的地方，都需要停掉整个服务，重新打包、部署整个应用的war包。特别是对于一个大型应用，我们不可能把所有内容都放在一个应用里，我们如何维护、如何分工合作都是问题
微服务架构
all in one的架构方式，我们把所有的功能单元放在一个应用里。然后我们把整个应用部署到服务器上。如果负载能力不行，我们将整个应用进行水平复制，进行扩展，然后均衡负载
所谓的微服务架构，就是打破之前的all in one的架构方式，把每个功能元素独立出来。把独立出来的功能元素的动态组合，需要的功能元素才去拿来组合，需要多一些时可以整合多个功能元素。所以微服务架构是对功能元素进行复制，而没有对整个应用进行复制。
优点：
- 节省了调用资源
- 每个功能元素的服务都是一个可替换的、可独立升级的软件代码
- 易于开发和维护：一个服务只关注一个特定的业务功能，因此它业务清晰，代码量少。开发和维护单个微服务至关简单。而整个应用是若干个微服务构建而成的，因此整个应用在被维持在一个可控的状态；
- 单个服务启动快：单个服务代码量少，因此启动快；
- 局部修改易部署：单个应用只要有修改，就得从新部署整个应用，微服务解决了这个问题。通常来讲，对某个微服务进行修改，只须要从新部署这个服务便可；
- 技术栈不受限：在微服务架构中，能够结合业务和团队的特色,合理选用技术栈。例若有些服务可使用关系型数据库Mysql，有的服务可使用非关系型数据库redis。甚至可根据需求，部分服务使用JAVA开发，部分微服务使用Node.js开发
- 按需收缩：可根据需求，实现细粒度的扩展。例如，系统中的某个微服务遇到了瓶颈，能够结合微服务的特色，增长内存，升级CPU或增长节点。
缺点
- 运维要求高：更多的服务意味着更多的运维投入。在单体架构中，只须要保证一个应用的运行便可，在微服务中，须要保证几十甚至几百个服务器正常运行和协做，这给运维带来了巨大的挑战；
- 分户式固有的复杂性：使用微服务架构的是分布式系统。对于一个分布式系统，系统容错，网络延迟都会带来巨大挑战。
- 接口调整成本高：微服务之间经过接口进行通讯
