Spring Boot 2.0说明

Q：让我们以一个大问题开始——Spring Boot已经是最重要的平台之一，Spring Boot 2.0有什么可以拿得出手的东西？

A: Spring Boot 2.0确实有两个主要目标。第一个是支持响应式编程(非阻塞型应用，异步、事件驱动，需要少数量化线程)。我们正在为所有支持响应式编程的Spring项目提供自动配置，包括Spring WebFlux，与Spring 5.0框架。现在也可以第一次选择Netty作为嵌入服务器。

第二个目标则是稍逊一筹，我们正试图完善在1.x线中所做的决定，以确保我们拥有一个更好的基础向前构建。在这个发布中已经有很多清理与重构。

Q： 有没有1.5版本中已经习惯的东西需要改变？

A：对于大多数已有用户来说，没有重大改变。我们依旧遵循约定大于配置，依旧依据类路径自动配置Spring。如果定义自己的实体，我们依旧支持，仍然可以用properties文件、yaml文件或者环境变量配置。

可能注意到的区别地方在于安全配置与OAuth。OAuth功能目前由一个独立Spring Security工程处理。

Q：2.0发行版本是否向后兼容？

A：用户升级最明显的影响会是properties文件，我们重命名好多properties熟悉以便更为一致。如果正在迁移一个已有工程，并且使用良好Spring Boot支持的集成开发环境IDE，如果尝试使用旧的属性名称，会得到警告信息。我们也可以得到一个迁移JAR包，会将旧的名称自动映射到新的名称上，以便能有机会逐渐重命名。

除此之外，所需要的改变取决于与自己工程跟Spring Boot集成的紧密程度。举个例子来说，如果使用标准自动配置特性，并且使用一些特性自定义东西，那么真的不应该有什么迁移痛苦。如果所做的东西稍微更复杂一点，那么也许需要一些代码迁移。用户面临改变最大的接触点在于嵌入servlet容器支持，actuator端点与metrics。在2.0版本中，actuator端点很不相同，但是如果你花费时间迁移，会免费得到Jersey与WebFlux支持。迁移手册会进一步介绍，并且有迁移JAR相关信息。

Q：老的特性是否废弃，或者不再支持？

A：如果使用迁移工程，那么只支持老的特性名称，这给我们两边最大的好处，因为可以重命名特性，并且保持自己的代码库干净，但是仍然需要一个迁移路径。这也意味着一旦迁移完成，并将迁移去掉，不会花费性能开销检查旧的名称。

Q：是否需要Spring 5.0框架？

A：是的，总是列出了所要求的最近Spring框架版本，Spring Boot 2.0也毫不例外。我们希望Spring 框架5.0.3版本或者更后。

Q：Java最低版本是什么？

A：目前最低所需版本是Java8，我们使用了很多Java8特性与类，所以没有办法在Java更早版本上运行Spring Boot 2.0。

Q：Java9是否完全支持？

A：完全支持Java9，我们甚至有一个CI任务确保Spring Boot以Java 9构建，并且运行所有的样例。更多细节参考这个wiki页：https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-with-Java-9

Q：HTTP/2怎么样呢？

A: 可以使用HTTP/2 Jetty、Undertow或者Tomcat。细节在参考文档中，但是基本上跟在属性中增加server.http2.enabled=true、并且配置SSL一样简单（不支持h2c，清除文本HTTP/2协议）。

Q：假设会继续支持流行应用服务器与框架，比如Tomcat、Jetty与Thymeleaf？

A：我们提供嵌入式Tomcat 8.5、Jetty9.5与Undertow 1.4支持。对于WebFlux应用，也可以使用嵌入式Netty 4.1。也可以仍然将Spring Boot应用部署到应用服务器上，通过TomEE、Wildfly、WebSphere Liberty Profile与Glassfish测试构建.

最低支持Thymeleaf版本是3.0，继续出色支持Spring，包括针对响应式应用引擎节流。

Q：我们是否会看到新的Spring Boot版本与Oracle新的六个月发行版本节奏一致？

A：Spring Boot 2.0是一个特性驱动发行版，我们不能称之为完成直到我们已经拥有一个完整的响应式故事。往前讲，下次几个发行版本会更加迭代式，并且会更容易支持基于日期的发行。已经说了，Spring Boot发布不会完全匹配Oracle发布节奏，我们打算遵循Spring 框架的引导，并且在之后几个月再发布。

