点击查看第一章
点击查看第三章

第2章

实战前的准备工作
工欲善其事，必先利其器。在开始学习之前，最重要的事情就是准备开发环境了，各位读者需要准备 JDK1.8、Maven3.3.3、Spring Tools 4 for Eclipse。为了保证读者在实践的时候所用及所见跟本书介绍的一样，建议大家的环境跟本书所用的一致。本书适合有一定开发经验的朋友，故在环境配置这块不会讲得太细，都是一些非常基础的东西。当然，每个人的开发环境在某些方面肯定是不一样的，比如有的人用Windows，有的人用Mac，有什么问题大家可以直接联系笔者，或者上网查资料。

2.1　开发环境的准备

开发环境的准备主要涉及三个方面：JDK、Maven、Spring Tools 4 for Eclipse。
1. JDK
JDK 的版本用1.8即可，环境变量大家自行去配置。配置好环境变量，在命令行中输入“java –version”能够显示出版本信息即可。笔者这边用的是 Mac 的命令行，Windows 上面用 cmd。

2. Maven
Maven 是用于项目构建的，本书所用的版本是 3.3.3。安装完之后也需要配置环境变量，配置好后同样需要在命令行中输入“mvn –version”进行检测。

3. Spring Tools 4 for Eclipse
大家可以选择自己熟悉的开发工具，不一定要用Spring Tools 4 for Eclipse，Spring Tools 4 for Eclipse下载的地址：http://spring.io/tools 。
下载完成后，还需要安装Lombok插件，本书的示例代码会采用Lombok来简化get,set方法。安装方式可参考http://cxytiandi.com/blog/detail/6813 。

2.2　Spring Boot入门

Spring Cloud 基于 Spring Boot 搭建，本节会简单介绍一下 Spring Boot 的使用方法，如需学习更多 Spring Boot 相关的内容，可以关注笔者的微信公众号“猿天地”，获取更多
信息。

2.2.1　Spring Boot简介

Spring Boot 是由 Pivotal 团队提供的全新框架，其设计目的是简化新 Spring 应用的初始搭建以及开发过程。该框架使用了特定的方式进行配置，从而使开发人员不再需要定义样板化的配置。Spring Boot 致力于在蓬勃发展的快速应用开发领域（rapid application development）成为领导者。
在使用 Spring Boot 之前，我们需要搭建一个项目框架并配置各种第三方库的依赖，还需要在 XML 中配置很多内容。Spring Boot 完全打破了我们之前的使用习惯，一分钟就可以创建一个 Web 开发的项目；通过 Starter 的方式轻松集成第三方的框架；去掉了XML 的配置，全部用注解代替。
Spring Boot Starter 是用来简化 jar 包依赖的，集成一个框架只需要引入一个Starter，然后在属性文件中配置一些值，整个集成的过程就结束了。不得不说，Spring Boot 在内部做了很多的处理，让开发人员使用起来更加简单了。
下面笔者总结了一些使用 Spring Boot 开发的优点：

• 基于 Spring 开发 Web 应用更加容易。
• 采用基于注解方式的配置，避免了编写大量重复的 XML 配置。
• 可以轻松集成 Spring 家族的其他框架，比如 Spring JDBC、Spring Data 等。
• 提供嵌入式服务器，令开发和部署都变得非常方便。

2.2.2　搭建Spring Boot项目

在Spring Tools 4 for Eclipse中依次选择 File -> New -> Maven Project，然后在出现的界面中按图2-1 所示增加相关信息。
完了上述操作之后，在 pom.xml 中添加 Spring Boot 的依赖，如代码清单 2-1 所示。编写启动类，如代码清单 2-2 所示。

启动类使用了 @SpringBootApplication 注解，这个注解表示该类是一个 Spring Boot 应用。直接运行 App 类即可启动，启动成功后在控制台输出信息，默认端口是 8080。
Tomcat started on port(s): 8080 (http)
可以看到，我们只在 pom.xml 中引入了一个 Web 的 Starter，然后创建一个普通的 Java 类，一个 Main 方法就可以启动一个 Web 项目。与之前的使用方式相比，这种方式简单很多。以前需要配置各种 Spring 相关的包，还需要配置 web.xml 文件，还需要将项目放入Tomcat 中去执行，搭建项目的过程还特别容易出错，会出现各种 jar 包冲突。有了 Spring Boot 后这些问题都解决了。
我们之所以能够通过一个 Main 方法启动一个 Web 服务，是因为 Sprig Boot 中内嵌了 Tomcat，然后通过内嵌的 Tomcat 来提供服务。当然，我们也可以使用别的容器来替换 Tomcat， 比如 Undertow 或 Jetty。
Spring Tools 4 for Eclipse还为我们提供了更加便捷的项目创建方式，在File -> New选项中有Spring Starter Project，可以直接选择Spring Boot的版本以及需要依赖的第三方包，直接生成Spring Boot项目，不用再去手动配置Maven依赖。这个功能和https://start.spring.io/提供的是同一个功能，方便快速搭建Spring Boot项目脚手架。

