«1. Обзор

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

Существуют различные области, в которых эта популярная библиотека пытается нам помочь:

    Управление зависимостями. Через стартеры и различные интеграции менеджера пакетов Автоконфигурация. Попытка свести к минимуму объем конфигурации, который требуется приложению Spring для подготовки к работе, и отдавать предпочтение соглашению, а не функциям конфигурации, готовым к производству. Например, Actuator, улучшенное ведение журнала, мониторинг, метрики или различные интеграции с PAAS. Расширенный опыт разработки. С несколькими утилитами тестирования или улучшенным циклом обратной связи с использованием spring-boot-devtools

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

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

2.1. Java Baseline

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 в зависимости от нашей конфигурации.

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

    GET на /application/fruits, возвращающий фрукты POST на /applications/fruits/{a-fruit}, обрабатывающий эти фрукты, которые должны быть включены в полезную нагрузку ~~ ~ Есть много других возможностей. Мы могли бы получить более подробные данные. Кроме того, мы могли бы определить конкретные реализации для каждой базовой технологии (например, JMX или Web). Для целей статьи мы сохраним это как простое введение, не вдаваясь в подробности.

4.3. Безопасность в Actuator

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

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

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

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

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

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

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

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

Весенняя загрузка представила инструменты разработки в версии 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 становится минимально поддерживаемой версией.

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

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

«