我的反复无常
年初写过几篇springboot的博客，但是觉得条理性差了点，本来想接着写，但是在写spring cloud的时候发现之前很多东西没整理好，决定还是放弃，重新开坑。
本次打算把整个系列计划一下，分为上下两个部分：
前半部分介绍所有必知必会的使用方法和基本原理：包括（1）springboot与微服务相关的内容，（2）如何配置，（3）与常用日志框架log4j、slf4j、logback等整合，（4）springboot在web开发中的各类问题，（5）springboot与虚拟化容器技术docker的整合应用，（7）springboot与数据访问方面的功能（springboot底层用spring data对sql和nosql的数据进行访问），（8）springboot的内部原理。
后半部分介绍一些高级应用场景整合和特性，如缓存、消息、检索等：包括（1）springboot的缓存管理机制，我们会使用redis作为缓存服务器作为示例进行介绍；（2）springboot与消息中间件，如rabbitmq进行整合；（3）springboot与全文检索ES整合；（4）springboot与邮件任务、定时任务、异步任务（提高并发能力）；（5）springboot的安全机制（springboot底层用的安全框架是spring security）；（6）springboot与分布式的整合使用，zookeeper和Dubbo，以及与springcloud的整合使用；（7）以及有关部署和运维springboot应用的要点（springboot的开发热部署 和监控管理）。
可以看出springboot不是一个单纯的框架，而是一个机遇J2EE的全套一站式解决方案。
（本文出自oschina博主happybks的博文：https://my.oschina.net/happyBKs/blog/1805314）
springboot为什么会出现？
所有的技术框架的发展似乎都遵循了一条主线规律：从一个复杂应用场景 衍生 一种规范框架，人们只需要进行各种配置而不需要自己去实现它，这时候强大的配置功能成了优点；发展到一定程度之后，人们根据实际生产应用情况，选取其中实用功能和设计精华，重构出一些轻量级的框架；之后为了提高开发效率，嫌弃原先的各类配置过于麻烦，于是开始提倡“约定大于配置”，进而衍生出一些一站式的解决方案。
是的这就是Java企业级应用->J2EE->spring->springboot的过程。
springboot的目标
Spring Boot来简化Spring应用开发，约定大于配置，去繁从简，只要run就能创建一个用来独立的。
其简化的手段是：包含一个个starter启动器来管理各类依赖和配置，你只需要POM引入这些start，所有的配置基本上springboot的start都会自行配置好，不需要你心。
spring全家桶
如今spring的项目越来越多，但当下最火的当属Spring Boot和Spring Cloud：
Spring Boot ：J2EE一站式解决方案
Spring Cloud ： 分布式整体解决方案
springboot的优势：
（1）快速创建独立运行的Spring项目以及与主流框架集成
（2） 使用嵌入式的Servlet容器，应用无需打成WAR包
springboot的web项目不再需要我们去配置一个tomcat引入相关servlet的类，它自含servlet容器，你可以打成一个jar来运行一个web项目。
（3） starters自动依赖与版本控制
所有的企业级开发场景都有相应的启动器，这些启动器帮我们导入这个场景所需要的所有依赖，并且自动控制版本。
像你要用Mongo、用ES、用redis，开发web项目等等，都只需要在maven的pom下引入相应的starter启动器即可。注意，以mongo为例，它不是像一般项目那样引入一个driver，而是引入一个springboot的mongodb的starter。它不仅会为我们将java访问mongo的driver相关的各个jar按正确的版本导入，还能为我们默认做好各类配置，我们直接继承某些抽象类或者接口，直接使用即可。
（4）大量的自动配置，简化开发，也可修改默认值
用springboot开发应用，用户只需要开发一个微小的入口；我们不需要进行大量的配置，大部分配置springboot已经自动为我们配置好了。
（5）无需配置XML，无代码生成，开箱即用
springboot的无须配置xml，不是因为它会将对应的代码自动生产成，而是springboot已经实现了一些API，它能够帮我们自动配置好。我们只要通过springboot创建出来就能用。
（6） 准生产环境的运行时应用监控
运维期间的健康状况，每个服务的状态等都能监控。
（7）与云计算的天然集成
那么springboot有什么缺点呢？
其实如非要说一个缺点，只能说：方便的springboot让一些程序员丧失了对其封装实现原理有更深了解的机会。因为springboot是在spring基础上的再次封装。当你学习springboot的内部实现原理时，你会发现你必须了解spring内部大量的API。所以如果你需要对springboot深度定制，必须对spring本身有相当的了解。
总结
springboot的目的是构建一个简化spring开发的框架
springboot框架本身是spring技术栈的大整合
springboot是一个基于J2EE的一站式解决方案
微服务
什么是微服务？
微服务是一种架构风格，它要求我们在开发一个应用的时候，这个应用必须构建成一系列小服务的组合；
可以通过http的方式进行互通。
要说微服务架构，先得说说过去我们的单体应用架构。
单体应用架构（All in one）
所谓单体应用架构是指，我们将一个应用的中的所有应用服务都封装在一个应用中。
无论是ERP、CRM或是其他什么系统，你都把数据库访问，web访问，等等各个功能放到一个war包内。
这样做的好处是，易于开发和测试；也十分方便部署；当需要扩展时，只需要将war复制多份，然后放到多个服务器上，再做个负载均衡就可以了。
单体应用架构的缺点是，哪怕我要修改一个非常小的地方，我都需要停掉整个服务，重新打包、部署这个应用war包。特别是对于一个大型应用，我们不可能吧所有内容都放在一个应用里面，我们如何维护、如何分工合作都是问题。
微服务架构
all in one的架构方式，我们把所有的功能单元放在一个应用里面。然后我们把整个应用部署到服务器上。如果负载能力不行，我们将整个应用进行水平复制，进行扩展，然后在负载均衡。
所谓微服务架构，就是打破之前all in one的架构方式，把每个功能元素独立出来。把独立出来的功能元素的动态组合，需要的功能元素才去拿来组合，需要多一些时可以整合多个功能元素。所以微服务架构是对功能元素进行复制，而没有对整个应用进行复制。
这样做的好处是：
（1）节省了调用资源。
（2）每个功能元素的服务都是一个可替换的、可独立升级的软件代码。
微服务与SOA的比较
微服务应该微到什么程度？大家可以看看Martine Flower的有关微服务和SOA的比较的文章：
https://martinfowler.com/articles/microservices.html#MicroservicesAndSoa
这里我就不细说了，等到后面重新写spring cloud文章的时候再说。
如何构建微服务
一个大型系统的微服务架构，就像一个复杂交织的神经网络，每一个神经元就是一个功能元素，它们各自完成自己的功能，然后通过http相互请求调用。比如一个电商系统，查缓存、连数据库、浏览页面、结账、支付等服务都是一个个独立的功能服务，都被微化了，它们作为一个个微服务共同构建了一个庞大的系统。如果修改其中的一个功能，只需要更新升级其中一个功能服务单元即可。
但是这种庞大的系统架构给部署和运维带来很大的难度。
于是，spring为我们带来了构建大型分布式微服务的全套、全程产品：
构建一个个功能独立的微服务应用单元，可以使用springboot，可以帮我们快速构建一个应用；
大型分布式网络服务的调用，这部分由spring cloud来完成，实现分布式；
在分布式中间，进行流式数据计算、批处理，我们有spring cloud data flow。
spring为我们想清楚了整个从开始构建应用到大型分布式应用全流程方案。
