Spring Boot浅谈(是什么/能干什么/优势和不足)

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方案的核心是，把docker做为操做系统环境的交付基线，也就是不一样的fat jar 使用相同的操做系统版本、相同的JVM环境。但对于docker image来讲都是同样的。

• B方案的核心是，不一样的fat jar，独立的编译为docker image，在启动时直接启动带有特定版本的image。

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自身并不解决的问题。

以上是我分享的主要内容，下面咱们总结一下：