2.2.3　编写第一个REST接口

本节将创建一个控制器，编写第一个 REST 接口，访问地址使用 /hello，如代码清单 2-3 所示。

@RestController 是 @Controller 和 @ResponseBody 的组合注解，可以直接返回 Json 格式数据。@GetMapping 其实就是 @RequestMapping（method = RequestMethod.GET），通过访问http://localhost:8080/hello 可以看到输出的结果“ hello ”。

2.2.4　读取配置文件

在以前的项目中我们主要在 XML 文件中进行框架配置，业务的相关配置会放在属性文件中，然后通过一个属性读取的工具类来读取配置信息。在 Spring Boot 中我们不再需要使用这种方式去读取数据了。Spring Boot 中的配置通常放在 application.properties 中，读取配置信息非常方便，总共分为 3 种方式。
（1）Environment：可以通过 Environment 的 getProperty 方法来获取想要的配置信息， 如代码清单 2-4 所示。

（2）@Value：可以注入具体的配置信息，如代码清单 2-5 所示。

（3）自定义配置类：prefix 定义配置的前缀，如代码清单 2-6 所示。

读取配置的方法如代码清单 2-7 所示。

定义配置 application.properties 的方法如下：
com.cxytiandi.name=yinjihuan

2.2.5　profiles多环境配置

在平时的开发中，项目会被部署到测试环境、生产环境，但是每个环境的数据库地址等配置信息都是不一样的。通过 profile 来激活不同环境下的配置文件就能解决配置信息不一样的问题。在 Spring Boot 中可以通过 spring.pro?les.active=dev 来激活不同环境下的配置。
可以定义多个配置文件，每个配置文件对应一个环境，格式为application-环境.properties，如表2-1所示。

在开发环境中，可以通过修改 application.properties 中的 spring.profiles.active 的值来激活对应环境的配置，在部署的时候可以通过 java –jar xxx.jar --spring.profiles.active=dev 来指定使用对应的配置。

2.2.6　热部署

开发过程中经常会改动代码，此时若想看下效果，就不得不停掉项目然后重启。对于 Spring Boot 项目来说，启动时间是非常快的，在微服务的架构下，每个服务只关注自己的业务，代码量也非常小，这个启动时间是可以容忍的。对于那些臃肿的单体老项目，启动时间简直是浪费生命。虽然 Spring Boot 启动很快，但是我们还是要自己去重启。能不能做到有改动，它就会悄无声息地自己把改动的地方重新加载一遍？答案是肯定的，通过 spring-boot-devtools 就可以实现。
只需要添加 spring-boot-devtools 的依赖即可实现热部署功能，如代码清单 2-8 所示。

注意：在 IDEA 中就算加了插件也是没有效果的，需要开启自动编译功能，开启方法如下：首先，如图2-2 所示进行操作。

然后，同时按下Shift+Ctrl+Alt+/，选择 Registry，如图2-3 所示。
最后，重启 IDEA 就可以了。
配置完热部署后，只要我们有保存操作，Spring Boot就会自动重新加载被修改的Class，我们再也不用手动停止、启动项目了。

2.2.7　actuator监控

Spring Boot 提供了一个用于监控和管理自身应用信息的模块，它就是 spring-boot- starter-actuator。该模块使用起来非常简单，只需要加入依赖即可，如代码清单 2-9 所示。

启动项目我们会发现在控制台输出的内容中增加了图2-4 所示的信息。
图2-4 所示的这些信息是 Actuator 模块提供的端点信息，具体如表 2-2 所示，通过访问这些端点我们可以得到很多监控信息。
比如，我们访问/actuator/health可以得到下面的信息：
{

"status": "UP"

}

