Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Serie: Java, Spring, Spring Boot
- Sprache: Russisch
- Veröffentlichungsjahr: 2023
Spring Boot, который скачивают более 75 миллионов раз в месяц, — наиболее широко используемый фреймворк Java. Его удобство и возможности совершили революцию в разработке приложений, от монолитных до микросервисов. Тем не менее простота Spring Boot может привести в замешательство. Что именно разработчику нужно изучить, чтобы сразу же выдавать результат? Это практическое руководство научит вас писать успешные приложения для критически важных задач. Марк Хеклер из VMware, компании, создавшей Spring, проведет вас по всей архитектуре Spring Boot, охватив такие вопросы, как отладка, тестирование и развертывание. Если вы хотите быстро и эффективно разрабатывать нативные облачные приложения Java или Kotlin на базе Spring Boot с помощью реактивного программирования, создания API и доступа к разнообразным базам данных — эта книга для вас.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 332
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Научный редактор В. Дмитрущенков
Переводчик И. Пальти
Марк Хеклер
Spring Boot по-быстрому. — СПб.: Питер, 2022.
ISBN 978-5-4461-3942-2
© ООО Издательство "Питер", 2022
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Оглавление
Предисловие
Добро пожаловать
Воздушный змей взлетает против ветра, а не по ветру.
Джон Нил, эссе «Инициатива и настойчивость» (The Weekly Mirror)
На сегодняшний день написано немало книг по Spring Boot. Хороших книг, созданных хорошими специалистами. Но любой автор сам выбирает, что включать в издание, что не включать, как представить отобранный материал, и принимает множество других решений, делающих каждую книгу уникальной. То, что одному автору кажется необязательным материалом, другой считает совершенно необходимым. Мы все разработчики, и наши мнения различаются.
Мое мнение таково: в уже существующих книгах недостает кое-каких деталей, которыми, как мне кажется, либо необходимо, либо очень полезно поделиться с разработчиками, только начинающими изучать Spring Boot. Список недостающих деталей непрерывно рос по мере того, как я общался с разработчиками со всего мира, находящимися на различных этапах путешествия в мир Spring Boot. Мы все учимся разному, в разное время и по-разному. Поэтому я и решил написать данную книгу.
Если вы новичок в Spring Boot или чувствуете, что нелишним будет углубить свои знания, — и, будем откровенны, когда это было лишним? — то эта книга специально для вас. В ней охватываются ключевые возможности Spring Boot, а также применение этих возможностей на практике.
Спасибо, что присоединились ко мне в этом путешествии! Приступим!
Условные обозначения
В книге применяются следующие условные обозначения.
Курсив
Курсивом выделены новые термины.
Моноширинный шрифт
Используется для листингов программ, а также внутри абзацев для обозначения таких элементов, как функции, базы данных, типы данных, переменные среды, операторы и ключевые слова, имена файлов и их расширения, команды и параметры командной строки.
Моноширинный жирный шрифт
Показывает команды или другой текст, который пользователь должен ввести самостоятельно.
Моноширинный курсив
Показывает текст, который должен быть заменен значениями, введенными пользователем, или значениями, определяемыми контекстом.
Шрифт без засечек
Используется для обозначения URL, адресов электронной почты, названий меню, параметров, кнопок, каталогов.
Этот рисунок указывает на общее примечание.
Этот рисунок указывает на предупреждение.
Этот рисунок указывает на совет или предложение.
Использование примеров кода
Дополнительные материалы (примеры кода, упражнения и т.д.) доступны для скачивания по адресу https://resources.oreilly.com/examples/0636920338727.
Относительно любых технических вопросов и проблем, возникших у вас при использовании примеров кода, пожалуйста, пишите по адресу электронной почты [email protected].
Эта книга создана, чтобы помочь вам в работе. В целом, если к ней прилагается какой-либо пример кода, можете использовать его в своих программах и документации. Обращаться к нам за разрешением нет необходимости, разве что вы копируете значительную часть кода. Например, написание программы, использующей несколько фрагментов кода из этой книги, не требует отдельного разрешения. Для продажи или распространения компакт-диска с примерами из книг O’Reilly, конечно, разрешение нужно.
Ответ на вопрос путем цитирования этой книги, в том числе примеров кода, не требует разрешения. Включение значительного количества кода примеров из нее в документацию вашего программного продукта требует разрешения.
Мы ценим, хотя и не требуем, ссылки на первоисточник. Ссылка на первоисточник включает название, автора, издательство и ISBN, например: «Хеклер М. Spring Boot по-быстрому. — СПб.: Питер, 2022, 978-5-4461-3942-2».
Благодарности
Нет предела моей благодарности всем, кто вдохновлял меня на написание этой книги и поддерживал во время работы над ней. Вы просто не представляете, как важно для меня то, что вы читали ее черновики и писали отзывы или просто тепло отозвались о ней в Twitter. Огромное вам спасибо!
Но есть несколько человек, сделавших эту книгу реальностью, а не просто оптимистическим планом по написанию.
Мой начальник, учитель и друг Таша Айзенберг (Tasha Isenberg). Таша, ты работала со мной, утрясая расписание, а когда ситуация стала совсем сложной, расчистила для меня дорогу для финишного рывка и помогла уложиться в основные сроки. Я очень благодарен за то, что у меня есть столь понимающий и энергичный заступник в VMware.
Доктор Дэвид Сайр (David Syer), основатель Spring Boot, Spring Cloud, Spring Batch, чей вклад в бесчисленные проекты Spring неоценим. Ваша проницательность была совершенно исключительной, а отзывы — невероятно содержательными, и никаких слов не хватит, чтобы выразить вам мою благодарность.
Грег Тернквист (Greg Turnquist), член команды Spring Data. Спасибо за критический взгляд и неприукрашенные отзывы: книга стала заметно лучше благодаря вашей бесценной новой точке зрения.
Мои редакторы Корбин Коллинз (Corbin Collins) и Сюзанна (Зан) Маккуэйд (Suzanne (Zan) McQuade). Ваша исключительная поддержка на всем пути от задумки книги до завершения вдохновляла меня на то, чтобы работать на пределе возможностей и как-то укладываться в, казалось бы, невозможные сроки. Я не мог желать большего.
Роб Романо (Rob Romano), Кэйтлин Геган (Caitlin Ghegan), Ким Сандовал (Kim Sandoval) и весь производственный отдел O’Reilly. Вы помогли мне завершить работу, придя на выручку в самый важный момент, на финишной прямой, буквально и фигурально выпустив эту книгу в мир.
Наконец, самое главное: моя прекрасная, любящая и чрезвычайно терпеливая жена Кэти. Сказать, что ты вдохновляешь меня и придаешь мне силы делать все, что я делаю, — величайшее преуменьшение. От всего сердца спасибо тебе за все.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Глава 1. Коротко о Spring Boot
В этой главе мы обсудим три важнейшие возможности Spring Boot и расскажем, как они повышают производительность труда разработчиков.
Три основополагающие возможности Spring Boot
Три важнейшие возможности Spring Boot, на которых основывается все прочее: упрощение управления зависимостями, упрощение развертывания и автоконфигурация.
Упрощение управления зависимостями с помощью стартовых пакетов
Один из самых потрясающих аспектов Spring Boot — управление зависимостями — становится действительно... управляемым.
Если вы более или менее давно разрабатываете важное программное обеспечение, то почти наверняка сталкивались с несколькими проблемами, связанными с управлением зависимостями. Любая функциональность приложения обычно требует нескольких зависимостей «переднего края». Например, чтобы предоставить реализующий REST веб-API, необходимо обеспечить способ открытия конечных точек для доступа по HTTP, прослушивания запросов, привязки этих конечных точек к методам/функциям обработки запросов с последующим формированием и возвращением соответствующих ответов.
Практически всегда все основные зависимости включают множество других зависимостей для реализации обещанной ими функциональности. Развивая пример с реализацией REST API, мы могли бы ожидать увидеть набор зависимостей (организованных в виде разумной, хотя и спорной структуры), включающих код для возврата ответов на запросы в конкретном формате, например JSON, XML, HTML; код для упаковки/распаковки объектов в требуемый (-е) формат (-ы); код для прослушивания и обработки запросов и возвращения ответов; код для декодирования сложных URI, применяемых при создании универсальных API; код поддержки различных протоколов связи и т.д.
Даже в этом относительно простом примере, вероятно, в файле сборки потребуется немало зависимостей. И это мы еще даже не думали, какую функциональность хотели бы включить в свое приложение, а говорили только про его внешние взаимодействия.
А теперь поговорим о версиях каждой из этих зависимостей.
Совместное использование библиотек требует определенной степени строгости, ведь зачастую одна версия конкретной зависимости может тестироваться (или вообще работать правильно) лишь с конкретной версией другой зависимости. И когда эти проблемы неизбежно возникают, то приводят к тому, что я называю лернейской гидрой зависимостей.
Как и ее тезка, лернейская гидра зависимостей может доставить немало проблем. И как и в случае с тезкой, никакой награды за поиск и искоренение программных ошибок, возникающих из-за расхождения версий, вас не ждет, только неуловимые окончательные диагнозы и часы, потраченные впустую на их поиск.
Знакомьтесь со Spring Boot и его стартовыми пакетами. Стартовые пакеты Spring Boot представляют собой спецификации (Bill of Materials, BOM), основанные на проверенном практикой предположении, что практически всегда создание конкретной функциональной возможности происходит практически одинаково.
В предыдущем примере при каждом создании API мы организовывали доступные для пользователей конечные точки, прослушивали на предмет запросов, обрабатывали запросы, отправляли и получали данные по сети посредством конкретного протокола и т.д. Этот паттерн проектирования/разработки/использования практически неизменен и представляет собой общепринятый подход, лишь с несколькими небольшими вариациями. И как и для прочих аналогичных паттернов, под рукой есть охватывающий его стартовый пакет Spring Boot.
Для получения всех этих связанных между собой элементов функциональности в одной зависимости приложения достаточно добавить один-единственный стартовый пакет, например spring-boot-starter-web. Все охватываемые им зависимости синхронизированы по версиям — протестированы на совместную работу, то есть проверено, что включенная в стартовый пакет версия библиотеки A корректно работает с включенной версией библиотеки Б… и В… и Г, и т.д. Это резко сокращает список зависимостей и упрощает жизнь разработчика, практически исключая труднообнаруживаемые конфликты версий среди зависимостей, необходимых для реализации неотъемлемых возможностей приложения.
В тех редких случаях, когда необходимо включить в приложение функциональность, предоставляемую другой версией включенной зависимости, можно просто переопределить протестированную версию.
Если вам нужно переопределить используемую по умолчанию версию зависимости — переопределяйте… но тогда повысьте уровень тестирования, чтобы сократить возникающие риски.
При желании можно также исключать ненужные для конкретного приложения зависимости с учетом того же предостережения.
В целом идея стартовых пакетов Spring Boot существенно упрощает зависимости и сокращает усилия, необходимые для добавления целых их наборов в приложение, а также резко сокращает накладные расходы по их тестированию, поддержке и обновлению.
Упрощение развертывания с помощью исполняемых JAR-файлов
Давным-давно, в те времена, когда по земле бродили серверы приложений, развертывание приложений Java было непростой задачей.
Чтобы запустить в эксплуатацию приложения, скажем, с доступом к базе данных, подобно многим современным микросервисам и практически всем приложениям с монолитной архитектурой тогда и сейчас, — пришлось бы проделать следующее.
1. Установить и настроить сервер приложений.
2. Установить драйверы базы данных.
3. Создать соединение с базой данных.
4. Создать пул соединений.
5. Собрать и протестировать приложение.
6. Выполнить развертывание приложения и его обычно довольно многочисленных зависимостей на сервере приложений.
Обратите внимание, что этот список предполагает наличие администраторов, которые бы настроили машину/виртуальную машину, и что на каком-то этапе независимо от этого процесса была создана база данных.
Spring Boot перевернул большую часть этого неуклюжего процесса развертывания с ног на голову и схлопнул описанные шаги в один (может, два, если считать за шаг копирование/вставку с помощью команды cfpush отдельного файла в нужное место).
Spring Boot не первоисточник так называемых über JAR-файлов1, но он произвел в них переворот. Вместо того чтобы выделять каждый файл из JAR-файла приложения и всех JAR-файлов зависимостей с последующим объединением их в один целевой JAR-файл — этот процесс иногда называют шейдингом (shading), — разработчики Spring Boot посмотрели с совершенно новой точки зрения, задавшись вопросом: а нельзя ли создавать вложенные JAR-файлы с сохранением их желаемого и получающегося форматов?
Вложение JAR-файлов вместо их шейдинга позволяет устранить огромноеколичество потенциальных проблем, возникающих вследствие потенциальных конфликтов версий, когда JAR-файл зависимости A и JAR-файл зависимости Б используют различные версии В. Исчезают также возможные юридические проблемы, возникающие вследствие переупаковки программного обеспечения и объединения его с другим программным обеспечением под другой лицензией. Хранение всех JAR-файлов зависимостей в исходном формате явно позволяет избежать этих и других проблем.
Кроме того, при необходимости можно легко извлечь содержимое исполняемого JAR-файла Spring Boot. В некоторых случаях это может понадобиться, и далее в книге я расскажу почему. А пока просто знайте, что исполняемые JAR-файлы Spring Boot способны решить многие ваши проблемы.
Благодаря включению всех зависимостей в один JAR-файл Spring Boot, развертывание чрезвычайно упрощается. Вместо сбора и проверки всех развертываемых зависимостей плагин Spring Boot обеспечивает их упаковку в выходной JAR-файл. А при его наличии можно запускать приложение везде, где доступна виртуальная машина Java (JVM), с помощью команды вида java-jar<SpringBootAppName.jar>.
Это еще не все.
Достаточно установить нужное значение одного-единственного свойства в файле сборки, чтобы плагин сборки Spring Boot сделал этот один-единственный JAR-файл полностью (само-)исполняемым. При наличии на машине JVM можно не набирать (описывать в сценарии) длинную строку java-jar<SpringBootAppName.jar>, а просто набрать команду <SpringBootAppName.jar> (конечно, заменив имя файла своим) — и дело в шляпе, все запущено и работает. Проще некуда.
Автоконфигурация
Новички в Spring Boot иногда смотрят на автоконфигурацию как на какое-то волшебство. Вероятно, автоконфигурация — величайший фактор повышения производительности работы программистов из предоставляемых Spring Boot. Я часто называю ее сверхспособностью разработчиков: Spring Boot обеспечивает невероятную производительность, учитывая мнения в популярных и повторяющихся сценариях использования.
Мнения в программном обеспечении? Чем они могут помочь?!
Если вы хоть сколько-нибудь долго работали программистом, то, без сомнения, заметили частое повторение определенных паттернов. Не точь-в-точь, конечно, но довольно близко — вероятно, в 80–90 % случаев проектирование, разработка и действия разработчика относятся к типичным сценариям использования.
Я уже упоминал эту повторяемость в программном обеспечении, именно она делает стартовые пакеты Spring Boot изумительно согласованными и удобными. Повторяемость также означает, что упомянутые действия, относящиеся к написанию кода для решения конкретной задачи, готовы к упрощению.
Возьмем для примера Spring Data — проект, связанный со Spring Boot и используемый им. Мы знаем, что для любого обращения к базе данных должно быть открыто какое-либо соединение с ней. Мы также знаем, что по выполнении приложением своих задач это соединение необходимо закрыть, чтобы избежать проблем. А в промежутке, вероятно, выполняются многочисленные обращения к базе данных посредством SQL-запросов — простых и сложных, только для чтения и с возможностью записи в базу данных, — и правильное создание этих SQL-запросов требует определенных усилий.
Теперь представьте себе, что все это можно существенно упростить. Автоматически открывать соединение при задании базы данных. Автоматически закрывать соединение по завершении работы приложения. Следовать простому и логичному соглашению по автоматическому созданию запросов, с минимальными затратами усилий разработчиком. Легкая настройка даже этого минимального кода под свои нужды, опять же в соответствии с простым соглашением, для создания упомянутых сложных SQL-запросов, заведомо согласованных и эффективных.
О подобном подходе к написанию кода иногда говорят: соглашения важнее конфигурации (convention over configuration), и если конкретное соглашение для вас внове, возможно, на первый взгляд оно покажется странноватым, но станет просто глотком свежего воздуха, если вам уже приходилось реализовывать схожую функциональность с написанием порой сотен повторяющихся, отупляющих строк кода создания/освобождения ресурсов/настройки простейших задач. Spring Boot (и большинство проектов Spring) следует мантре «соглашения важнее конфигурации», гарантируя, что если следовать простым, четким и хорошо документированным соглашениям, код конфигурации будет минимальным или вообще окажется не нужен.
Кроме того, автоконфигурация наделяет разработчика сверхспособностями благодаря тому, что команда Spring подходит к конфигурации среды, придерживаясь принципа «разработчик прежде всего». Наша производительность как разработчиков наиболее высока, когда можно сосредоточиться на решаемой задаче, а не выполнять миллион рутинных операций настройки. Как же Spring Boot добивается этого?
Возьмем для примера другой связанный со Spring Boot проект — Spring Cloud Stream. При подключении к платформе обмена сообщениями наподобие RabbitMQ или Apache Kafka разработчик обычно должен указать определенные настройки для соединения с этой платформой и ее использования — имя хоста, порт, учетные данные и т.д. Концентрация внимания на нуждах разработчиков означает наличие настроек по умолчанию (на случай, если другие не указаны), создающих подходящие условия для разработчика, работающего локально: localhost, порт по умолчанию и т.д. Все это — хорошо продуманная среда выполнения, практически на 100 % совместимая со средами разработки, хотя в производственной среде это не так. В рабочей среде может понадобиться указать конкретные значения, так как среда платформы и хостинга очень изменчива.
Использование значений по умолчанию в совместно разрабатываемых проектах позволяет также существенно сократить время, необходимое для настройки среды разработки. Это чистая выгода как для вас, так и для вашей команды.
В некоторых случаях конкретные сценарии использования относятся не к упомянутым 80–90 % типичных сценариев, а к прочим 10–20 % вполне допустимых сценариев. В этих случаях можно выборочно переопределить автоконфигурацию или даже отключить ее полностью, хотя, конечно, тогда вы утратите все сверхспособности. Для изменения некоторых решений обычно требуется всего лишь задать нужные значения одного или нескольких свойств или предоставить один или несколько компонентов, реализующих нечто, для чего в Spring Boot в обычных условиях служит автоконфигурация. Другими словами, это очень просто сделать в тех редких случаях, когда действительно нужно. Автоконфигурация — инструмент с широкими возможностями, незаметно и неустанно работающий ради упрощения жизни разработчика и невероятного повышения его производительности.
Резюме
Три важнейшие возможности Spring Boot, на которых основывается все прочее: упрощение управления зависимостями, упрощение развертывания и автоконфигурация. Их все можно настраивать под свои нужды, но делать это приходится редко. И все три делают очень многое, чтобы вы стали более производительным разработчиком. Spring Boot буквально окрыляет!
В следующей главе мы рассмотрим, какой замечательный выбор есть у приступающих к созданию приложений Spring Boot. Все варианты — отличные!
1 От нем. über — «сверх». — Примеч. пер.