Q：我们在这么多新的工程中听过Spring Boot，可是采用指标是什么？

A：根据我们能够跟踪到的指标，我们对采纳率很高兴。当然，作为一个开源项目，很难获取到精确数字。只要觉得合适就能够免费使用软件，无须将使用信息返回给我们。

过去我们常常将maven下载量作为一个指标，但是最近我们已经渐渐更趋向于使用从Spring 初始化 (start.spring.io) 中生成项目的数量。虽然当前的增长率随着时间自然平滑， 2017年见证4.7M个初始化项目生成，代表从2016年以来256%的增长率。maven下载量是非常高的数量，以300%增长率，很欣慰看到两个增长曲线呈现很好相关性。

但是我最喜欢的一个指标是回馈给项目的贡献，很高兴现在有超过400个代码库贡献者。

公共可获得的数据也同样看来有前途的，Spring Boot在Github上位列Java项目forks第一位（将Spring框架移到第二位），stars第七位。

Q：是否有计划在任何时间点停止支持1版本？

A：Spring项目大版本一般支持三年，小版本发布12个月。既然Spring Boot 1.0在2014年发布，1.5版本在2017年早期，我们事实上已经满足那些通常的支持标准。当然，我们也完全预期到用户需要时间升级，所以我们打算支持1.5版本至少到明年。

Q：之前不可用的响应式支持例子是什么？是否需要使用WebFlux与Reactor以便能够受益响应式支持，或者实现是否会普遍给用户响应式益处，如果是这样的话，该怎么样做？

A：我认为Spring在响应式编程中有一个相当独特的位置。虽然可能掺和，采用完全响应式栈，也可更小起步。可以实际从基于Servlet MVC应用中返回reactor类型（Flux与Mono），他们会生效。不会获得完全一样的好处，但是也有机会能够尝试响应式API，而不用完全移到一个全新的架构上。Spring5.0框架也引入了一个新的WebClient API，提供一种很自然的方式调用远程网络服务。API充分使用项目reactor类型，允许以自然方式组成操作。

但是，意识到这一点很重要：响应式编程可选项是我们提供的东西，除了传统同步、阻塞模型；团队致力于为开发者提供两种模型可选，会继续在两头花费精力。

Q：除了Java， 原生支持其他什么JVM语言？

A：可以几乎使用任何JVM语言书写Spring Boot应用，只要Java互操作性良好，Groovy与Kotlin是两个最佳选择，如果想要除了Java的其他语言开发。

Q：Python目前呈现爆发态，Spring 团队针对Python平台是否有在进行中的工作？

A：不清楚目前使用Python的Spring 项目。在Spring后显然有很多年的开发努力，所以一般来说我们针对JVM语言是有道理的。最近可选语言花费在Kotlin。Spring框架与Spring Boot都带有Kotlin扩展包，提供类第一的Kotlin体验。

Q：提到了安全检查--是否使用去年晚些引入的新的Spring Security 5.0?

A：是的，Spring Boot 2.0需要Spring Security 5.0作为最低版本。

Q：能不能谈一下安全特定的变化？

A：Spring Security自身引入了一整套新的API，为了支持响应式编程。如果对已有的Spring Security概念熟悉的话，会发现响应式等价物也很容易使用。

Spring Boot在2.0版本中也利用机会简化安全配置，一些在1.5版本中支持的更负载自定义项已经去除，为了支持更简单的模型。这篇发布博文更为详细地解释了变化依据。

Q：Micrometer指标，是不是一个新的启动器或者是否内建？是否在JMX中暴露？

A：Micrometer.io 替换了指标API，之前是Spring Boot自身的一部分。自动提供了各种技术的instrumentation（Spring MVC、RestTemplate、DataSource Pools等等）。通过利用Micrometer，我们能够与Boot 1.5相类似的方式通过JMX和HTTP暴露指标。有关Micrometer真正令人激动的事情是也能够将指标导出到很多不同后端。我们包括Altlas、Datalog、Ganglia、Graphite、New Relic、Prometheus、SignalFX与StatusD导出支持。