UP表示当前应用处于健康状态，如果是DOWN就表示当前应用不健康。增加下面的配置可以让一些健康信息的详情也显示出来：
management.endpoint.health.show-details=ALWAYS
再次访问 /actuator/health，就可以得到健康状态的详细信息：
{

"status": "UP",
"diskSpace": {
    "status": "UP",
    "total": 491270434816,
    "free": 383870214144,
    "threshold": 10485760
}

}
大部分端点默认都不暴露出来，我们可以手动配置需要暴露的端点。如果需要暴露多个端点，可以用逗号分隔，如下所示：
management.endpoints.web.exposure.include=configprops,beans
如果想全部端点都暴露的话直接配置成下面的方式：
management.endpoints.web.exposure.include=*
关于这些监控的信息不再赘述，大家可以自行了解。后面我们会介绍如何使用Spring Boot Admin 在页面上更加直观地展示这些信息，目前都是Json格式的数据，不方便查看。

2.2.8　自定义actuator端点

在很多场景下，我们需要自定义一些规则来判断应用的状态是否健康，可以采用自定义端点的方式来满足多样性的需求。如果我们只是需要对应用的健康状态增加一些其他维度的数据，可以通过继承AbstractHealthIndicator来实现自己的业务逻辑。如代码清单 2-10 所示。

通过up方法指定应用的状态为健康，down方法指定应用的状态为不健康。withDetail方法用于添加一些详细信息。
访问 /actuator/health，可以得到我们自定义的健康状态的详细信息：
{

"status": "UP", 
"details": {
    "user": {
        "status": "UP", 
        "details": {
            "status": true
        }
    }, 
    "diskSpace": {
        "status": "UP", 
        "details": {
            "total": 249795969024, 
            "free": 7575375872, 
            "threshold": 10485760
        }
    }
}

}
上面我们是在框架自带的health端点中进行扩展，还有一种需求是完全开发一个全新的端点，比如查看当前登录的用户信息的端点。自定义全新的端点很简单，通过@Endpoint注解就可以实现。如代码清单 2-11 所示。

访问/actuator/user可以看到返回的用户信息如下:
[

{
    "userName": "yinjihuan", 
    "userId": 1001
}

]

2.2.9　统一异常处理

对于接口的定义，我们通常会有一个固定的格式，比如：
{

"status": true,
"code": 200,
"message": null,
"data": [
    {
        "id": "101",
        "name": "jack"
    },
    {
        "id": "102",
        "name": "jason"
    }
]

}
但是，如果调用方在请求我们的 API 时把接口地址写错了，就会得到一个 404 错误：
{

"timestamp": 1492063521109, 
"status": 404,
"error": "Not Found",
"message": "No message available",
"path": "/rest11/auth"

}
后端服务会告诉我们哪个地址没找到，其实也挺友好。但是因为我们上面自定义的数据格式跟下面的不一致，所以当用户拿到这个返回的时候是无法识别的，其中最明显的是status 字段。我们自定义的是 boolean 类型，用来表示请求是否成功，这里返回的就是 Http 的状态码，所以我们需要在发生这种系统错误时也能返回我们自定义的那种格式，那就要定义一个异常处理类（见代码清单 2-12），通过这个类既可以返回统一的格式，也可以统一记录异常日志。

ResponseData 是我们返回格式的实体类，其发生错误时也会被捕获到，然后封装好返回格式并返回给调用方。最后关键的一步是，在 Spring Boot 的配置文件中加上代码清单2-13 所示配置。

然后当我们调用一个不存在的接口时，返回的错误信息就是我们自定义的那种格式了：
{

"status": false, "code": 404,
"message": "No handler found for GET /rest11/auth", "data": null

}
最后贴上 ResponseData 的定义，如代码清单 2-14 所示。

2.2.10　异步执行

异步调用就是不用等待结果的返回就执行后面的逻辑；同步调用则需要等待结果再执行后面的逻辑。
通常我们使用异步操作时都会创建一个线程执行一段逻辑，然后把这个线程丢到线程池中去执行，代码如代码清单 2-15 所示。

这种方式尽管使用了Java的Lambda，但看起来没那么优雅。在Spring中有一种更简单的方式来执行异步操作，只需要一个 @Async 注解即可，如代码清单 2-16 所示。

