Что нового в Spring Boot 2?

Что нового в Spring Boot 2?

1. обзор

Spring Boot привносит взвешенный подход к экосистеме Spring. Впервые выпущен в середине 2014 года. Spring Boot прошла через множество разработок и улучшений. Его версия 2.0 сегодня готовится к выпуску в начале 2018 года.

Есть несколько областей, в которых эта популярная библиотека пытается нам помочь:

  • Управление зависимостями. Через стартеров и различные интеграции менеджера пакетов

  • Автонастройки. Попытка свести к минимуму количество конфигурации, которое требуется приложению Spring для подготовки к работе, и предпочтение соглашения по конфигурации

  • Готовые к производству функции. Например,Actuator, улучшенное ведение журнала, мониторинг, метрики или различная интеграция с PAAS

  • Расширенный опыт разработки. С несколькими утилитами тестирования или улучшенным циклом обратной связи с использованиемspring-boot-devtools

В этой статье мы рассмотрим некоторые изменения и функции, запланированные в Spring Boot 2.0. Мы также расскажем, как эти изменения могут помочь нам стать более продуктивными.

2. зависимости

2.1. Базовый уровень Java

Spring Boot 2.x will no longer support Java 7 and below, что является минимальным требованием Java 8.

Это также первая версия, поддерживающая Java 9. Не планируется поддерживать Java 9 в ветке 1.x. Это означаетif you want to use the latest Java release and take advantage of this framework, Spring Boot 2.x is your only option.

2.2. Ведомость материалов

С каждым новым выпуском Spring Boot обновляются версии различных зависимостей экосистемы Java. Это определено в Bootbill of materials aka BOM.

В 2.х это не исключение. Нет смысла перечислять их, но мы можем взглянуть наspring-boot-dependencies.pom, чтобы увидеть, какие версии используются в любой данный момент времени.

Несколько основных моментов, касающихся минимально необходимых версий:

  • Минимальная поддерживаемая версия Tomcat - 8.5

  • Hibernate минимальная поддерживаемая версия 5.2

  • Минимальная поддерживаемая версия Gradle - 3.4

2.3. Плагин Gradle

Плагин Gradle претерпел значительные улучшения и некоторые критические изменения.

To create fat jars, bootRepackage Gradle’s task gets replaced with bootJar and bootWar для создания фляг и войн соответственно.

Если бы мы хотели запускать наши приложения с плагином Gradle, в 1.x мы могли бы выполнитьgradle bootRun.In 2.x bootRun extends Gradle’s JavaExec.. Это означает, что нам легче настроить его, применяя ту же конфигурацию, которую мы обычно используем в классические задачиJavaExec.

Иногда нам хочется воспользоваться преимуществами Spring Boot BOM. Но иногда мы не хотим создавать полное загрузочное приложение или переупаковывать его.

В связи с этим интересно знать, чтоSpring Boot 2.x will no longer apply the dependency management plugin by default.

Если мы хотим управлять зависимостями Spring Boot, мы должны добавить:

apply plugin: 'io.spring.dependency-management'

Это дает нам большую гибкость с меньшей конфигурацией в вышеупомянутом сценарии.

3. Автоконфигурация

3.1. Безопасность

В 2.x настройка безопасности значительно упрощена. By default, everything is secured, including static resources and Actuator endpoints.с

Как только пользователь настроит безопасность явно, настройки Spring Boot перестанут действовать. Затем пользователь может настроить все правила доступа в одном месте.

Это избавит нас от проблем с упорядочиваниемWebSecurityConfigurerAdapter. Эти проблемы обычно возникали при индивидуальной настройке правил безопасности Actuator и App.

Давайте посмотрим на простой фрагмент кода безопасности, в котором смешаны правила для исполнительных механизмов и приложений:

http.authorizeRequests()
  .requestMatchers(EndpointRequest.to("health"))
    .permitAll() // Actuator rules per endpoint
  .requestMatchers(EndpointRequest.toAnyEndpoint())
    .hasRole("admin") // Actuator general rules
  .requestMatchers(PathRequest.toStaticResources().atCommonLocations())
    .permitAll() // Static resource security
  .antMatchers("/**")
    .hasRole("user") // Application security rules
  // ...

3.2. Реактивная поддержка

Spring Boot 2 предлагает набор новых стартеров для различных реактивных модулей. Некоторыми примерами являются WebFlux и реактивные аналоги для MongoDB, Cassandra или Redis.

Есть также тестовые утилиты для WebFlux. В частности, мы можем воспользоваться преимуществом@WebFluxTest.. Он ведет себя аналогично старому@WebMvcTest, первоначально представленному как часть различных тестовslices еще в 1.4.0.

