Приветствую, уважаемый читатель!
Мы живем в интересное время – практически у каждого человека в кармане лежит небольшой компьютер, имеющий доступ в Интернет. Этот факт обеспечил появление множества востребованных интернет-сервисов. Если раньше имело смысл создавать приложения, которые нужны всем, например, службу электронной почты, то в наши дни из-за массовости проникновения технологии спрос найдет и какая-нибудь экзотика вроде доставки вегетарианской пищи.
Такой разброс «предметных областей» мог бы потребовать тысяч уникальных программных продуктов, множество технологий и разновидностей специалистов. Но так не случилось.
Большая часть возможностей, которые предлагает нам Интернет, обеспечена приложениями на основе микросервисной архитектуры. Микросервис – это независимое приложение, которое умеет выполнять несколько взаимосвязанных функций по запросам от других микросервисов, либо от пользовательского интерфейса.
Так же, как наши жилища построены из однотипных кирпичей, блоков или плит, так и Интернет-сервисы, которые мы используем, состоят из множества микросервисов.
Микросервисы независимы, легко переиспользуются или заменяются. А главное - они сравнительно просты и, зачастую, однотипно устроены. Достаточно написать один-два, и программист может создавать их быстро и очень много, большую часть позаимствовав из других проектов. Например, хорошо написанный сервис User Manager можно затем переиспользовать в любых проектах, где есть авторизация пользователей. Хорошо написанные сервисы продуктовых каталогов и заказов можно использовать в любом новом проекте, связанном с продажами через Интернет.
Это руководство поможет Вам освоить современную серверную Java-разработку на примере написания стандартного микросервиса.
Предлагаю ознакомиться с планом работ, выполнив которые, мы создадим готовый к развертыванию в промышленной платформе микросервис с правильной архитектурой.
Первая часть «Инструменты разработчика» расскажет о типовом наборе средств, которые ежедневно используются в нашей работе:
Java Development Kit – комплект Java-разработчика
IntelliJ IDEA – среда разработки
Gradle – система автоматической сборки
Git – система управления версиями
Вторая часть «Архитектура приложения» посвящена тому, как устроен типовой Java-сервис:
Spring Boot – платформа (framework) для написания приложений на Java
DTO – объекты для передачи данных
REST-контроллеры – обработчики запросов
Валидация – проверка корректности данных
Модели – представления о сущностях
Liquibase – создание и подключение к базе данных
DAO-слой – взаимодействие с базой данных
Сервисный слой – бизнес-логика
Обработка исключений – что делать, если что-то пошло нет так
Scheduler – запуск обработки без запроса
Kafka – обмен сообщениями с другими приложениями
Application.yml – конфигурация приложения
Транзакции – позаботимся о целостности данных
Третья часть «Тестирование» поможет написать тесты для вашего приложения:
JUnit – тестирование классов проекта, профили приложения
MockMvc – тестирование REST-контроллеров
Run Tests With Coverage – проверяем покрытие тестами
Rest Assured – тестирование web-сервисов
Selenium-java – frontend-тестирование
Четвертая часть «Контейнеризация приложений» познакомит вас с тем, каким образом запускаются и работают приложения в промышленных средах:
Дистрибутивы – отдаем приложение в эксплуатацию
Docker – средство контейнеризации приложений
Kubernetes – средство оркестровки приложений
В четвертой части «Разное» будет рассказано о важных мелочах, которые помогут влиться в команду профессионалов:
Форматирование кода – каким должен быть Java-код
Code Review – обсуждение доработок
Merge Conflict – что делать, если возник конфликт веток
Markdown – разметка форматирования текста
OpenAPI – framework для описания REST-сервисов
JSON Web Token – токены доступа
SSL/HTTPS – включаем шифрования трафика
Maven – еще один стандартный сборщик проектов
Jira – средство планирования разработки
Stand-up – общение с командой
Собеседование – как получить работу своей мечты
«Список литературы» - книги, которые надо прочитать
Часть 1. Инструменты разработчика
В этой части мы установим на компьютер средства, необходимые разработчику: JDK, IDEA и Git. Затем создадим новый проект и репозиторий для него. А также научимся вносить в проект изменения так, как это принято при командной разработке.
Java Development Kit
Java Development Kit – это первый, обязательный и минимально-необходимый инструмент Java-разработчика. Без него невозможна компиляция Java-программ.
Важно – не путайте Java Runtime Environment (JRE) и Java Development Kit (JDK). Первое позволяет только запускать уже скомпилированные Java-программы.
Прежде чем скачивать и устанавливать JDK на компьютер, получите информацию о версии JDK, которая используется на проекте. Если такой информации нет, установите последнюю LTS версию – 17 (к середине 2022 года).
На момент, когда пишутся эти строки, уже существует 18 версия, а когда вы будете их читать, наверняка будут 19, 20 и 21 версии. Но надо учитывать, что не каждая версия имеет статус Long Term Support (LTS), предполагающий поступление обновлений для нее.
История появления последних версий JDK
Версия |
LTS |
Год выхода |
8 |
Да |
2014 |
9 |
Нет |
2017 |
10 |
Нет |
2018 |
11 |
Да |
2018 |
12 |
Нет |
2019 |
13 |
Нет |
2019 |
14 |
Нет |
2020 |
15 |
Нет |
2020 |
16 |
Нет |
2021 |
17 |
Да |
2021 |
18 |
Нет |
2022 |
19 |
Нет |
2022 (запланировано) |
20 |
Нет |
2023 (запланировано) |
21 |
Да |
2023 (запланировано) |
Вопрос - откуда скачивать JDK – не так прост. Изначально язык Java был разработан компанией Sun Microsystems, а JDK распространялся бесплатно. Затем в 2010 году Sun приобрела фирма Oracle, которая стала вводить лицензионные ограничения на Oracle JDK. Однако за три года до этого Sun опубликовала исходный код Java, что дало старт проекту OpenJDK, коммерческое использование которого не ограничивалось.
Начиная с 17 версии Oracle разрешает разработку при помощи своей JDK в коммерческих целях бесплатно, но только «для внутренних бизнес операций». Это значит, что если вы производите программное обеспечение, являясь сотрудником некоей компании, то запущено оно может быть только «внутри» этой компании. В других случаях: работа по договору оказания услуг, работа на фирму-подрядчика, установка разработанной программы на компьютеры клиента – необходима консультация юриста.
Поэтому на текущий момент общая рекомендация для коммерческой разработки - установите OpenJDK.
С 8 по 16 версии рекомендуется устанавливать Adopt OpenJDK. Начиная с 17 версии проект стал частью Eclipse Foundation и сменил наименование на Eclipse Adoptium. Работая надо этим руководством, я использовал именно эту версию JDK.
После установки убедитесь, что системная переменная JAVA_HOME указывает на папку, в которую был развернут JDK.
Cреда разработки INTELLIJ IDEA
В принципе, JDK и любой текстовый редактор – это минимум, чтобы начать писать Java-программы. Но для профессиональной разработки стандартом является использование IntelliJ IDEA от фирмы JetBrains.
Установите IDEA Ultimate Edition и создайте с ее помощью новый проект.
После того, как вы нажмете кнопку «Create», автоматически будет создана структура каталогов для проекта и минимально-необходимый набор файлов.
Простейший Gradle-проект готов к запуску. Файл Main.java не должен вызывать вопросов, а вот на build.gradle остановимся подробнее.
Система автоматической сборки Gradle
Автоматические системы сборки предназначены для облегчения работы с проектом. Gradle уже включен в поставку IDEA, поэтому отдельно скачивать и устанавливать его не нужно.
Сборочный файл build.gradle уже создан для нас. Посмотрим, что внутри:
Эта секция подключает плагин компиляции и сборки Java-программ.
plugins {
id 'java'
}
Репозитории, откуда будут скачиваться библиотеки. Автоматически добавлен mavenCentral – это псевдоним репозитория maven.org, которого в большинстве случаев достаточно для работы.
repositories {
mavenCentral()
}
Сторонние библиотеки, которые использует проект. Пока добавлены библиотеки JUnit для тестирования, которым мы займемся ближе к концу реализации проекта.
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.1'
}
Платформа JUnit указана как целевая для запуска тестов.
test {
useJUnitPlatform()
}
По мере того, как мы будем добавлять функциональность в приложение, мы будем дописывать в секции файла build.gradle новую информацию.
Система управления версиями GIT
В промышленной разработке работа над проектами ведется командами, в которых программисты работают одновременно. Чтобы не мешать друг другу, каждый из разработчиков создает свою версию проекта - «ветку» и вносит изменения туда. После того, как работа закончена, ветка разработчика вливается («мерджится») в основную. Этот процесс обеспечивают системы управления версиями. На данный момент стандартом в индустрии является система Git за авторством создателя Linux – Линуса Торвальдса.
Установите Git на свой компьютер и включите в IDEA интеграцию с ним.
Файлы проекта в навигаторе окрасились в красный цвет – это значит, что Git их пока не обрабатывает. Это нужно исправить. Но предварительно надо указать Git, какие файлы проекта в репозитории не нужны: локальные настройки (.gradle, .idea), результаты сборок (build).
Укажите три каталога и у вас должен появится такой файл .gitignore
/.gradle/
/.idea/
/build/
Добавьте файлы проекта в обработку Git.
Добавленные файлы должны позеленеть. Сделайте первый commit. Commit – это этап изменений кода, который будет зафиксирован в репозитории.
Теперь пришло время поделиться результатами нашего труда с коллегами. Зарегистрируйтесь на сайте gitlab.com, создайте репозиторий проекта и сделайте «Push» из IDEA. Push отправит ваш «commit» на сервер, и он станет видимым для других разработчиков.
Укажите ссылку на созданный вами репозиторий
Если все прошло успешно, файлы проекта загрузятся на сервер Gitlab.
Теперь попробуем внести первую небольшую доработку в наш проект – например, добавить файл с документацией.
Создайте новую ветку c именем «feature/documentation».
Создайте файл readme.md, сделайте commit и push.
Теперь у вас на сервере в проекте есть две ветки: исходная - master, и новая - feature/documentation.
Создайте запрос на слияние веток на сервере gitlab.com.
Влейте изменения в основную ветку.
Заметьте, что в реальном проекте вам бы понадобилось получить одобрение (approve) от ваших коллег, чтобы сделать это.
В IDEA переключитесь на основную ветку.
Скачайте обновления, которые произошли в основной ветке к себе на компьютер
Убедитесь, что файл readme.md появился в основной ветке.
Когда будете приступать к новой задаче каждый раз следуйте этому алгоритму:
Создайте новую ветку от основной
Произведите доработку в новой ветке
Сделайте commit и push новой ветки на сервер
Создайте merge request на сервере на слияние новой и старой ветки
Сделайте merge на сервере
Переключитесь обратно на основную ветку в IDEA
Обновите основную ветку у себя на компьютере при помощи pull
Таким образом несколько программистов могут работать над одним проектом, не мешая друг другу. Каждый работает в своей ветке проекта, «переливая» изменения в основную ветку при помощи контролируемого коллегами merge request.
Безусловно, в учебных проектах с одним программистом, эта работа излишняя – можно просто последовательно делать commit и push в основную ветку по мере добавления функционала.
Продолжение следует
Комментарии (17)
smartello
05.07.2022 02:51+2непонятно что вы хотите описать. Зачем нужен экскурс в историю JDK и т.д.
Одно из преимуществ (пусть и не главное) микросервисной архитектуры - возможность писать на чём угодно.
Кстати, рекомендую использовать разные БД для разных сервисов и ваша жизнь станет намного приятнее.
mmMike
05.07.2022 07:28+3Использование SpringBoot для микро сервисов иногда чревато.
Простой сервис делающий, например, только select из БД и интегрированный, например с kafka или пусть даже с HTTP (пусть даже с тем же Tomcat что и Spring использует) при старте кушает ресурсы существенно меньше чем тот же сервис (с аналогичным функционалом) на SpringBoot c его hibernate и построениями зависимостей на старте.
Однако когда нужно поднять под сотню сервисов на одном сервере (сразу) это становится существенным.
Не понимаю это всеобщего "только на SpringBoot".
Ну да.. удобнее начиная с определенного объема исходного кода модуля. Но не все же упирается в "удобство разработки". Да и простые модули по объему кода и его "читаемости" ну что на SpringBoot что традиционно одинаково пишутся.
ABHuman
05.07.2022 10:13А что скажете про родной джавовский аналог Спринга?
Kopilov
05.07.2022 11:00Если Java EE, то как API, он весьма неплох. Реализация «от Оракла» — Glassfish, когда-то я с ним работал. Сейчас, специально для микросервисов, есть Quarkus, реализующий это же API.
mmMike
05.07.2022 11:14Glassfish сервер это контейнер сервлетов. Совсем и принципиально идеологически другой способ организации ПО чем у SpringBoot.
gkislin
05.07.2022 22:49+1Glassfish это Application Server
А под аналогом Spring, судя по всему, имелся в виду принцип IoC в Jakarta-уже-EE - спецификация CDI
Не лучший вариант для "экономии ресурсов" поднимать отдельный AS
Разве что в одном поднимать несколько приложений, но это несогласуется с концепцией микросервисов- каждому свое окружение.
mmMike
05.07.2022 11:18+1да и без всего этого можно.
У меня еще осталось ПО которое собирается и как war под Glassfish и как отдельный jar c встроенным Grizzy HTTP сервером.
Но, Glassfish скорее мертв чем жив. IMHO
Kopilov
05.07.2022 13:14+1Не спорю, что Glassfish мёртв. Quarkus, тем не менее, живее всех живых, и по API если не взаимозаменим, то гораздо ближе к классическим Java EE контейнерам, чем Spring.
Сравнивая с комментарием внизу, «привычная оболочка» лично для меня — это именно это API (JaxRS и прочее), и за него Ораклу спасибо. Когда Glassfish умер, пересесть на Quarkus не составило труда, а Spring пришлось бы учить заново.«без всего этого можно» — без чего именно и как именно, TCP-сокеты самому слушать? Можно, но зачем?
isden
05.07.2022 11:20+1Hibernate для работы с базой не обязателен, есть варианты (даже без ORM — JDBC например).
Для микросервисов есть специально заточенный для них Spring Cloud.mmMike
05.07.2022 11:27Ну я так про что и говорю.
Не нужен hibernate - пользуемся jdbc. Используем HTTP встроенный сервер - так там уже есть практически у всех своя реализация @Inject . И она хоть по проще, но за то быстрее работает (а даже 300..500 ms на старте экономии это не мало)
и получается, что от SpringBoot ну просто как привычная оболочка, без которой нормально и там быстро написать можно.
Удручает хайп и мода. Когда новенькие программеры даже не знают, что Java приложения можно и без SpringBoot. И что кроме JPA (а многие даже не знают увы, какая под крышкой SpringBoot реализация JPA) есть jdbc.. (Да вообще нифига не знают. Пользуются "магией" и примерами)
Вот ровно это я и хотел сказать.
isden
05.07.2022 11:35+5Spring/SpringBoot это не просто "привычная оболочка", а ключевые фичи, вроде IoC/DI, конфигурации и много всего еще. Удобный фреймворк. Без него можно обойтись (или есть аналоги разной степени похожести), но придется МНОГО писать руками и МНОГО тестировать.
nickD
06.07.2022 19:38Программы пишутся для программистов, а для оптимизации выполнения есть компиляторы и виртуальные машины, spring boot очень удобен для разработки, а если вам нужно, что то оптимизировать можно обратится к соответствующим инструментам. Нужно время старта посмотрите на Native Image graalvm.
LeshaRB
Установите IDEA Ultimate Edition и создайте с ее помощью новый проект
А почему именно Ultimate... ? Community с данной задачей не справится? Да и бесплатен он
Но для профессиональной разработки стандартом является использование IntelliJ IDEA от фирмы JetBrains
Откуда такая информация? Если я поставлю Eclipse, я не смогу заниматься профессиональной разработкой?
Инструкция у вас так понимаю для Windows пользователей... Вы просто пишите везде , скачайте и установите...
GBR-613
Это просто калька с английского. В английском слово standard обычно означает не то, что обязательно к исполнению, а то, что общепринято, на что в реальности все равняются.
Когда -то в Eclipse не было интеграции с Gradle. Может быть, сейчас ее добавили.