我们可以直接在 Controller 中调用这个业务方法，它就是异步执行的，会在默认的线程池中去执行。需要注意的是，一定要在外部的类中去调用这个方法，如果在本类调用则不起作用，比如 this.saveLog()。最后在启动类上开启异步任务的执行，添加 @ EnableAsync 即可。
另外，关于执行异步任务的线程池我们也可以自定义，首先我们定义一个线程池的配置类，用来配置一些参数，具体代码如代码清单 2-17 所示。

然后我们重新定义线程池的配置，如代码清单 2-18 所示。

配置完之后我们的异步任务执行的线程池就是我们自定义的了，我们可以在属性文件里面配置线程池的大小等信息，也可以使用默认的配置：
spring.task.pool.maxPoolSize=100
最后讲一下线程池配置的拒绝策略。当我们的线程数量高于线程池的处理速度时，任务会被缓存到本地的队列中。队列也是有大小的，如果超过了这个大小，就需要有拒绝的策略，不然就会出现内存溢出。目前支持两种拒绝策略：

• AbortPolicy：直接抛出 java.util.concurrent.RejectedExecutionException 异常。
• CallerRunsPolicy：主线程直接执行该任务，执行完之后尝试添加下一个任务到线程池中，这样可以有效降低向线程池内添加任务的速度。

建议大家用CallerRunsPolicy 策略，因为当队列中的任务满了之后，如果直接抛异常， 那么这个任务就会被丢弃。如果是 CallerRunsPolicy 策略，则会用主线程去执行，也就是同步执行，这样操作最起码任务不会被丢弃。

2.2.11　随机端口

在实际的开发过程中，每个项目的端口都是定好的，通过 server.port 可以指定端口。当一个服务想要启动多个实例时，就需要改变端口，特别是在我们后面进行 Spring Cloud 学习的时候，服务都会注册到注册中心里去，为了能够让服务随时都可以扩容，在服务启动的时候能随机生成一个可以使用的端口是最好不过的。在 Spring Boot 中，可以通过${random} 来生成随机数字，我们可以这样使用：
server.port=${random.int[2000,8000]}
通过 random.int 方法，指定随机数的访问，生成一个在 2000 到 8000 之间的数字，这样每次启动的端口就都不一样了。
其实上面的方法虽然能够达到预期的效果，但是也会存在一些问题：如果这个端口已经在使用了，那么启动必然会报错。所以我们可以通过代码的方式来随机生成一个端口，然后检测是否被使用，这样就能生成一个没有被使用的端口。
编写一个启动参数设置类，如代码清单 2-19 所示。

通过对启动参数进行遍历判断，如果有指定启动端口，后续就不自动生成了；如果没有指定，就通过 ServerPortUtils 获取一个可以使用的端口，然后设置到环境变量中。在application.properties 中通过下面的方式获取端口：
server.port=${server.port}
关于获取可用端口的代码如代码清单 2-20 所示。

获取可用端口的主要逻辑是指定一个范围，然后生成随机数字，最后通过 NetUtils 来检查端口是否可用。如果获取到可用的端口则直接返回，没有获取到可用的端口则执行回调逻辑，重新获取。检测端口是否可用主要是用 Socket 来判断这个端口是否可以被链接。相关的代码就不贴了，大家可以参考笔者 GitHub 上的示例代码。
最后在启动类中调用端口即可使用，如代码清单 2-21 所示。

2.2.12　编译打包

传统的Web项目在部署的时候，是编译出一个war包放到Tomcat的webapps目录下。而在Spring Boot构建的Web项目中则打破了这一传统部署的方式，它采用更加简单的内置容器方式来部署应用程序，只需要将应用编译打包成一个jar包，直接可以通过java –jar命令启动应用。
在项目的pom.xml中增加打包的Maven插件，如代码清单 2-22 所示。

mainClass配置的是我们的启动入口类，配置完成后可以通过Maven的mvn clean package命令进行编译打包操作。编译完成后在target目录下会生成对应的jar包，部署的时候直接调用java –jar xx.jar即可启动应用。

2.3　Spring Boot Starter自定义

Spring Boot的便利性体现在，它简化了很多烦琐的配置，这对于开发人员来说是一个福音，通过引入各种Spring Boot Starter包可以快速搭建出一个项目的脚手架。
目前提供的Spring Boot Starter包有：

• spring-boot-starter-web：快速构建基于Spring MVC的Web项目，使用Tomcat做默认嵌入式容器。
• spring-boot-starter-data-redis：操作Redis。
• spring-boot-starter-data-mongodb：操作Mongodb。
• spring-boot-starter-data-jpa：操作Mysql。
• spring-boot-starter-activemq：操作Activemq。
• ……