4. Готовые к производству функции

Spring Boot предоставляет несколько полезных инструментов, которые позволяют нам создавать готовые к работе приложения. Среди прочего, мы можем воспользоваться Spring Boot Actuator.

Actuator содержит различные инструменты для упрощения мониторинга, отслеживания и общего анализа приложений. Более подробную информацию о приводе можно найти в нашемprevious article.

With its 2 version actuator has been through major improvements. Эта итерация направлена ​​на упрощение настройки. Он также поддерживает другие веб-технологии, в том числе новый реактивный модуль.

4.1. Технологическая поддержка

In Spring Boot 1.x only Spring-MVC was supported for actuator endpoints. In 2.x, however, it became independent and pluggable. Spring boot теперь обеспечивает "из коробки" поддержку WebFlux, Jersey и Spring-MVC.

Как и прежде, JMX остается опцией и может быть включен или отключен через конфигурацию.

4.2. Создание пользовательских конечных точек

Новая инфраструктура актуаторов не зависит от технологий. Из-за этого модель разработки была переработана с нуля.

Новая модель также приносит большую гибкость и выразительность.

Давайте посмотрим, как создать конечную точкуFruits для привода:

@Endpoint(id = "fruits")
public class FruitsEndpoint {

    @ReadOperation
    public Map fruits() { ... }

    @WriteOperation
    public void addFruits(@Selector String name, Fruit fruit) { ... }
}

Как только мы зарегистрируемFruitsEndpoint в нашемApplicationContext,, он может быть представлен как конечная точка сети с использованием выбранной нами технологии. Мы также можем выставить его через JMX в зависимости от нашей конфигурации.

Преобразование нашей конечной точки в конечные точки сети приведет к следующему:

  • GET к/application/fruits возвращает фрукты

  • POST на/applications/fruits/{a-fruit} обрабатывает тот фрукт, который должен быть включен в полезную нагрузку

Есть много других возможностей. Мы могли бы получить более детальные данные. Кроме того, мы могли бы определить конкретные реализации для каждой базовой технологии (например, JMX против Web). Для целей статьи мы сохраним ее как простое введение, не вдаваясь в подробности.

4.3. Безопасность в приводе

В Spring Boot 1.x Actuator определяет свою собственную модель безопасности. Эта модель безопасности отличается от модели, используемой нашим приложением.

Это было причиной многих болевых точек, когда пользователи пытались улучшить безопасность.

В версии 2.x конфигурация безопасности должна быть настроена с использованием той же конфигурации, что и остальная часть приложения.

По умолчанию большинство конечных точек привода отключены. Это не зависит от того, находится ли Spring Security в пути к классам или нет. Помимоstatus иinfo, все остальные конечные точки должны быть включены пользователем.

4.4. Другие важные изменения

  • Большинство свойств конфигурации теперь находятся вmanagement.xxx, например:management.endpoints.jmx

  • Некоторые конечные точки имеют новый формат. e.g.: env, flyway or liquibase

  • Предопределенные пути к конечной точке больше не настраиваются

5. Расширенный опыт разработки

5.1. Лучшая обратная связь

Spring boot представилdevtools в 1.3.

Он заботится о сглаживании типичных проблем развития. Например, кэширование технологий просмотра. Он также выполняет автоматический перезапуск и перезагрузку браузера. Кроме того, это позволяет нам удаленно отлаживать приложения.

In 2.x when our application gets restarted by devtools a ‘delta' report will be printed out. В этом отчете будет указано, что изменилось, и какое влияние это может оказать на наше приложение.

Допустим, мы определяем источник данных JDBC, заменяющий источник, настроенный Spring Boot.

Devtools будет указывать, что автоконфигурированный больше не создается. Он также укажет на причину: неблагоприятное совпадение в@ConditionalOnMissingBean для типаjavax.sql.DataSource. Devtools распечатает этот отчет после перезапуска.

5.2. Ломать перемены

Из-за проблем с JDK 9 devtools отказывается от поддержки удаленной отладки через HTTP.

6. Резюме

В этой статье мы рассмотрели некоторые изменения, которые принесет Spring Boot 2.

Мы обсудили зависимости и то, как Java 8 становится минимально поддерживаемой версией.

Далее мы поговорили об автоконфигурации. Мы сосредоточились на безопасности среди других. Мы также говорили о приводе и многих улучшениях, которые он получил.

Наконец, мы говорили о некоторых незначительных изменениях, которые произошли в предоставляемых инструментах разработки.