spring 与 spring boot的区别在哪里，那个在工作中更常用？

Spring是一个开源的轻量级Java SE（Java 标准版本）/Java EE（Java 企业版本）开发应用框架，其目的为开发Java应用程序提供了全面的基础架构支持。它包含一些很好的功能，依赖注入和开箱即用的模块，如：Spring JDBC 、Spring MVC 、Spring Security、 Spring AOP 、Spring ORM 、Spring Test，总之除了帮我们管理对象及其依赖关系，还提供像通用日志记录、性能统计、安全控制、异常处理等面向切面的能力，还能管理最头疼的数据库事务等。

Spring Boot是Spring框架的扩展，它可以建立独立的Spring应用程序；内嵌了如Tomcat，Jetty和Undertow这样的容器，也就是说可以直接跑起来，用不着再做部署工作；采用约定优于配置的做法，无需再像Spring那样配置大量的xml文件；能够自动配置Spring应用；提供了一些现有的功能，提供生产指标,健壮检查和外部化配置；提供的POM可以简化Maven的配置；

spring出现的时间早，spring boot出现时间晚，但发展快，它的约定优于配置的做法是个趋势。所以在工作中很多开发得较早的Java应用spring比较常见，而比较新的Java应用中spring boot逐渐得到普及。

为什么选择Spring Boot作为微服务的入门级微框架

大概说一下：

Spring 是一个“引擎”

Spring MVC 是基于 Spring 的一个 MVC 框架

Spring Boot 是基于 Spring4 的条件注册的一套快速开发整合包

Spring 最初利用“工厂模式”（ DI ）和“代理模式”（ AOP ）解耦应用组件。大家觉得挺好用，于是按照这种模式搞了一个 MVC 框架（一些用 Spring 解耦的组件），用开发 web 应用（ SpringMVC ）。然后有发现每次开发都要搞很多依赖，写很多样板代码很麻烦，于是搞了一些懒人整合包（ starter ），这套就是 Spring Boot 。

spring 框架有超多的延伸产品例如 boot security jpa etc... 但它的基础就是 spring 的 ioc 和 aop ioc 提供了依赖注入的容器 aop 解决了面向横切面的编程 然后在此两者的基础上实现了其他延伸产品的高级功能 Spring MVC 呢是基于 Servlet 的一个 MVC 框架 主要解决 WEB 开发的问题 因为 Spring 的配置太复杂了 各种 XML JavaConfig hin 麻烦 于是懒人改变世界推出了 Spring boot 约定优于配置 简化了 spring 的配置流程 简单谈下自己的理解 也没有学很久 若有错误请指正

1. Spring Boot是什么，解决哪些问题

?1) Spring Boot使编码变简单

?2) Spring Boot使配置变简单

?3) Spring Boot使部署变简单

?4) Spring Boot使监控变简单

?5) Spring Boot的不足

2. Spring Boot在平台中的定位，相关技术如何融合

?1) SpringBoot与SEDA +MicroService + RESTful

?2) SpringBoot与Mock

3. 采用了SpringBoot之后，技术管理应该如何进行

首先，我们来看一下spring boot是什么，它帮助我们解决了哪些问题：

SpringBoot是伴随着Spring4.0诞生的；

从字面理解，Boot是引导的意思，因此SpringBoot帮助开发者快速搭建Spring框架；

SpringBoot帮助开发者快速启动一个Web容器；

SpringBoot继承了原有Spring框架的优秀基因；

SpringBoot简化了使用Spring的过程。

Spring由于其繁琐的配置，一度被人认为“配置地狱”，各种XML、Annotation配置，让人眼花缭乱，而且如果出错了也很难找出原因。

Spring Boot更多的是采用Java Config的方式，对Spring进行配置。

可以看到，采用了spring-boot-start-actuator之后，直接以REST的方式，获取进程的运行期性能参数。

当然这些metrics有些是有敏感数据的，spring-boot-start-actuator为此提供了一些Basic Authentication认证的方案，这些方案在实际应用过程中也是不足的。

Spring Boot作为一个微框架，离微服务的实现还是有距离的。

没有提供相应的服务发现和注册的配套功能，自身的acturator所提供的监控功能，也需要与现有的监控对接。没有配套的安全管控方案，对于REST的落地，还需要自行结合实际进行URI的规范化工作。

下面，我们研究一下Spring Boot在平台中的定位，相关技术如何融合。

上图比较复杂，整体是采用SEDA，也就是Stage-EDA。可以看到，整体是以处理顺序进行展示的，响应过程类似。在处理过程中，主要会有前置过滤，核心功能处理，后置过滤几大部分。