自动配置非常方便，当我们要操作Mongodb的时候，只需要引入spring-boot-starter-data-mongodb的依赖，然后配置Mongodb的链接信息 spring.data.mongodb.uri = mongodb://localhost/test就可以使用MongoTemplate来操作数据，MongoTemplate的初始化工作全部交给Starter来完成。
自动配置麻烦的是当出现错误时，排查问题的难度上升了。自动配置的逻辑都在Spring Boot Starter中，要想快速定位问题，就必须得了解Spring Boot Starter的内部原理。接下来我们自己动手来实现一个Spring Boot Starter。

2.3.1　Spring Boot Starter项目创建

创建一个项目spring-boot-starter-demo，pom.xml配置如代码清单 2-23 所示。

创建一个配置类，用于在属性文件中配置值，相当于spring.data.mongo这种形式，如代码清单2-24所示。

@ConfigurationProperties指定了配置的前缀，也就是spring.user.name=XXX
再定义一个Client，相当于MongoTemplate，里面定一个方法，用于获取配置中的值， 如代码清单 2-25 所示。

2.3.2　自动创建客户端

一个最基本的Starter包定义好了，但目前肯定是不能使用UserClient ，因为我们没有自动构建UserClient 的实例。接下来开始构建UserClient，如代码清单 2-26 所示。

Spring Boot会默认扫描跟启动类平级的包，假如我们的Starter跟启动类不在同一个主包下，如何能让UserAutoConfigure 生效？
在resources下创建一个META-INF文件夹，然后在META-INF文件夹中创建一个spring.factories文件，文件中指定自动配置的类：
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.cxytiandi.demo.UserAutoConfigure
Spring Boot启动时会去读取spring.factories文件，然后根据配置激活对应的配置类，至此一个简单的Starter包就实现了。

2.3.3　使用Starter

现在可以在其他的项目中引入这个Starter包，如代码清单 2-27 所示。

引入之后就直接可以使用UserClient，UserClient 在项目启动的时候已经自动初始化好， 如代码清单 2-28 所示。

属性文件中配置name的值和开启UserClient：
spring.user.name=yinjihuan
spring.user.enabled=true
访问/user/name就可以返回我们配置的yinjihuan。

2.3.4　使用注解开启Starter自动构建

很多时候我们不想在引入Starter包时就执行初始化的逻辑，而是想要由用户来指定是否要开启Starter包的自动配置功能，比如常用的@EnableAsync这个注解就是用于开启调用方法异步执行的功能。
同样地，我们也可以通过注解的方式来开启是否自动配置，如果用注解的方式，那么spring.factories就不需要编写了，下面就来看一下怎么定义启用自动配置的注解，如代码清单 2-29 所示。

这段代码的核心是@Import({UserAutoConfigure.class})，通过导入的方式实现把UserAutoConfigure实例加入SpringIOC容器中，这样就能开启自动配置了。
使用方式就是在启动类上加上该注解，如代码清单 2-30 所示。

2.3.5　使用配置开启Starter自动构建

在某些场景下，UserAutoConfigure中会配置多个对象，对于这些对象，如果不想全部配置，或是想让用户指定需要开启配置的时候再去构建对象，这个时候我们可以通过@ConditionalOnProperty来指定是否开启配置的功能，如代码清单 2-31 所示。
代

通过上面的配置，只有当启动类加了@EnableUserClient并且配置文件中spring.user.enabled=true的时候才会自动配置UserClient。

2.3.6　配置Starter内容提示

在自定义Starter包的过程中，还有一点比较重要，就是对配置的内容项进行提示，需要注意的是，Eclipse中是不支持提示的，Spring Tools 4 for Eclipse中可以提示，如图2-5所示：

定义提示内容需要在META-INF中创建一个spring-configuration-metadata.json文件， 如代码清单 2-32 所示。

• name：配置名
• type：配置的数据类型
• defaultValue：默认值

2.4　本章小结

本章带领大家学习了 Spring Boot 框架。Spring Boot 是构建 Spring Cloud 的基础，无论你是否要使用 Spring Cloud 来构建微服务，Spring Boot 都是 Web 开发的首选框架。从下章开始我们将正式进入 Spring Cloud 的世界，大家首先会学习到 Spring Cloud Eureka 服务注册中心。