Что нового в 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 больше не будет поддерживать Java 7 и ниже , поскольку Java 8 является минимальным требованием.

Это также первая версия, поддерживающая Java 9. Поддержка Java 9 в ветке 1.x не планируется. Это означает , что если вы хотите использовать последнюю версию Java и воспользоваться преимуществами этой платформы, Spring Boot 2.x — ваш единственный вариант .

2.2. Спецификация материалов

С каждым новым выпуском Spring Boot обновляются версии различных зависимостей экосистемы Java. Это определено в спецификации загрузки, также известной как спецификация .

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

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

• Минимальная поддерживаемая версия Tomcat — 8.5.
• Минимальная поддерживаемая версия Hibernate — 5.2.
• Минимальная поддерживаемая версия Gradle — 3.4.

2.3. Плагин Gradle

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

Для создания толстых jar-файлов задача bootRepackage Gradle заменяется на bootJar и bootWar для создания jar-файлов и варов соответственно.

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

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

В связи с этим интересно узнать, что Spring Boot 2.x больше не будет применять плагин управления зависимостями по умолчанию .

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

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

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

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

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

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

Как только пользователь явно настроит безопасность, значения по умолчанию 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, первоначально представленный как часть различных срезов тестирования еще в 1.4.0.

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

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

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

Привод версии 2 претерпел значительные усовершенствования. Эта итерация сосредоточена на упрощении настройки. Он также поддерживает другие веб-технологии, в том числе новый реактивный модуль.

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

В Spring Boot 1.x для конечных точек привода поддерживалась только Spring-MVC. Однако в версии 2.x он стал независимым и подключаемым. Spring boot теперь поддерживает стандартную поддержку WebFlux, Jersey и Spring-MVC.

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

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

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

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

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

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

    @ReadOperation
    public Map<String, Fruit> fruits() { ... }

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

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

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

• ПОЛУЧИТЬ в /application/fruits возврат фруктов
• POST на /applications/fruits/{a-fruit} , обрабатывающий этот фрукт, который должен быть включен в полезную нагрузку

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

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

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

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

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

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

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

• Большинство свойств конфигурации теперь находятся в файле management.xxx, например: management.endpoints.jmx .
• Некоторые конечные точки имеют новый формат. например: env, flyway или liquibase
• Предопределенные пути к конечным точкам больше не настраиваются

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

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

Spring boot представил инструменты разработки в версии 1.3.

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

В 2.x, когда наше приложение перезапускается с помощью devtools , будет распечатан «дельта-отчет» . В этом отчете будет указано, что изменилось и как это может повлиять на наше приложение.

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

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

5.2. Критические изменения

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

6. Резюме

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

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

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

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