图中的过滤器都是可插拔式的，并且可以根据实际场景进行扩展开发。每个过滤器都是Stage，比如ClientInstance合法性检查、调用鉴权、解密、限流等等。

一个请求Stage与Stage的转换，实现上是切换不同的线程池，并以EDA的方式驱动。

对于业务逻辑的开发者而言，只需要关心CORE部分的业务逻辑实现，其他的非功能都由框架进行统一实现。

Mock不应当再是测试的专有名词了，当然对于测试这个角色而言，mockito这样的工具，依然可以为他们提升不少效率。

SpringBoot为创建REST服务提供了简便的途径，相比之下，采用阿里的dubbo在做多团队、多进程联调时，mock的难度就陡增。

Mock是解耦并行开发的利器，在理性的情况下，软件从开发期Mock联调，到开发与开发的真实联调，只需要切换一个依赖的域名即可，比如：

mockURI:http://mock.service.net/v1/function?param1=value1

devURI:http://dev.service.net/v1/function?param1=value1

而上述的域名切换，只需要在开发期定义好一个配置项，在做环境切换的时候自动注入即可，省时、省心、省力。

如上图和docker的集成可以有AB两种方案：

A相比与B方案的特点是对于docker registry（也就是docker的镜像仓库）的依赖性较低，对于前期编译过程的要求也较低。

采用了Spring Boot之后，技术管理应该如何进行？

正因为Spring Boot是与Spring一脉相承的，所以对于广大的Java开发者而言，对于Spring的学习成本几乎为零。

在实践Spring Boot时学习重点，或者说思维方式改变的重点在于：

1）对于REST的理解，这一点尤为重要，需要从设计、开发多个角色达成共识，很多时候都是对于HTTP 1.1协议以及REST的精髓不理解，导致REST被“盲用”而产生一些不好的效果。

2）对于YAML的理解和对于JavaConfig的理解，这两点相对较为简单，本质上是简化了xml文件，并提供等价的配置表述能力。

1. 丰富的工具链为SpringBoot的推广带来了利好。

2. SpringBoot的工具链主要来自于两个方面：

1) 原有Spring积累的工具链；

2) SpringMVC或者其他REST框架使用HTTP协议，使得HTTP丰富的工具成为SpringBoot天然的资源。

SpringBoot自身对于前面提到的配置文件：“application.yml”提供了多个“Profile”，可以便于开发者描述不同环境的配置，这些配置例如数据库的连接地址、用户名和密码。

但是对于企业用户而言，把不同环境的配置，写到同一个配置文件中，是极其不安全的，是一个非常危险的动作。

有一个经常被提及的例子是，随着开源的进行，很多互联网公司，都由于把相关的代码提交到github之类的开源代码社区，并且没有对代码进行严格的配置审查，导致一些”password”被公开。有些不良用心的人，就利用搜索工具，专门去挖掘这些关键字，进而导致数据库被“拖库”。

所以对于企业用户，更多的应该是采用集中式的配置管理系统，将不同环境的配置严格区分地存放。

虽然SpringBoot的actuator自身提供了基于“用户名+口令”的最简单的认证方式，但它保护的是对框架自身运行期的性能指标敏感数据的最基本的保护。这种保护在实际应用过程中，“用户名+口令”的管理是缺乏的，“用户名+口令”的安全配置过程是缺失的。

SpringBoot也不提供对于我们自己开发的功能的任何防护功能。

一般来讲，一个安全的信道（信息传输的通道），需要通信双方在进行正式的信息传输之前对对方进行身份认证，服务提供方还需要在此基础之上，对请求方的请求进行权限的校验，以确保业务安全。这些内容也需要基于SpringBoot进行外围的安全扩展，例如采用前面提到的S-EDA进行进程级别的安全管控。这些还需要配套的安全服务提供支持。

一般来说，只要企业与互联网对接，那么随便一个面向消费者的“市场活动”，就有可能为企业带来井喷的流量。

传统企业内，更多的系统是管理信息类的支撑系统，这类系统在设计时的主要用户是企业内部员工以及有限的外部供应商。这类系统存在于企业内部的时间一直很长，功能耦合也很多，在功能解耦前，是非常不适合的，或者说绝对不可以直接为互联网的用户进行服务的。

SpringBoot自身并没有提供这样的流控措施，所以需要结合前面提到的S-EDA进行流量的控制，并结合下层的水平扩展能力（例如，Kubernets）进行流量负载合理的动态扩容。

另外，在长业务流程的设计上，也尽可能地采用异步的方式，比如接口调用返回的是一个“受理号”，而不是业务的处理结果，避免井喷业务到来时，同步调用所带来的阻塞导致系统迅速崩溃，这些也都是SpringBoot自身并不解决的问题。

下面我们总结一下：

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com