Русский
Русский
English
Статистика
Реклама

Java

Перевод Топ-5 курсов по Java для фуллстек-разработчиков

12.02.2021 12:08:58 | Автор: admin
В этом материале приведены сведения о пяти лучших курсах, предназначенных для тех, кто хочет начать карьеру в сфере фуллстек-разработки на Java. Роль подобных разработчиков стала в наши дни достаточно популярной. Многие компании нуждаются в таких специалистах. Эти специалисты, правда, пользуются не только Java. Среди применяемых ими инструментов можно, например, отметить Angular, Spring, REST API, HTML, CSS, различные системы управления базами данных.

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



Курсы, сведения о которых приведены в этом материале, способны помочь выйти на достаточно высокий уровень тому, кто ничего не знает о программировании на Java и о работе с другими технологиями. Автор материала подчёркивает тот факт, что он никак не связан с организациями, о курсах которых он рассказывает.

1. Java Full Stack Training (Sudaksha)


Компания Sudaksha Education Enterprise занимается подготовкой Java-программистов уже 12 лет. Её курсы по Java и обычные, и дистанционные, окончили около 50000 человек. Сейчас в компании имеется онлайн-курс по фуллстек-разработке на Java, ориентированный как на начинающих, так и на достаточно опытных программистов. Этот курс призван дать таким программистам полные и подробные сведения по необходимым для них вопросам. Среди технологий и инструментов, которые изучают на курсе помимо Java, можно отметить следующие: Spring Boot, JavaScript, SQL, HTML, CSS, BootStrap, Angular, REST, Maven, Spring Data JPA.

Сведения о курсе Java Full Stack Training опубликованы на платформе Course Report, специалисты которой отбирают качественные курсы по веб-разработке, программированию и безопасности.

Основные особенности курса:

  • Наличие инструктора.
  • Практические занятия.
  • Помощь в трудоустройстве.
  • Подготовка к собеседованиям с участием высококлассных специалистов.
  • По окончании курса выдаётся сертификат.
  • Курс предусматривает работу над проектами.

2. Full Stack Java developer Java + JSP + Restful WS + Spring (Udemy)


Платформа Udemy предлагает учебный курс, рассчитанный на начинающих. Он позволяет, во-первых, получить знания по фуллстек-разработке на Java, а во-вторых знакомит учащихся с сопутствующими технологиями. Среди них RESTful веб-сервисы, Spring Boot, JSP Servlets, Hibernate. В процессе прохождения курса можно освоить важные понятия Java-разработки и применить полученные знания на практике, создав, под руководством специалистов, веб-приложение.

Основные особенности курса:

  • Свободный график проведения занятий.
  • По окончании курса выдаётся сертификат.
  • Наличие учебных материалов.

3. Java Full Stack (Cognixia)


Компания Cognixia предлагает учебный курс по фуллстек-разработке на Java, слушатели которого, кроме прочего, имеют возможность освоить следующие темы: Node.js, Express.js, Mongoose, создание и развёртывание Angular-приложений, HTTP-сервисы и взаимодействие серверных приложений, MongoDB. Учиться тут можно либо очно, лично присутствуя в обычном классе, либо дистанционно, присутствуя во время занятий в виртуальной классной комнате. Курс рассчитан на людей, имеющих отношение к информационным технологиям: на веб-разработчиков, инженеров по программному обеспечению, технических менеджеров, дизайнеров, специалистов по сетевым технологиям, выпускников технических ВУЗов, системотехников.

Основные особенности курса:

  • В процессе прохождения курса учащимся выставляют оценки.
  • Учебные проекты.
  • Сертификат, признаваемый потенциальными работодателями.

4. Full Stack Java Developer (Simplilearn)


Программа Full Stack Java Developer, предлагаемая компанией Simplilearn Solutions совместно с Hirist и HackerEart предназначена для новичков и профессионалов. Обширная программа курса рассчитана на 6 месяцев, выпускникам гарантируется трудоустройство. В процессе освоения курса учащиеся получают серьёзные знания по созданию, тестированию и развёртыванию приложений. Среди технологий и инструментов, затрагиваемых в курсе, можно отметить следующие: Angular, Docker, CSS, Git, HTML, Jenkins, JUnit, Maven, MySQL, RabbitMQ, Selenium, TypeScript, MongoDB. Учащимся предоставляется шестимесячное профессиональное членство на Hirist, что даёт доступ к вебинарам и к мероприятиям, ориентированным на трудоустройство в сфере информационных технологий.

Основные особенности курса:

  • Создание 4 проектов профессионального уровня.
  • Освоение около 30 инструментов и навыков, востребованных в индустрии информационных технологий.
  • Сертификат, признаваемый потенциальными работодателями.
  • Пожизненный доступ к материалам курса.

5. Java Full Stack Developer (WileyNXT)


Платформа WileyNXT предлагает всем желающим курс Java Full Stack Developer, который можно проходить, не покидая удобных домашних условий. Обширная учебная программа курса содержит сведения о структурном и объектно-ориентированном программировании на Java, о работе с SQL, о веб-разработке, о фронтенд- и бэкенд-фреймворках, о программном обеспечении для веб-разработки, об основах системной инженерии и DevOps.

Основные особенности курса:

  • Лаборатории для изучения программирования методом погружения.
  • Учебные материалы мирового уровня от компании Wiley.
  • Создание и наполнение профиля на GitHub.
  • Всемирно известные преподаватели.

Где и как вы учились бы, если бы решили освоить фуллстек-разработку на Java?

Подробнее..

Как катать релизы несколько раз в день и спать спокойно. Доклад Яндекса

26.02.2021 12:14:08 | Автор: admin
Высокие темпы разработки сопряжены с рисками, влияющими на отказоустойчивость и стабильность особенно если хочется экспериментировать и пробовать разное. Разработчик Маркета Мария Кузнецова рассказала о релизном цикле своей команды от и до, а также о мониторингах и других вещах, позволяющих обновлять сервис со скоростью три релиза в день.



Всем привет! Я представляю бэкенд-разработку курьерской платформы. Поговорить хочу о том, как нам удается, с одной стороны, двигаться быстро, а, с другой стороны, не потонуть в ворохе и потоке проблем и ошибок.

(...) Сейчас у нас в среднем выкатывается по три релиза в день.



Стек технологий, которые мы используем типичен для Java-приложений Маркета. Мы используем 11-ю Java, Spring, PostgreSQL для хранения данных, Liquibase для накатывания миграций и Quartz для регулярных Cron-задач. Конечно, у нас реализовано много интеграций с внутренними сервисами.

Начать я хочу с того, как у нас устроен процесс релиза.

1. Релизы


С самого начала проекта мы живем в парадигме trunk-based development. Чтобы код попал в продакшен, нужно поставить пул-реквест и пройти код-ревью. Причем в пул-реквесте запускаются также и прикоммитные проверки, в первую очередь это юнит-тесты и функциональные тесты.

Среды у нас сейчас только две продакшен и тестинг. Когда код-ревью пройдено и код попал в trunk, запускается вот такой релизный пайплайн.



Дальше я покажу все шаги подробнее.



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



Все сервисы Маркета, за очень редким исключением, имеют минимум два инстанса, минимум один в каждом дата-центре. Раскатка релиза происходит поэтапно. Вначале один инстанс, или процент, если инстансов много, потом все остальные. Если вначале что-то идет не так, выкатка дальше не пойдет, релиз останавливается и нужно идти разбираться.

Всё, релиз раскатили. Идёт шаг проверки. По сути мы заменили ручной регресс тестирования на интеграционные тесты, но также добавили нагрузочные тесты. Самое главное: на каждом шаге мы пытаемся выявить проблему и не допустить, чтобы плохой код попал в продакшен.

Конечно, у нас есть ограничения при выкатке релиза. Парадигма trunk-based development диктует то, что не должно быть долго живущих feature branches, и получается так, что в trunk может оказаться незаконченная функциональность.

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

При чем здесь кот Шредингера? Часто новая функциональность в продакшене должна и работать, и не работать одновременно: для каких-то пользователей должна быть включена, а для других все должно работать по-старому. Можно было бы, конечно, поднять отдельный инстанс, бэкенд с новой функциональностью, пустить туда какую-то часть пользователей, а остальных оставить на старых.

Но такой подход звучит дорого.

2. Feature toggles


Поэтому мы пришли к тому, что стали использовать feature toggles. Toggles с английского переводится как переключатель, и это в точности описывает его предназначение.

if (configurationService.isBooleanEnabled(NEW_FEATURE_ENABLED)) {    //new feature here} else {        //old logic}

Можно выкатить код и пока не использовать его в продашкене, например, ждать поддержки фронтенда или же дальше его реализовывать.

Нам очень важно уметь включать-выключать функциональность по отмашке от коллег. Поэтому свой toggles мы сложили в базу.

public class User {    private Map<String, UserProperty> properties = new HashMap<>();    String getPropertyValue(String key) {        UserPropertyEntity userProperty = properties.get(key);        return userProperty == null ? null : userProperty.getValue();    }}

Поскольку функциональность не всегда нужно сразу включать на всех пользователей, сделали feature toggles на пользователя и тоже положили их в базу. Так мы можем точечно включать функциональность, и это дает возможность провести эксперименты. Например, мы делали новую функциональность под кодовым названием Звонки. Это напоминание курьеру о том, что у него скоро доставка. (...) Такая функциональность сильно перестраивала процесс работы курьера, и нам было важно проверить, как процесс летит в реальном времени, в реальной жизни.

По первым результатам эксперимента мы поняли, что после звонка курьеру некуда записать комментарии от пользователя. Поэтому срочно добавили комментарии и возможность работы с ними. И дальше уже пользователей в эксперимент добавляли только с этой функциональностью. С помощью feature toggles у нас сделана выкатка на процент пользователей. Мы храним версию и требуем от курьера, чтобы у него была установлена именно она. В противном случае просим его обновиться.



Конечно, у такого подхода есть минусы. Toggles скапливаются, и здесь ничего не остается, кроме как их убирать. Также увеличивается сложность тестов, потому что проверять свой код нужно во всех режимах работы toggles. Кроме того, toggles лежат в базе, поэтому получается лишний поход в БД. Здесь ничего не остается, кроме как поставить кэш. Какие плюсы мы за это получаем?



Мы получаем возможность спокойно жить в парадигме trunk based development. Также можем проводить точечные эксперименты на пользователях.

Я уже приводила пример со звонками. Мы поддерживаем не просто изменение кода зачастую это изменение бизнес-процессов. Нам нужно проверять еще и то, насколько готов офлайн, как хорошо мы донесли это до курьеров, что мы от них хотим.

Мобильное приложение обычно тоже раскатывается не сразу на всех пользователей, а вначале на какой-то процент из них. И мы можем получить такую ситуацию, что в зависимости от пользователя бэкенд должен иметь разную логику. Это не только изменения в API, но и именно изменения в бизнес-логике. Toggles нам тоже помогают решить такую задачу.

Остался вопрос про деградацию. Мы обслуживаем офлайн-процесс, и в случае любых проблем с ПО нам нужно сделать так, чтобы самая важная часть функциональности работала. Чтобы курьеры могли выдать посылку, выбить чек и понять, куда ехать дальше.

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

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

3. Метрики и мониторинги


Поэтому дальше я хочу поговорить о метриках и мониторингах. Сразу скажу: в этой части мы не будем обсуждать, какие системы сбора и визуализации метрик использовать. Для этого есть опенсорс-решения. У себя для сбора метрик мы используем Graphite и, как и для мониторингов, внутреннюю систему.

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



Но предлагаю рассмотреть, что это такое, на примере.



Метрика обычно представляется как график, он описывает какой-то параметр нашей системы. А мониторинг это событие, превышение заданного ранее порога и какое-то действие, которое необходимо предпринять при превышении порога.

Какие могут быть действия? Конечно, самое важное уведомить ответственных: написать в мессенджер или позвонить. Реже запустить процесс откатки последнего релиза. У себя в проекте мы такой вариант не используем. Еще есть вариант мониторинга, который мы называем загорается лампочка. Произошло интересующее нас событие, и оно отобразилось в интерфейсе мониторинга. Дальше тоже происходит действие уведомить ответственных или еще что-то.



Мы говорим про Java-приложение, а оно должно быть где-то запущено, будь то контейнеры или железные машины. Ресурсы и в том, и в другом случае для нас конечны, нам нужно понимать, как мы их используем. Наши приложения мы запускаем во внутреннем облаке, облако нам предоставляет всю подобную информацию. Информацию о ресурсах стоит собирать не только на контейнерах, где живет ваше приложение, но и там, где работает ваше хранилище.

На слайде пример, как нам в базе перестало хватать CPU.

Окей, у нас Java-приложение, и, конечно, стоит собирать информацию о состоянии JVM.



Мы используем Spring, поэтому для решения такой задачи хорошо подходит библиотека Spring Boot Actuator. Она добавляет endpoint в ваше приложение, и к этому endpoint можно обратиться по http и получить необходимую информацию о памяти или что-то еще. Окей, приложение запущено. Дальше оно вообще работает или нет? Что с ним происходит? Можно отправлять запросы в это приложение или нет?

@RestController@RequiredArgsConstructorpublic class MonitoringController {    private final ComplexMonitoring generalMonitoring;    private final ComplexMonitoring pingMonitoring;    @RequestMapping(value = "/ping")    public String ping() {        return pingMonitoring.getResult();    }    @RequestMapping(value = "/monitoring")    public String monitoring() {        return generalMonitoring.getResult();    }}

Такие вещи нужно понимать не только нам, но и балансеру. Для этого мы добавляем в приложение контроллер с двумя методами Ping и Monitoring. Рассмотрим вначале Ping. Он отвечает на вопросы, живо ли приложение, можно ли отправлять на него запросы. И отвечает он это в первую очередь не нам, но балансеру. Но мы же используем этот метод для мониторинга того, живо приложение или нет.

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

public enum MonitoringStatus { OK, WARNING, CRITICAL;}@RequiredArgsConstructorpublic class MonitoringEvent { private final String name; private volatile long validTill; private volatile MonitoringStatus status;}

Мониторинги строятся на системе статусов и приоритетов между ними. Событие мониторинга в минимальном варианте описывается именем, временем, до которого действует мониторинг, но и статусом. По истечении этого времени мониторинг считается пройденным, погашенным и переходит в статус ok.

public interface ComplexMonitoring { void addTemporary(String name, MonitoringStatus status, long validTillMilis); Result getResult(); //тут можно делать проверку для статусов в MonitoringEvent} 

Получается такой простейший интерфейс мониторинга. Добавить или обновить событие и вернуть текущее состояние мониторинга в оговоренном формате.

У нас есть клиент мобильное приложение, нужно понимать, как качественно мы отвечаем клиенту и какая вообще нагрузка на нас идет. Поэтому стоит собирать RPS, тайминги и пятисотки.



Как мерить RPS, понятно из названия. Стоит отметить, что хорошо смотреть как общий RPS по приложению, так и по отдельным методам API. А вот с двумя остальными с таймингами и пятисотками все не так понятно. В каждый момент времени может быть много запросов и, соответственно, много времен ответов. Всю эту информацию нужно агрегировать. Для этого хорошо подходят перцентили. Этот термин пришел к нам из статистики.

Чтобы рассказать, что это такое, на слайде есть нижний график, на нем выделена точка в 400 мс. Это график 99 перцентиля какого-то метода из нашего API. Что значат эти 400 мс? Что в этот момент 99% запросов отрабатывали не хуже 400 мс.

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

Как мы собираем RPS, тайминги и пятисотки? Когда запрос оказался у нас в инфраструктуру, он попадает на L7 balancer. А дальше он не сразу попадает в приложение, перед этим есть nginx.



А вот уже из nginx он попадает в приложение. У nginx есть access.log, в который можно собирать всю необходимую информацию. Это коды ответа, время ответа и сам запрос.



Часто, когда возникают проблемы с временем ответа или пятисотки, стоит посмотреть, что в это время было с хранилищем.

У нас PostgreSQL, поэтому мы именно его мониторим и смотрим. Мы строим все эти графики не сами они нам предоставляются облаком, в котором развернута наша база. Что у нас есть? Количество запросов, транзакций, лаг репликации, среднее время транзакции и так далее. На самом деле на этих графиках представлен факап, который у нас произошел.



Вообще-то мы работаем с реальным процессом, и он нам тоже диктует, на что нам нужно посмотреть. Регистрацию нежелательных событий мы уже рассматривали, для этого хорошо подходит метод Monitoring, он был ранее.

Осталась статистика по хранилищу. Хранилище вообще может многое рассказать о состоянии нашей системы. Можно считать показатели: как, например, количество заказов за день, так и просто попадание в интервал доставки. Можно искать противоречия статусной модели. Так мы отслеживаем чеки, с которыми возникли проблемы.

public class MetricQueryRealJobExecutor { private static final RowMapper<Metric> METRIC_ROW_MAPPER = BeanPropertyRowMapper.newInstance(Metric.class); private final JdbcTemplate jdbcTemplate; public void doJob(MetricQuery task) { List<Metric> metrics = jdbcTemplate.query(task.getQuery(), METRIC_ROW_MAPPER); metrics.forEach(metric -> KEY_VALUE_LOG.info(KeyValueLogFormat.format(metric)) ); } @Data private static class Metric { private String key; private double value; }} 

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

Сложили в базу такую тройку: уникальный ключ для метрики, сам запрос, в котором можно эту метрику посчитать, и Cron-выражение, когда считать. То есть в базе получилась тройка: ключ запрос cron expression. А над всей этой тройкой сделали Cron-задачу, которая достает ее из хранилища и добавляет к общему пулу Cron-задач. Дальше эта задача выполняется.

Итого, что мы получаем?

  • Плохой код не должен попадать в продакшен, для этого мы ставим всевозможные преграды: тесты, стрельбы, мониторинги. Задача без тестов не считается сделанной. Лучше заниматься оптимизацией работы тестов, чем получить проблему в продакшене.
  • Feature toggles помогают нам управлять логикой работы бэкенда, а мы, в свою очередь, можем легко управлять toggles, и их плюсы все-таки перевешивают минусы.
  • Мы должны уметь быстро обнаруживать проблему, в идеале раньше, чем ее заметят наши пользователи. Но ее мало обнаружить, нужно еще ее интерпретировать. Поэтому собирайте много метрик о состоянии системы. Это помогает в поиске проблемы.

И, конечно, давайте будем писать код без багов, тогда у нас вообще все будет хорошо. На этом у меня все.
Подробнее..

Recovery mode Лучший язык программирования

24.02.2021 10:16:44 | Автор: admin

Этот вопрос на первый взгляд звучит вызывающе, едва ли не табуирован, на него часто всплывает заезженный ответ, что все субъективно и зависит от задачи. Так ли это на самом деле?
Возвав к логике и здравому смыслу, попытаемся выявить наиболее объективные критерии сравнения языков программирования. Кто не боится разочароваться, увидев свой любимый язык заклейменным и преданным позору, давайте рискнем порассуждать, что лучше подходит для индустриальной разработки?

Принципы отбора

Экосистем много, начинать с выбранных достоинств какой-то одной глупо, поэтому действовать будем методом исключения по ясным пунктам. Все сравнения опираются на объективные бенчмарки.

Поддерживаемость

Прежде всего, язык должен быть достаточно мейнстримным, чтобы проект на нем был поддерживаемым. Сразу выбрасываем за борт всю экзотику и функциональщину вроде Haskell, Elixir, Nim, Erlang умирающий Ruby туда же. По этой же причине отбрасываем и всевозможные языки закрытых (Swift) и тем более окукленных по паспорту (1C например) экосистем.

Типизация

Общая практика в индустрии показывает что слабая типизация однозначно вредит читаемости, поддерживаемости и порождает большое количество ошибок, поэтому выкидываем JavaScript и PHP. Далее, замечаем что динамическая типизация ухудшает скорость работы, а варианты компиляции традиционно динамических языков, отличаются плохой поддерживаемостью, и выглядят скорее как извращение приделанное сбоку костылями, поэтому за бортом остаются и строго-типизированные, но динамические Python и TypeScript.

В сухом остатке

У нас остались мейнстримные, строго-статически-типизированные C#, Java, C++, C и восходящие в последнее время к ним Kotlin, Go и Rust. Не каждый пожелает (а еще меньше смогут) использовать C++ в большом проекте, поэтому, несмотря на лучшие пока показатели по скорости, отложим его вместе с более низкоуровневым Си для узких мест.

Java vs C#

C# и Java близнецы. Экосистемы обоих языков на данный момент открыты и очень развиты. Java здесь выходит вперед за счет большего количества инструментов, библиотек, конкуренции и вариантов выбора. Но C# более стройный синтаксически, в нем исправлены известные проблемы Java (слабые дженерики пропадающие на этапе компиляции, отсутствие пользовательских значимых типов на стеке, сочетаемость значимых и ссылочных типов как List). Кроме того у .NET в целом лучшие показатели по скорости и памяти.

Kotlin

Долгое время C# выглядел практически идеальным по кроссплатформености, высокоуровневости абстракций и скорости приближающейся местами к С++. Однако практика с Kotlin показала, что он превосходит C# и по концепциям, и по синтаксической стройности. И вот почему. Если C# идет по пути добавления в ядро языка все новых и новых абстракций и ключевых слов, то в Kotlin весь синтаксический "сахар" базируется на встраиваемых лямбдах и функциях области видимости и вынесен в стандартную библиотеку. В чем здесь преимущество? Почти любую фичу, казалось бы языка, в Kotlin можно прочитать в стандартной библиотеке и понять как любой другой код. Kotlin, правда, немного уступает C# по скорости, но лишь потому что компилируется в байт-код Java.

Go?

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

Rust?

Начать следует с того что у Rust порог входа выше чем у C++, уже потому что на C++ сразу можно писать как на любом другом высокоуровневом ЯП, предоставив стандартной библиотеке разруливать работу с памятью. Rust же не даст спрятаться от решения вопросов безопасности и размещения в памяти и из-за этой необходимости, он (внезапно!) превращается в достаточно низкоуровневый язык, сравнимый скорее даже с Си, чем с C++.

Вывод

Мы по возможности непредвзято рассмотрели объективные факторы способствующие индустриальной разработке. Вывод из них все же неизбежно будет субъективен. Поэтому привествуются альтернативные выводы!
Итак, по моему мнению, на текущий момент, для написания большинства кроссплатформенных приложений удобнее всего использовать Kotlin, дополняя его C++ в тех случаях когда требуется скорость. Kotlin прекрасно подходит для бекендов, язык экосистемы Android по умолчанию, без проблем компилируется в JS и WebAssembly для браузеров, с небольшими приседаниями может быть использован для iOS, а с помощью jpackage легко подготовить самодостаточный исполняемый файл для Windows, macOS, Linux в "родном" формате.

Подробнее..

Шаблон Kotlin микросервисов

27.02.2021 20:23:19 | Автор: admin

Для разработчиков не секрет, что создание нового сервиса влечет за собой немало рутиной настройки: билд скрипты, зависимости, тесты, docker, k8s дескрипторы. Раз мы выполняем эту работу, значит текущих шаблонов IDE недосточно. Под катом мои попытки автоматизировать все до одной кроссплатформенной кнопки "сделать хорошо" сопровождаемые кодом, примерами и финальным результатом.
Если перспективы создания сервисов в один клик с последующим автоматическим деплоем в Digital Ocean звучат заманчиво, значит эта статья для вас.

Начнем создавать наш шаблон и прежде всего рассмотрим организацию сборки. Несмотря на любовь многих к maven за его простоту и декларативность, использовать будем gradle, ибо он современее и позволяет писать скрипт сборки на одном языке с проектом. Помимо самого Kotlin плагина, нам потребуется еще два:

plugins {  kotlin("jvm") version "1.4.30"  // Чтобы собрать fat jar  id("com.github.johnrengelman.shadow") version "6.1.0"  // Чтобы собрать self-executable приложение с jvm  id("org.beryx.runtime") version "1.12.1"}

Из зависимостей, в качестве серверного фреймворка был выбран "родной" для Kotlin Ktor. Для тестирования используется связка testNG + Hamkrest с его выразительным DSL, позволяющим писать тесты таким образом:

assertThat("xyzzy", startsWith("x") and endsWith("y") and !containsSubstring("a"))

Собираем все вместе, ориентируясь на Java 15+

dependencies {  // для парсинга аргументов командой строки  implementation("com.github.ajalt.clikt:clikt:3.1.0")  implementation("io.ktor:ktor-server-netty:1.5.1")  testImplementation("org.testng:testng:7.3.0")  testImplementation("com.natpryce:hamkrest:1.8.0.1")  testImplementation("com.nhaarman.mockitokotlin2:mockito-kotlin:2.2.0")}application {  @Suppress("DEPRECATION") // for compatibility with shadowJar  mainClassName = "AppKt"}tasks {  test {    useTestNG()  }  compileKotlin {    kotlinOptions {      jvmTarget = "15"    }  }}

В исходный код генерируемый шаблоном по умолчанию добавлен entry-point обработки аргументов командой строки, заготовка ддя роутинга, и простой тест (заодно служащий примером использоования testNG с Hamkrest).
Из того что следует отметить, позволил себе небольшую вольность с официальным Kotlin codestyle чуть-чуть поправив его в .editorsconfig:

[*.{kt, kts, java, xml, html, js}]max_line_length = 120indent_size = 2continuation_indent_size = 2

В первую очередь, это вопрос вкуса, но ещё так в одну строчку помещается больше кода, что помогает избежать переноса в выражениях внутри класса и функции, лямбды, например.
Чтобы собрать self-executable jar используйте команду

gradle clean test shadowJar

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

Осталось написать Dockerfile, его привожу целиком. Сборка и запуск разделены и производятся в два этапа:

# syntax = docker/dockerfile:experimentalFROM gradle:jdk15 as builderWORKDIR /appCOPY src ./srcCOPY build.gradle.kts ./build.gradle.ktsRUN --mount=type=cache,target=./.gradle gradle clean test shadowJarFROM openjdk:15-alpine as backendWORKDIR /rootCOPY --from=builder /app/*.jar ./app

Работать сервис будет в контейнере с jdk (а не jvm), ради простоты ручной диагностики с помощью jstack/jmap и других поставляемых с jdk инструментов.
Сконфигурируем запуск приложения при помощи Docker Compose:

version: "3.9"services:  backend:    build: .    command: java -jar app $BACKEND_OPTIONS    ports:      - "80:80"

Теперь мы можем запускать наш сервис на целевой машине, без дополнительных зависимостей в виде Jdk/Gradle, при помощи простой команды

docker-compose up

Как деплоить сервис в облако? Выбрал Digital Ocean по причине дешевой стоимости и простоты управления. Благодаря тому что мы только что сконфигурировали сборку и запуск в контейнере, можно выбрать наш репозиторий с проектом в разделе Apps Platform и... все! Файлы конфигурации Docker будут подцеплены автоматически, мы увидим логи сборки, а после этого получим доступ к веб адресу, логам приложения, консоли управления, простым метрикам потребления памяти и процессорного времени. Выглядит это удовольствие примерно так и стоит 5$ в месяц:

При последующих изменениях в master ветке репозитория, передеплой запустится автоматически. Очень удобно. И наконец, все описанное в статье, подробно задокументировано в README.md файле шаблона проекта, чтобы после создания последующая сборка и деплой не вызывали сложностей.

Исползьовать описаный шаблон чтобы получить готовый репозиторий, можно просто нажав кнопочку "Use this template"на GitHub:
github.com/demidko/Projekt

Или, если вам нужен варинт с портабельным jvm:
github.com/demidko/Projekt-portable

Интересно услышать предложения, комментарии и критику.

Подробнее..

Pattern matching в Java 8

27.02.2021 22:08:03 | Автор: admin
Многие современные языки поддерживают сопоставление с образцом (pattern matching) на уровне языка.
Язык Java не является исключениям. И в Java 16 будет добавлено поддержка сопоставление с образцом для оператора instanceof, как финальной фичи.
В будущем надеемся, что сопоставление с образцом будем расширено и для других языковых конструкций.

Сопоставление с образцом раскрывают перед разработчиком возможность писать код более гибко и красивее, при этом оставляя его понятным.
Но что если нельзя перейти с тех или иных причин на новые версии Java. Благо используя возможности Java 8, можно реализовать некоторые возможности pattern matching в виде библиотеки.
Рассмотрим некоторые паттерны, и как их можна реализовать с помощью простенькой библиотеки.

Constant pattern позволяет проверить на равность с константами. В Java оператор switch позволяет проверить на равность числа, перечисления и строки. Но иногда хочется проверить на равность константы объектов используя метод equals().

switch (data) {      case new Person("man")    -> System.out.println("man");      case new Person("woman")  -> System.out.println("woman");      case new Person("child") -> System.out.println("child");              case null                 -> System.out.println("Null value ");      default                   -> System.out.println("Default value: " + data);};


Подобный код можна написать следующим образом. При этом под капотом осуществляется сравнения значений и проверка их в операторе if. Можно использовать как форме утверждение так и как выражения.
Так же можно очень просто работать с диапазонами значений.

import static org.kl.jpml.pattern.ConstantPattern.*;matches(data).as(      new Person("man"),    () ->  System.out.println("man");      new Person("woman"),  () ->  System.out.println("woman");      new Person("child"),  () ->  System.out.println("child");              Null.class,           () ->  System.out.println("Null value "),      Else.class,           () ->  System.out.println("Default value: " + data));matches(data).as(      or(1, 2),    () ->  System.out.println("1 or 2");      in(3, 6),    () ->  System.out.println("between 3 and 6");      in(7),       () ->  System.out.println("7");              Null.class,  () ->  System.out.println("Null value "),      Else.class,  () ->  System.out.println("Default value: " + data));


Tuple pattern позволяет проверить на равность нескольких перемен с константами одновременно.

var (side, width) = border;switch (side, width) {      case ("top",    25) -> System.out.println("top");      case ("bottom", 30) -> System.out.println("bottom");      case ("left",   15) -> System.out.println("left");              case ("right",  15) -> System.out.println("right");       case null         -> System.out.println("Null value ");      default           -> System.out.println("Default value ");};for ((side, width) : listBorders) {      System.out.println("border: " + [side + "," + width]); }


При этом кроме использования в форме switch, можно разложить на сопоставляющие или пройти последовательно в цикле.

import static org.kl.jpml.pattern.TuplePattern.*;let(border, (String side, int width) -> {    System.out.println("border: " + side + "," + width);});matches(side, width).as(      of("top",    25),  () -> System.out.println("top");      of("bottom", 30),  () -> System.out.println("bottom");      of("left",   15,  () -> System.out.println("left");              of("right",  15),  () -> System.out.println("right");               Null.class,    () -> System.out.println("Null value"),      Else.class,    () -> System.out.println("Default value"));foreach(listBorders, (String side, int width) -> {     System.out.println("border: " + side + "," + width); }


Type test pattern позволяет одновременно сопоставить тип и извлечь значение переменной.

switch (data) {      case Integer i  -> System.out.println(i * i);      case Byte    b  -> System.out.println(b * b);      case Long    l  -> System.out.println(l * l);              case String  s  -> System.out.println(s * s);      case null       -> System.out.println("Null value ");      default         -> System.out.println("Default value: " + data);};


В Java для этого нам нужно сначала проверить тип, привести к типу и потом присвоить новой переменной. С помощью такого паттерна код стает на много проще.

import static org.kl.jpml.pattern.VerifyPattern.matches;matches(data).as(      Integer.class, i  -> { System.out.println(i * i); },      Byte.class,    b  -> { System.out.println(b * b); },      Long.class,    l  -> { System.out.println(l * l); },      String.class,  s  -> { System.out.println(s * s); },      Null.class,    () -> { System.out.println("Null value "); },      Else.class,    () -> { System.out.println("Default value: " + data); });


Guard pattern позволяет одновременно сопоставить тип и проверить на условия.

switch (data) {      case Integer i && i != 0     -> System.out.println(i * i);      case Byte    b && b > -1     -> System.out.println(b * b);      case Long    l && l < 5      -> System.out.println(l * l);      case String  s && !s.empty() -> System.out.println(s * s);      case null                    -> System.out.println("Null value ");      default                      -> System.out.println("Default: " + data);};


Подобную конструкцию можно реализовать следующим образом. Чтобы упростить написания условий, можно использовать следующее функции для сравнения: lessThan/lt, greaterThan/gt, lessThanOrEqual/le, greaterThanOrEqual/ge, equal/eq, notEqual/ne. А для того чтобы опустить условия можно пременить: always/yes, never/no.

import static org.kl.jpml.pattern.GuardPattern.matches;matches(data).as(                 Integer.class, i  -> i != 0,  i  -> { System.out.println(i * i); },      Byte.class,    b  -> b > -1,  b  -> { System.out.println(b * b); },      Long.class,    l  -> l == 5,  l  -> { System.out.println(l * l); },      Null.class,    () -> { System.out.println("Null value "); },      Else.class,    () -> { System.out.println("Default value: " + data); });matches(data).as(                 Integer.class, ne(0),  i  -> { System.out.println(i * i); },      Byte.class,    gt(-1), b  -> { System.out.println(b * b); },      Long.class,    eq(5),  l  -> { System.out.println(l * l); },      Null.class,    () -> { System.out.println("Null value "); },      Else.class,    () -> { System.out.println("Default value: " + data); });


Deconstruction pattern позволяет одновременно сопоставить тип и разложить объект на составляющие.

let (int w, int h) = figure; switch (figure) {      case Rectangle(int w, int h) -> out.println("square: " + (w * h));      case Circle   (int r)        -> out.println("square: " + (2 * Math.PI * r));      default                      -> out.println("Default square: " + 0);};   for ((int w, int h) :  listFigures) {      System.out.println("square: " + (w * h));}


В Java для этого нам нужно сначала проверить тип, привести к типу, присвоить новой переменной и только тогда через геттеры доступиться к полям класса.

import static org.kl.jpml.pattern.DeconstructPattern.*;Figure figure = new Rectangle();let(figure, (int w, int h) -> {      System.out.println("border: " + w + " " + h));});matches(figure).as(      Rectangle.class, (int w, int h) -> out.println("square: " + (w * h)),      Circle.class,    (int r)        -> out.println("square: " + (2 * Math.PI * r)),      Else.class,      ()             -> out.println("Default square: " + 0));   foreach(listRectangles, (int w, int h) -> {      System.out.println("square: " + (w * h));});


При этом чтобы получить составляющее, класс должен иметь один или несколько деконструирующих методов. Эти методы должны быть помечены аннотаций Extract.
Все параметры должны быть открытыми. Поскольку примитивы нельзя передать в метод по ссылке, нужно использовать обертки на примитивы IntRef, FloatRef и т.д.
Чтобы уменьшить оверхед с использованием рефлексии, используется кеширования и прийомы с стандартным классом LambdaMetafactory.

@Extractpublic void deconstruct(IntRef width, IntRef height) {      width.set(this.width);      height.set(this.height); }


Property pattern позволяет одновременно сопоставить тип и доступиться к полям класса по их именам.

let (w: int w, h:int h) = figure; switch (figure) {      case Rectangle(w: int w == 5,  h: int h == 10) -> out.println("sqr: " + (w * h));      case Rectangle(w: int w == 10, h: int h == 15) -> out.println("sqr: " + (w * h));      case Circle   (r: int r) -> out.println("sqr: " + (2 * Math.PI * r));      default                  -> out.println("Default sqr: " + 0);};   for ((w: int w, h: int h) :  listRectangles) {      System.out.println("square: " + (w * h));}


Это упрощенная форма деконструирующего паттерна, где нужны только конкретные поля класса разложить.
Чтобы уменьшить оверхед с использованием рефлексии, используется кеширования и прийомы с стандартным классом LambdaMetafactory.

import static org.kl.jpml.pattern.PropertyPattern.*;  Figure figure = new Rectangle();let(figure, of("w", "h"), (int w, int h) -> {      System.out.println("border: " + w + " " + h));});matches(figure).as(      Rect.class,    of("w", 5,  "h", 10), (int w, int h) -> out.println("sqr: " + (w * h)),      Rect.class,    of("w", 10, "h", 15), (int w, int h) -> out.println("sqr: " + (w * h)),      Circle.class,  of("r"), (int r)  -> out.println("sqr: " + (2 * Math.PI * r)),      Else.class,    ()                -> out.println("Default sqr: " + 0));   foreach(listRectangles, of("x", "y"), (int w, int h) -> {      System.out.println("square: " + (w * h));});


Также для упрощения именования полей можно использовать другой способ с ссылками на методы.

Figure figure = new Rect();let(figure, Rect::w, Rect::h, (int w, int h) -> {      System.out.println("border: " + w + " " + h));});matches(figure).as(      Rect.class,    Rect::w, Rect::h, (int w, int h) -> System.out.println("sqr: " + (w * h)),      Circle.class,  Circle::r, (int r)  -> System.out.println("sqr: " + (2 * Math.PI * r)),      Else.class,    ()                  -> System.out.println("Default sqr: " + 0));   foreach(listRectangles, Rect::w, Rect::h, (int w, int h) -> {      System.out.println("square: " + (w * h));});


Position pattern позволяет одновременно сопоставить тип и проверить значение полей в порядке объявления.

switch (data) {      case Circle(5)   -> System.out.println("small circle");      case Circle(15)  -> System.out.println("middle circle");      case null        -> System.out.println("Null value ");      default          -> System.out.println("Default value: " + data);};


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

import static org.kl.jpml.pattern.PositionPattern.*;matches(data).as(                 Circle.class,  of(5),  () -> { System.out.println("small circle"); },      Circle.class,  of(15), () -> { System.out.println("middle circle"); },      Null.class,            () -> { System.out.println("Null value "); },      Else.class,            () -> { System.out.println("Default value: " + data); });


Также если разработчик не хочет проверять некоторые поля, эти поля должны быть помечены аннотаций Exclude. Эти поля должны быть объявлены последними.

class Circle {      private int radius;              @Exclude      private int temp; }


Static pattern позволяет одновременно сопоставить тип и деконструировать объект используя фабричные методы.

 switch (some) {      case Result.value(var v) -> System.out.println("value: " + v);      case Result.error(var e) -> System.out.println("error: " + e);      default                    -> System.out.println("Default value");};


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

import static org.kl.jpml.pattern.StaticPattern.*;matches(figure).as(      Result.class, of("value"), (var v) -> System.out.println("value: " + v),      Result.class, of("error"), (var e) -> System.out.println("error: " + e),      Else.class, () -> System.out.println("Default value")); 


Sequence pattern позволяет проще обрабатывать последовательности данных.

List<Integer> list = ...;  switch (list) {      case empty()     -> System.out.println("Empty value");      case head(var h) -> System.out.println("list head: " + h);      case tail(var t) -> System.out.println("list tail: " + t);                  default          -> System.out.println("Default value");};


Используя библиотечные методы можно просто работать с последовательностями данных.

import static org.kl.jpml.pattern.SequencePattern.*;List<Integer> list = List.of(1, 2, 3);matches(figure,      empty() ()      -> System.out.println("Empty value"),      head(), (var h) -> System.out.println("list head: " + h),      tail(), (var t) -> System.out.println("list tail: " + t),            Else.class, ()  -> System.out.println("Default value"));   


Также для упрощения кода, можно использовать следующее функции, которые можно увидеть в современных языках как языковые фичи или функции.

import static org.kl.jpml.pattern.CommonPattern.*;var rect = lazy(Rectangle::new);var result = elvis(rect.get(), new Rectangle());   with(rect, it -> {   it.setWidth(5);   it.setHeight(10);});   when(    side == Side.LEFT,  () -> System.out.println("left  value"),    side == Side.RIGHT, () -> System.out.println("right value"));   repeat(3, () -> {   System.out.println("three time");)   int even = self(number).takeIf(it -> it % 2 == 0);int odd  = self(number).takeUnless(it -> it % 2 == 0);


Как можно видеть pattern matching сильный инструмент, который намного упрощает написание кода. Используя возможности Java 8 можно сэмулировать возможности pattern matching самыми средствами языка.

Исходной код библиотеки можно посмотреть на github: link. Буду рад отзывам, предложениям по улучшению.
Подробнее..
Категории: Kotlin , Java

Односторонние и двусторонние отношения в Hibernate

14.02.2021 16:19:02 | Автор: admin

Всем нам хорошо известен ответ на вопрос, какими могут быть отношения между сущностями в Hibernate и JPA. Вариантов всего четыре:

  • OneToOne - один к одному

  • OneToMany - один ко многим

  • ManyToOne - многие к одному

  • ManyToMany - многие ко многим

Для каждого из отношений есть своя аннотация и, казалось бы, на этом можно закончить разговор, но все не так просто. Да и вообще, может ли быть что-то просто в Hibernate ;) Каждое из выше перечисленных отношений может быть односторонним (unidirectional) или двусторонним (bidirectional), и если не принимать это во внимание, то можно столкнуться с массой проблем и странностей.

Для примера возьмем две простейшие сущности: пользователь и контакт. Очевидно, что каждый контакт связан с пользователем отношением многие к одному, а пользователь с контактами отношением один ко многим.

Односторонние отношения

Односторонним называется отношение, владельцем которого является только одна из двух сторон. Отсюда и название. Следует заметить, что при этом вторая сторона об этом отношении ничего не знает. HIbernate будет считать владельцем отношения ту сущность, в которой будет поставлена аннотация отношения.

Давайте попробуем сделать владельцем отношения сторону контакта. При этом сущности будут выглядеть следующим образом.

@Entity@Table(name = "contacts")public class Contact {    @Id    @GeneratedValue(strategy = GenerationType.IDENTITY)    private Long id;    @Column    private String type;    @Column    private String data;    @ManyToOne    private User user;        // Конструктор по умолчанию, геттеры, сеттеры и т.д.}@Entity@Table(name = "users")public class User {    @Id    @GeneratedValue(strategy = GenerationType.IDENTITY)    private Long id;    @Column    private String username;    // Конструктор по умолчанию, гетеры, сеттеры и т.д.}

Если запустить этот код, то Hibernate создаст следующую структуру таблиц, которая выглядит для нас вполне привычно. Отношение между таблицами создается при помощи ссылочного поля user_id в таблице contacts.

create table contacts (    id bigint not null auto_increment,    data varchar(255),    type varchar(255),    user_id bigint,    primary key (id)) engine=InnoDB;    create table users (    id bigint not null auto_increment,    email varchar(255),    password varchar(512) not null,    username varchar(128) not null,    primary key (id)) engine=InnoDB

Но выбор сущности Contact в качестве стороны владельца отношений в данном случае не очень удачен. Очевидно, что нам чаще нужна информация обо всех контактах пользователя чем о том, какому пользователю принадлежит контакт. Попробуем сделать владельцем контакта сущность пользователя. Для этого убираем поле user из класса Contact и добавляем поле со списком контактов в класс User. Получаем следующий код.

@Entity@Table(name = "contacts")public class Contact {    @Id    @GeneratedValue(strategy = GenerationType.IDENTITY)    private Long id;    @Column    private String type;    @Column    private String data;        // Конструктор по умолчанию, геттеры, сеттеры и т.д.}@Entity@Table(name = "users")public class User {    @Id    @GeneratedValue(strategy = GenerationType.IDENTITY)    private Long id;    @Column    private String username;    @OneToMany    private List<Contact> contacts;    // Конструктор по умолчанию, гетеры, сеттеры и т.д.}

Теперь владельцем отношения является сущность пользователя, что более логично, но если запустить данный код и посмотреть на созданную Hibernate структуру таблиц, то мы столкнёмся с одной хорошо известной почти каждому кто использовал эту библиотеку проблемой.

create table contacts (    id bigint not null auto_increment,    data varchar(255),    type varchar(255),    primary key (id)) engine=InnoDB;create table users (    id bigint not null auto_increment,    email varchar(255),    password varchar(512) not null,    username varchar(128) not null,    primary key (id)) engine=InnoDB;create table users_contacts (    User_id bigint not null,    contacts_id bigint not null) engine=InnoDB;

Чтобы связать сущности Hibernate создал дополнительную таблицу связи (join table) с именем users_contacts, хотя сущности вполне можно было бы связать через ссылочное поле в таблице contacts, как в предыдущем случае. Честно говоря, я не совсем понимаю, почему Hibernate поступает именно так. Буду рад, если кто-то поможет с этим разобраться в комментариях к статье.

Проблему можно легко решить добавив аннотацию JoinColumn к полю contacts.

    @OneToMany    @JoinColumn(name = "user_id")    private List<Contact> contacts;

При таких настройках связь будет проводиться при помощи колонки user_id в таблице contacts, а таблица связи создаваться не будет.

Двусторонние отношения

У двусторонних отношений помимо стороны - владельца (owning side) имеется ещё и противоположная сторона (inverse side). Т.е. обе стороны отношения обладают информацией о связи. Логично предположить, что из одностороннего отношения можно сделать двустороннее просто добавив поле и аннотацию в класс сущности противоположной стороны, но не все так просто. В чем именно тут проблема очень хорошо видно на примере отношения многие ко многим. Давайте создадим пример такого отношения между сущностями пользователя и роли этого пользователя.

@Entity@Table(name = "users")public class User {    @Id    @GeneratedValue(strategy = GenerationType.IDENTITY)    private Long id;    @Column    private String username;    @ManyToMany    private List<Role> roles;    // Конструктор по умолчанию, гетеры, сеттеры и т.д.}@Entity@Table(name = "roles")public class Role {    @Id    @GeneratedValue(strategy = GenerationType.IDENTITY)    private Long id;    @Column    private String name;    @ManyToMany    private List<User> users;    // Конструктор по умолчанию, гетеры, сеттеры и т.д.}

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

create table roles_users (    Role_id bigint not null,    users_id bigint not null) engine=InnoDB;create table users_roles (    User_id bigint not null,    roles_id bigint not null) engine=InnoDB;

Дело в том, что вместо одного одностороннего отношения мы с вами сейчас создали два односторонних. Тоже самое произойдет и для отношения один ко многим. Чтобы Hibernate понял, что мы хотим создать именно одностороннее отношение нам нужно указать, какая из двух сторон является владельцем отношений, а какая сторона является обратной. Это делается при помощи атрибута mappedBy. Важно отметить, что указывается этот параметр в аннотации, которая находится на противоположной стороне отношения.

Для отношения многие ко многим любая из сторон может быть владельцем. В случае с ролями и пользователями выберем сущность пользователя в качестве владельца. Для этого изменим описание поля users в классе Role следующим образом.

    // значение атрибута mappedBy - имя поля связи в классе сущности-владельца отношений    @ManyToMany(mappedBy = "roles")    private List<User> users;

Теперь Hibernate создаст только одну таблицу связи users_roles.

И напоследок давайте сделаем двусторонним отношение между пользователями и контактами. Следует отметить, что в отношении один ко многим стороной-владельцем может быть только сторона многих (many), поэтому атрибут mappedBy есть только в аннотации @OneToMany . В нашем случае владельцем отношения будет сторона контакта (класс Contact).

@Entity@Table(name = "contacts")public class Contact {    @Id    @GeneratedValue(strategy = GenerationType.IDENTITY)    private Long id;    @Column    private String type;    @Column    private String data;    @ManyToOne    private User user;        // Конструктор по умолчанию, геттеры, сеттеры и т.д.}@Entity@Table(name = "users")public class User {    @Id    @GeneratedValue(strategy = GenerationType.IDENTITY)    private Long id;    @Column    private String username;    @OneToMany(mappedBy = "user")    private List<Contact> contacts;    // Конструктор по умолчанию, гетеры, сеттеры и т.д.}

Для такого кода Hibernate создаст привычную нам структуру из двух таблиц со ссылкой на пользователя в таблице контактов.

На этом все на этот раз! Благодарю, что дочитали до конца и надеюсь, что статья была полезной! Разумеется, очень жду от вас обратную связь в виде голосов и комментариев!

Возможно, будет продолжение ;

Подробнее..

Java Core для самых маленьких. Часть 2. Типы данных

15.02.2021 14:04:42 | Автор: admin

Вступление

В этой статье мы не будем использовать ранее установленную IDE и JDK. Однако не беспокойтесь, ваш труд не был напрасным. Уже в следующей статье мы будет изучать переменные в Java и активно кодить в IDEA. Эта же статья является обязательным этапом. И в начале вашего обучения вы, возможно, будете не раз к ней возвращаться.

1998 - пин-код от моей кредитки является ничем иным как числом. По-крайней мере для нас - для людей. 36,5 - температура, которую показывают все термометры в разных ТРЦ. Для нас это дробное число или число с плавающей запятой. "Java Core для самых маленьких" - а это название данной серии статей, и мы воспринимает это как текст. Так к чему же я веду. А к тому, что Джаве (так правильно произносить, на тот случай если кто-то произносит "ява"), как и человеку, нужно понимать с чем она имеет дело. С каким типом данных предстоит работать.

Фанаты матрицы и, надеюсь, остальные читатели знают, что на низком уровне, вся информация в ЭВМ представлена в виде набора нулей и единиц. А вот у человеков, на более высоком уровне, есть высокоуровневые языки программирования. Они не требуют работы с нулями и единицами, предоставляя возможность писать код понятный для людей. Одним из таких языков программирование и является Java. Мало того, Java - это строго-типизированный язык программирования. А еще бывают языки с динамической типизацией данных (например Java Script). Но мы здесь учим нормальный язык программирования, поэтому не будем отвлекаться.

Что для нас означает строгая типизация? Это значит, что все данные и каждое выражение имеет конкретный тип, который строго определен. А также то, что все операции по передаче данных будут проверяться на соответствие типов. Поэтому давайте поскорее узнаем какие типы данных представлены в Java!

Примитивы

В языке Java существует 8, оскорбленных сообществом, примитивных типов данных. Их также называют простыми. И вот какие они бывают:

  • Целые числа со знаком: byte, short, int, long;

  • Числа с плавающей точкой: float, double;

  • Символы: char;

  • Логические значения: boolean.

В дальнейшем комбинируя эти самые примитивы мы сможем получать более сложные структуры. Но об этом нам еще рано беспокоиться. Сейчас же рассмотрим каждый из примитивов подробнее.

Тип byte

Является наименьшим из целочисленных. 8-разрядный тип данных c диапазоном значений от -2^7 до 2^7-1. Или простыми словами может хранить значения от -128 до 128. Используется для работы с потоками ввода-вывода данных, эта тема будет рассмотрена позже.

Тип short

16-разрядный тип данных в диапазоне от -2^15 до 2^15-1. Может хранить значения от -32768 до 32767. Самый редко применяемый тип данных.

Тип int

Наиболее часто употребляемый тип данных. Содержит 32 разряда и помещает числа в диапазоне от -2^31 до 2^31-1. Другими словами может хранить значения от -2147483648 до 2147483647.

Тип long

64-разрядный целочисленный тип данных с диапазоном от -2^63 до 2^63-1. Может хранить значения от -9223372036854775808 до 9223372036854775807. Удобен при работе с большими целыми числами.

Используются при точных вычислениях, которые требуют результата с точностью до определенного знака после десятичной точки (вычисление квадратного корня, функции синуса или косинуса и прочего).

Тип float

32-разрядный тип данных с плавающей точкой. Требует в два раза меньше памяти и в некоторых процессорах выполняется быстрее по сравнению с double. Но если значения слишком велики или слишком малы, то не обеспечивает требуемую точность вычислений. Используется когда нужно число с дробной частью, но без особой точности.

Тип double

На хранение требуется 64 бита. Рационально пользоваться double когда нужно сохранить точность многократно повторяющихся вычислений или манипулировать большими числами.

Тип char

16-разрядный тип данных в диапазоне от 0 до 2^16. Хранит значения от 0 до 65536. Этот тип может хранить в себе полный набор международных символов на всех известных языках мира (кодировка Unicode). То есть по сути каждый символ представляет из себя какое-то число. А тип данных char позволяет понять, что это число является символом.

Тип boolean

Может принимать только 2 значения true или false. Употребляется в условных выражениях, к примеру 1 > 10 вернет false, а 1 < 10 - true.

На этом примитивные типы данных в Java закончились. В следующей статье мы будем объявлять переменные конкретного типа данных. Поговорим о том, что такое литералы. А еще узнаем, что такое приведение типов данных. Вообщем следующая статья будет очень насыщенной и познавательной!

Подробнее..

Code evaluation как средство отладки

15.02.2021 14:04:42 | Автор: admin

Господа разработчики java приложений. Сегодня вашему вниманию представляется простой способ использования code evaluation, реализация которого позволит исполнять произвольный код в работающем приложении, что в свою очередь позволит сэкономить массу времени на CI/CD.

Зачем мне это нужно?

Если вам приходится разрабатывать в условиях микросервисной архитектуры, особенно в большой компании, то скорее всего вам знакома ситуация, когда посмотреть как "по-боевому" работает приложение можно только на стендах на которых есть интеграции с другими микросервисами. И поскольку далеко не все вещи можно проверить локально на заглушках, для того чтобы проверить ту или иную гипотезу, приходится пушить новый код (не факт что работающий корректно) в репозиторий... прогонять его через CI/CD... и только потом по логам понять что где-то что-то пошло не так. И хорошо если логи сразу покажут в чём вы ошиблись, потому как иначе этот процесс пуша и прогона по пайплайнам может стать вашим круговоротом сансары.

Исполнение динамически введённого кода поможет решить эту проблему.

Как это работает?

Как мы с вами знаем, groovy это полностью совместимый с Java язык программирования с динамической компиляцией. Эти две особенности groovy и помогут нам в том, что бы реализовать code evaluation для java приложений. О том как добавить поддержку groovy в java проект вы сможете легко найти сами. А я приведу пример, как реализовать code evaluation (в некотором смысле аналогичный тому, который вы можете видеть во время дебага в вашей IDE).

1) Создадим groovy класс, а в нём шаблонную строку в которую поместим класс и плейсхолдер для динамически введённого кода. Пример такой строки:

def EXPRESSION_CLASS_TEMPLATE = """package dev.toliyansky.eval.serviceclass ExpressionClass implements java.util.function.Supplier<Object> {def get() {%s}}"""

Примечание: package должен быть такой же как и у класса в котором вы этот код будете писать.

Почему мы имплементируем Supplier будет описано ниже.

2) Динамически скомпилируем и загрузим этот класс.

Кусок кода ниже может быть размещён например в REST контроллере, который получает code как тело запроса.

def finalClassCode = String.format(EXPRESSION_CLASS_TEMPLATE, code)def supplier = groovyClassLoader.parseClass(finalClassCode)                                .getDeclaredConstructor()                                .newInstance() as Supplier<Object>def result = supplier.get()

В первой строчке заменяем %s на код который хотим динамически ввести и исполнить в рантайме.

Во второй строке компилируем и загружаем класс из строки, которую получили на предыдущем шаге. Тут важно заметить что созданный инстанс класса приводим к Supplier для того, чтобы далее в третьей строчке можно было сделать вызов метода в котором должен исполниться динамически введённый код. Supplier<Object> в данном случае идеально нам подходит.

Вот собственно и всё.

Пример использования code evaluation

Допустим у вас web приложение в kubernetes. Вы написали какую-то новую фичу, закоммитились, прошли код ревью, прогнали код через CI/CD и вот POD с вашим приложением наконец поднимается, вы заходите в логи и видите что фича работает не так как ожидалось. Допустим, для примера, что вы забыли в конструкторе что-то проинициализировать и поэтому остальная бизнес логика не отрабатывает с банальным NullPointerException.

Имея в своём арсенале HTTP роут с исполнением динамического кода, можно спокойно обратиться к applicationContext, вытащить нужный бин и ручками проинициализировать забытую переменную. После чего потыкать в инициирование отработки бизнес кода и проверить результат, минуя весь CI/CD. Таким банальным примером всё не ограничивается. При желании можно даже в райнтайме переопределить метод класса с бизнес логикой и играться до тех пор пока не отладите код и потом уже зная как оно себя ведёт коммититься и прогонять пайплайны.

Готовое решение для web приложений на spring boot

Если вы не хотите возиться с добавлением groovy в ваш java проект и писать все эти контроллеры, обёртки, разбираться с динамикой, а просто хотите добавить в одну строчку зависимость в ваш проект и чтобы работало из коробки, то тогда специально для вас презентую маленький проект который всё это умеет - evaluator-spring-boot-starter

Это, как можно догадаться из названия, spring boot starter. Подключение данного стартера добавляет в ваше web приложение роут http://host:port/eval отдающий WEB-UI, в котором можно ввести код который хотите динамически исполнить, а результат выведется в окне рядом. Всё это приправлено подсветкой синтаксиса, и прочими удобствами. Если же, например, ваше приложение не имеет выходного роута из кластера и вы можете только лишь использовать curl или wget из терминала POD, то тогда можно использовать роут http://host:port/eval/groovy и отправлять код как параметр GET запроса или как тело POST запроса.

Впрочем, всё это более-менее подробно описано в readme проекта.

Скриншот WEB-UI evaluator-spring-boot-starterСкриншот WEB-UI evaluator-spring-boot-starter

В итоге

  • Продемонстрировано как code evaluation может сэкономить время на отладке приложения

  • Продемонстрировано как реализовать code evaluation в java проекте

  • Продемонстрировано готовое решение в виде spring boot starter.

Подробнее..

Project Loom Современная маcштабируемая многопоточность для платформы Java

19.02.2021 18:05:42 | Автор: admin


Эффективное использование многочисленных ядер современных процессоров сложная, но всё более важная задача. Java была одним из первых языков программирования со встроенной поддержкой concurrency. Ее concurrency-модель, основанная на нативных тредах, хорошо масштабируется для тысяч параллельно выполняющихся стримов, но оказывается слишком тяжеловесной для современного реактивного программирования с сотнями тысяч параллельных потоков.


Ответ на эту проблему Project Loom. Он определяет и реализует в Java новые легковесные параллельные примитивы.


Алан Бейтман, руководитель проекта OpenJDK Core Libraries Project, потратил большую часть последних лет на проектирование Loom таким образом, чтобы он естественно и органично вписывался в богатый набор существующих библиотек Java и парадигм программирования. Об этом он и рассказал на Joker 2020. Под катом запись с английскими и русскими субтитрами и перевод его доклада.



Меня зовут Алан Бейтман, я работаю в группе Java Platform в Oracle, преимущественно над OpenJDK. Сегодня я буду говорить о Project Loom.


Мы занялись этим проектом в конце 2017 года (точнее, технически в начале 2018-го). Он появился как проект в OpenJDK для того, чтобы упростить написание масштабируемых многопоточных приложений. Цель в том, чтобы позволить разработчикам писать масштабируемые многопоточные приложения в так называемом синхронном стиле. Это достигается путем доведения базовой единицы многопоточности потока до такой легковесности, чтобы им можно было представлять любую параллельную задачу. Даже задачи, которые блокируются или выполняются в течение длительного времени.


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


План выступления такой:


  1. Начну с пары слов о мотивации этого проекта.
  2. Поговорю о том, как мы имплементировали эти так называемые легкие потоки.
  3. Переключусь на IDE и покажу несколько демо, напишу немного кода.
  4. Наконец, рассмотрю другие аспекты проекта.

Потоки


Платформа Java (и язык, и JVM) во многом построена на концепции потоков:


  • Если вы сталкиваетесь с исключением, то получаете трассировку стека определенного потока.
  • Вы можете связать некоторые данные с потоками, используя ThreadLocal.
  • Если вы находитесь в отладчике и выполняете пошаговое выполнение кода, вы шагаете по выполнению потока. Когда вы нажимаете step over, это означает переход к следующей инструкции в потоке, с которым вы работаете.
  • А когда вы находитесь в профайлере, профайлеры обычно группируют данные по потокам, сообщают вам, какие потоки выполняются и что они делают.

В общем, всё, что касается платформы и инструментов, связано с потоками.


В Java API поток означает java.lang.Thread. В реализации JDK есть только одна реализация потока, которая фактически основана на потоке операционной системы. Между java.lang.Thread и потоком ОС существует связь один-к-одному. Те из вас, кто уже давно работает с платформой Java, могут вспомнить зелёные потоки в ранних выпусках JDK. Я немного расскажу об этом позже. Но по меньшей мере последние 20 лет, когда мы говорим о java.lang.Thread, мы говорим о тонкой оболочке вокруг потока ОС.


Cами потоки ОС ничего не знают о Java. Они очень общие. Обычно они должны поддерживать множество разных языков и сред выполнения. Они ничего не знают о том, как эти языки и программы используют стек, и им обычно приходится выделять очень большой фиксированный стек, чтобы поддерживать универсальность
программ, которые должны выполняться.


Другой аспект потоков операционной системы заключается в том, что они проходят через ядро ОС для переключения контекста, что обычно требует
значительное количество времени. В течение многих лет это было около микросекунды или больше.


Еще одна особенность потоков операционной системы заключается в том, что ядро ОС должно иметь некоторую форму планирования. Ему нужно выбрать, какой поток
запускать на каждом ядре процессора. Веб-серверы ведут себя совсем иначе, чем, например, поток с вычислениями для воспроизводения видео. Планировщик ОС должен быть очень общим и в некотором роде компромиссным, чтобы поддерживать все различные варианты использования.


Давайте немного поговорим об использовании потоков. Можно писать многопоточные приложения в стиле, который мы называем синхронным. Простой, императивный блокирующий синхронный код. Задачи выполняются в одном потоке от начала до конца. Код обычно очень легко читать и писать. Именно так большинство из нас, я думаю, учились его писать. Мы научились работать так с одним потоком до того, как узнали, что такое поток.


Этот синхронный стиль очень хорошо сочетается с дизайном языка Java. Он очень хорошо сочетается с инструментами. И в целом, как любит говорить мой коллега Рон Пресслер, гармонично сочетается с платформой. Но поскольку поток по сути представляет собой тонкую оболочку вокруг потока ОС, это ограниченный ресурс.


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


А с современным сервером теоретически вы можете иметь миллионы сетевых подключений. Я видел, как Хайнц Кабуц делает демо с Project Loom, где он фактически использовал два миллиона соединений. И серверы могут поддерживать подобное, если у них достаточно памяти.


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


Ладно, что нам с этим делать?


Если потоки дорогой ресурс, почему бы нам ими не делиться? Это означает пулы потоков. Вместо создания потока для каждого запроса или транзакции мы заимствуем поток из пула, выполняем транзакцию, а затем возвращаем его в пул.


Но у пулов много проблем. Думаю, большинство тех, кто их использовал, знает о проблеме того, как они засоряют ThreadLocals. Эта так называемая утечка памяти с пулами потоков существует долгое время. Также проблематична отмена: если я хочу отменить транзакцию, но она почти завершена, я, возможно, прерываю поток после того, как он был взят для другой транзакции.


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


Мы можем заметить, что для большого количества запросов и транзакций,
которые не упираются в CPU, поток проводит большую часть своего времени в ожидании, в блокировке, ожидая базу данных, IO, что-то еще. А нам, на самом деле, не нужен поток, когда он ожидает.


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


Это приводит нас к созданию новых API, по существу, несовместимых со старыми. Или в итоге у нас есть синхронные и асинхронные версии API.


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


Когда мы отлаживаем, это будет отладка лишь этапа транзакции. Если мы профилируем, то не увидим многого о том, что на самом деле происходит. Потому что многие транзакции выглядят ничего не делающими, они просто ждут IO. Профайлер, который смотрит на незанятый пул потоков, не особо много видит.


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


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


Что приводит нас к дилемме.



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


Итак, как нам решить эту дилемму? Что, если бы мы могли снизить стоимость потоков и иметь их неограниченное количество? Тогда мы могли бы написать простой синхронный код, который гармонирует с платформой, полностью использует оборудование и масштабируется как асинхронный код. Project Loom именно об этом.


API


Давайте пойдем дальше и поговорим немного об API.


Если Project Loom снижает стоимость потоков, то как это будет отражаться на разработчиках и на API? Эта проблема сложнее, чем кажется на первый взгляд, и мы потратили более двух лет на борьбу с ней.


Один из вариантов, с которого мы начали и к которому в итоге вернулись, это
использование для легких форм потоков java.lang.Thread. Это старый API, который существует с JDK 1.0. Проблема в том, что у него много багажа. Там есть такие вещи, как группы потоков, загрузчик классов контекстов потоков. Есть множество полей и других API, которые связаны с потоками, которые просто не интересны.


Другой вариант начать все сначала и ввести совершенно новую
конструкцию или новый API. Если вы с самого начала интересовались Project Loom, возможно, вы видели некоторые из ранних прототипов, где мы представили для дешевых легких потоков совершенно новый API под названием fiber.


Помимо изучения API, мы также много изучали, как люди используют потоки. Оказалось, что одни их части используются очень широко, другие в меньшей степени. Thread.currentThread() используется и прямо и косвенно везде, например, для блокировки.


Вопрос, который часто возникает в викторинах: Сколько раз Thread.currentThread() используется при первом использовании популярной библиотеки логирования? Люди, не знающие ответа на этот вопрос, могут ответить 2 или 5. Правильный ответ 113.


Другой широко используемый аспект потока это ThreadLocals. Они используются везде, что иногда не радует. Если сломать Thread.currentThread() или ThreadLocals, то в контексте этих новых более дешевых потоков будет не запустить много уже существующего кода. Поэтому вначале, когда у нас был fiber API, нам пришлось эмулировать Thread API, чтобы существующий код запускался в контексте того, что называлось в то время fiber. Таким образом, мы могли уйти от кода, использующего Thread, не повредив нарыв.


Итак, .currentThread() и Threadlocals очень широко используются. Но в потоках есть и редко используемый багаж. И здесь нам немного помогает расширенная политика депрекации. Если некоторые из этих старых областей со временем могли бы исчезнуть, подвергувшись депрекации, окончательной депрекации и, в конечном итоге, удалению тогда, может быть, удастся жить с java.lang.Thread.


Два года исследований, около пяти прототипов и мы пришли к выводу, что избежать
гравитационного притяжения 25 лет существующего кода невозможно. Эти новые дешевые потоки будут представлены с существующим API java.lang.Thread. То есть java.lang.Thread будет представлять и потоки ОС, и новые дешевые потоки.


Мы также решили дать этим новым потокам имя. Оно появилось благодаря Брайану Гетцу, он придумал название виртуальный поток (virtual thread).


Использование привычного Thread хорошая новость для разработчиков. Нет новой модели программирования, нет новых концепций для изучения, вместо этого вам фактически придется отучиться от некоторых старых привычек. Когда я говорю отучиться, я имею в виду такие вещи, как пулы потоков, ThreadLocals и так далее.


Как реализованы эти виртуальные потоки?



Они мультиплексируются поверх небольшого пула потоков операционной системы. Я сказал потоки во множественном числе, и вот тут уместно вспомнить уже упомянутые green threads. Ранние выпуски JDK, особенно 1.0.1.1 с классической виртуальной машиной, поддерживали модель, где потоки мультиплексировались в один-единственный поток ОС. То, что мы делаем теперь, перекликается с этим, но сейчас речь о более чем одном потоке ОС.


Итак, у нас есть набор потоков, на которые эти виртуальные потоки мультиплексируются. Под капотом виртуальная машина HotSpot была обновлена для поддержки новой конструкции: scoped stackful one-shot delimited continuations. Виртуальные потоки объединяют континуации в HotSpot с планировщиками в библиотеке Java. Когда код, выполняющийся в виртуальном потоке, блокируется, скажем, в операции блокировки или в блокирующей IO-операции, соответствующая континуация приостанавливается, стек потока, на концептуальном уровне, вымещается в кучу Java, а планировщик выберет и возобновит другой виртуальный поток в этом же потоке ОС. Исходный виртуальный поток может быть возобновлен в том же потоке ОС или в другом.


Таким образом, код, в котором есть остановка и возобновление, может делать это в разных потоках ОС с течением времени. Есть небольшой набор потоков операционной системы, который обычно как минимум соответствует количеству ядер в системе. Они поддерживают выполнение многих виртуальных потоков, осуществляя прогресс кусочек за кусочком.


Пользовательский код, использующий API Java, не знает о распределении, которое
происходит под капотом, а yield и resume происходит глубоко в библиотеках JDK, поэтому мы говорим, что планирование является вытесняющим и не требует сотрудничества со стороны кода пользователя.


С точки зрения стоимости, поток ОС слева, виртуальный поток справа.



Обычно операционная система резервирует около мегабайта стека для потока операционной системы. Некоторые ядра выделяют дополнительные данные ядра, и 16КБ не редкость. Это то, что операционная система имеет на поток ОС. Кроме того, виртуальная машина HotSpot добавляет к этому пару КБ метаданных.


Виртуальные потоки намного дешевле, текущий прототип составляет около 256 байт на виртуальный поток. Еще есть стек, он уменьшается и увеличивается по мере необходимости и обычно составляет пару КБ в этом главное преимущество
виртуальных потоков перед потоками ОС.


Переключение задач также немного лучше, в типичных ОС оно составляет около микросекунды, в некоторых случаях может быть хуже. Лучший вариант с виртуальными потоками на данный момент работает лучше, около пары сотен наносекунд. Меньший размер и лучшее время переключения контекста означают, что мы можем иметь столько потоков, сколько захотим, и уровень многопоточности может
расти без ограничений.


Самое время перейти от слайдов к IDE и показать вам несколько примеров в коде.


Демо


У меня открыта IDE с пустым методом, и мы начнем с самого начала.


import ...public class Demo {    public static void main(String[] args) throws Exception {...}    void run() throws Exception {    }}

Я упомянул, что мы ввели новый фабричный метод, и начну с использования фабричного метода Thread.startVirtualThread().


import ...public class Demo {    public static void main(String[] args) throws Exception {...}    void run() throws Exception {        Thread thread = Thread.startVirtualThread(() -> System.out.println("hello"));        thread.join();    }}

Вывел сообщение hello, ничего особенного. Это немного отличается от использования конструкторов и метода start(), здесь всего лишь один фабричный метод.


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


void run() throws Exception {    Thread thread = Thread.startVirtualThread(Thread::dumpStack);    thread.join();}

Этот референс-метод просто вызывает дамп стека в контексте виртуального потока.



Возможно, это выглядит немного иначе, чем то, что вы видели бы с обычным java.lang.Thread, потому что фреймы, которые вы видите здесь, не те, что вы видите в обычном JDK. Это своего рода эквивалент запуска потока, потому что виртуальный поток запускает континуацию. Это дает представление о том, в чем вы можете увидеть разницу.


Давайте рассмотрим еще один из аспектов API. Что делает этот startVirtualThread()?


В дополнение к введению фабричных методов для создания виртуальных потоков, текущий прототип имеет новый билдер для создания потоков. Создадим билдер с помощью метода Thread.builder(). Мы можем при этом вызвать несколько методов, позволяющих настроить поток: является ли он потоком-демоном, какое у него имя и некоторые другие аспекты.



В числе этих методов есть virtual(). Создание виртуального потока cо startVirtualThread(), было, по сути, тем же самым. Вот длинная форма того, что я сделал минуту назад:


void run() throws Exception {    Thread thread = Thread.builder().virtual().task(() -> {        System.out.println("hello");    }).start();    thread.join();    }}

Мы снова сделали то же самое многословнее, но теперь использовали билдер потоков. А он избавляет нас от того, чтобы сначала использовать конструктор для создания потоков, а затем вызывать setDaemon() или setName(). Это очень полезно.


Это хорошее улучшение API для тех, кто в конечном итоге использует Thread API напрямую. Запускаем и получаем то же, что и в случае с startVirtualThread().


Еще мы можем создать ThreadFactory.


void run() throws Exception {    ThreadFactory factory = Thread.builder().name(prefix:"worker-", start:0).factory();}

Это создает фабрику потоков она создает потоки, которые называют себя worker-0, worker-1, worker-2 и так далее. На самом деле worker это только начальный аффикс, который добавляется к префиксу. Это еще один полезный способ создания фабрик потоков.


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


Большинство людей фактически не используют Thread API напрямую. Начиная с JDK 5, они перешли на использование ThreadExecutor и других API из java.util.concurrent.


Я хочу показать вам использование одного из этих ThreadExecutor. Мы создадим множество потоков и покажем вам, что на самом деле происходит.


Я собираюсь создать ExecutorService executor:


try (ExecutorService executor = Executors.newVirtualThreadExecutor()) {}

Этот фабричный метод для Executors создает виртуальные потоки. Обратите внимание, что здесь я использую try-with-resources. Одна из вещей, которые мы сделали в Loom, мы модернизировали ExecutorService для расширения AutoCloseable, чтобы вы могли использовать их с конструкцией try-with-resources.


Приятная вещь в том, что когда он закрыт, как на примере сверху, он гарантирует, что все задачи, которые являются потоками в этом случае, будет завершены до того, как завершится закрытие. На самом деле закрытие будет ждать, пока все задачи или потоки не будут завершены, что очень полезно. Этот тип Executor'а создает поток для каждой задачи, поэтому он сильно отличается от пулов потоков, которые вы обычно создаете с помощью фабричного класса Executors.


Давайте создадим здесь миллион потоков.


import ...  public class Demo {      public static void main(String[] args) throws Exception {...}      void run() throws Exception {          try (ExecutorService executor = Executors.newVirtualThreadExecutor()) {              IntStream.range(0, 1_000_000).forEach(i -> {                  executor.submit(() -> { });              });          }      }      String fetch(String url) throws IOException {...}      void sleep(Duration duration) {...}  }

Я использую IntStream.range(), вместо цикла for. Это вызовет метод executor.submit() один миллион раз, он создаст миллион потоков, которые ничего не делают. Если это запустить, ничего интересного не произойдет Process finished with exit code 0.


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


import ...public class Demo {    public static void main(String[] args) throws Exception {...}    void run() throws Exception {        AtomicInteger counter = new AtomicInteger();        try (ExecutorService executor = Executors.newVirtualThreadExecutor()) {            IntStream.range(0, 1_000_000).forEach(i -> {                executor.submit(counter::incrementAndGet);            });        }        System.out.println(counter.get());    }    String fetch(String url) throws IOException {...}    void sleep(Duration duration) {...}  }

Мы создаем Executor, отправляем миллион задач, каждая из этих задач будет увеличивать счетчик, и когда все закончится, выводится значение счетчика. Если все работает правильно, как у нас, должен быть выведен миллион.


Отрабатывает быстро как видите, эти потоки очень дешевы в создании.


Давайте покажу вам, что еще мы можем делать с Executor'ами. У меня есть метод, который просто принимает байты из определенного URL-адреса, создает из него строку. Это не очень интересно разве что то, что это блокирующая операция.


String fetch(String url) throws IOExpection {    try (InputStream in = URI.create(url).toURL().openStream()) {        byte[] bytes = in.readAllBytes();        return new String(bytes, charsetName:"ISO-8859-1");    }}

Он создает сетевые подключения, HTTP-соединение будет ожидать результатов от сервера, мы просто воспользуемся этим как частью примера.


Давайте посмотрим вот на что:


void run() throws Exception {       try (ExecutorService executor = Executors.newVirtualThreadExecutor()) {           Callable<String> task1 = () -> fetch(url:"https://jokerconf.com/");           Callable<String> task1 = () -> fetch(url:"https://jokerconf.com/en");           String first = executor.invokeAny(List.of(task1, task2));           System.out.println(first.length());       }     }

Вот одна задача, которая получает HTML-страницу с jokerconf.com. Я собираюсь создать вторую задачу, которая будет делать то же самое, но будет получать английскую версию страницы. Если кто-то говорит на двух языках, то он сможет читать и русскую и английскую страницу, это не имеет значения.


Мы используем executor.invokeAny() и даем ему две задачи.
ExecutorService имеет несколько комбинаторов, invokeAny(), invokeAll(), они существуют уже давно. Мы можем использовать их с виртуальными потоками.


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


Я запущу два виртуальных потока. Один из них получит первую страницу, другой вторую, в зависимости от того, что вернется первым, я получу результат в String first. Другой будет отменен (прерван). Запускаем и получаем результат: 200160, то есть одна из страниц размером 200 КБ.


Итак, что произошло: были созданы два потока, один выполнял блокирующую операцию получения данных с первого URL-адреса, другой со второго URL-адреса, и я получил то, что пришло первое. Если запущу еще пару раз, буду получать разные значения: одна из страниц всего 178 КБ, другая 200 КБ.


Это один из комбинаторов. На самом деле, я бы мог хотеть обе страницы и что-то с ними сделать, в этом случае я мог бы использовать invokeAll().


void run() throws Exception {       try (ExecutorService executor = Executors.newVirtualThreadExecutor()) {           Callable<String> task1 = () -> fetch(url:"https://jokerconf.com/");           Callable<String> task1 = () -> fetch(url:"https://jokerconf.com/en");           executor.invokeAll(List.of(task1, task2)); List>Future>String>>                   .stream() Stream<Future<String>>                   .map(Future::join) Stream<String>                   .map(String::length) Stream<integer>                   .forEach(System.out.println);       }     }

Как видите, это не слишком интересно всё, что мы здесь делаем, это invokeAll(). Мы выполним обе задачи, они выполняются в разных потоках. InvokeAll() блокируется до тех пор, пока не будет доступен результат всех задач, потому что вы получаете здесь Future, которые гарантированно будут выполнены. Создаем поток, получаем результат, получаем длины, а затем просто выводим их. Получаем 200 КБ и 178 КБ. Вот что вы можете делать с ExecutorService.


Покажу вам еще кое-что. В рамках Loom мы немного поработали над CompletableFuture, чтобы вы могли делать подобное. Добавить задачу и получить CompletableFuture, а не Future, и тогда я смогу написать такой код:


void run() throws Exception {       try (ExecutorService executor = Executors.newVirtualThreadExecutor()) {           Callable<String> task1 = () -> fetch(url:"https://jokerconf.com/");           Callable<String> task1 = () -> fetch(url:"https://jokerconf.com/en");           CompletableFuture<String> future1 = executor.submitTask(task1);           CompletableFuture<String> future2 = executor.submitTask(task2);           CompletableFuture.completed(future1, future2) Stream<CompletableFuture<String>>                   .map(Future::join) Stream<String>                   .map(String::length) Stream<integer>                   .forEach(System.out.println);       }     }

Я вызываю в CompletableFuture-метод под названием completed(). Это возвращает мне стрим, который заполняется Future в ленивом режиме по мере их завершения. Это намного интереснее, чем invokeAll(), который я показал ранее, поскольку метод не блокируется, пока не будут выполнены все задачи. Вместо этого поток заполняется результатом в ленивом режиме. Это похоже на стримо-подобную форму CompletionService, если вы когда-нибудь такое видели.


Я запущу несколько раз, порядок, вероятно, будет случайным. В любом случае, это дает вам представление о других вещах, которые вы можете делать с CompletableFuture, стримами и виртуальными потоками.


Еще одна вещь, которую я хочу сделать, забегая вперед. Мы еще поговорим об этом подробнее после демо. В прототипе есть ограничение. Виртуальные потоки делают то, что мы называем закреплением потока ОС, когда мы пытаемся выполнить IO-операции, удерживая монитор. Я объясню это лучше после демо, но пока у меня открыта IDE, покажу вам это на практике и объясню, на что это влияет.


import ...public class Demo {    public static void main(String[] args) throws Exception {...}    void run() throws Exception {        Thread.startVirtualThread(() ->            sleep(Duration.ofSeconds(2));        }).join();    }    String fetch(String url) throws IOException {...}    void sleep(Duration duration) {...}  }

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


void run() throws Exception {        Thread.startVirtualThread(() -> {            Object lock = new Object();            synchronized (lock) {                sleep(Duration.ofSeconds(2));            }        }).join();}

Я запускаю это с диагностическим свойством, которое даст мне трассировку стека, когда поток закреплен.



Мы видим трассировку стека, которая говорит мне, что поток был закреплен. Она снабжена примечаниями, которые говорят мне, где удерживается монитор. Это ограничение в нашем текущем прототипе. По сути, потоки могут блокироваться, удерживая монитор. Поток закрепляет соответствующий поток ОС, эта скорее качество сервиса текущей реализации, чем ошибка. Я вернусь к тому, что мы делаем c этим, через несколько минут. Это своего рода базовое демо.


У меня есть более полная демонстрация, переключусь для этого на немного другой проект.


package demo;import ...@Path("/")public class SleepService {    @GET    @Path("sleep")    @Producers(MediaType.APPLICATION_JSON)    public String sleep(@QueryParam("millis") long millis) throws Exception {        Thread.sleep(millis);        return "{ \"millis\": \"" + millis + "\" };    }}

Уже существуют несколько серверов, которые работают с виртуальными потоками.
Есть сервер Helidon MP. Я думаю, MP означает MicroProfile. Helidon настроен, они недавно внесли некоторые изменения, теперь вы можете запустить его со свойством, при котором он будет запускать каждый запрос в отдельном виртуальном потоке. Мой код может выполнять операции блокировки, и они не будут закреплять базовый поток ОС. У меня может быть намного больше запросов, чем потоков, работающих одновременно и выполняющих блокирующие операции, это действительно очень полезно.


Первый сервис, который я вам покажу, что-то вроде эквивалента hello world при использовании подобных служб. Запускаем код из примера выше, переходим в окно терминала и вводим curl-команду.



Curl-команда кодирует параметр миллисекунд обратно в JSON, который возвращается.
Не слишком интересно, потому что все, что было сделано, это сон. Остановлю сервер и вставлю Thread.dumpStack():


public String sleep(@QueryParam("millis") long millis) throws Exception {    Thread.dumpStack();    Thread.sleep(millis);    return "{ \"millis\": \"" + millis + "\" };}

Снова запущу сервер. Я снова выполняю команду curl, которая устанавливает HTTP-соединение с сервером, она подключается к эндпоинту сна, параметр millis=100.


curl http://localhost:8081/sleep?millis=100


Посмотрим на вывод: печатается трассировка стека, созданная Thread.dumpStack() в сервисе.



Огромная трассировка стека, мы видим здесь кучу всего: код Helidon, код Weld, JAX-RS Довольно интересно просто увидеть это всё. Это сервер, который создает виртуальный поток для каждого запроса, что довольно интересно.


Теперь посмотрим на более сложный сервис. Я показал вам комбинаторы
invokeAny и involeAll в простом демо в самом начале, когда показывал новый ExecutorService.


import ...@Path("/")public class AggregatorServices {    @GET    @Path("anyOf")    @Produces(MediaType.APPLICATION_JSON)    public String anyOf(@QueryParam("left") String left,                        @QueryParam("right") String right) throws Exception {        if (left == null || right == null) {            throw new WebApplicationException(Response.Status.BAD_REQUEST);        }        try (var executor :ExecutorService = Executors.newVirtualThreadExecutor()) {            Callable<String> task1 = () -> query(left);            Callable<String> task2 = () -> query(right);            // return the first to succeed, cancel the other            return executor.invokeAny(List.of(task1, task2));        }    }    @GET    @Path("allOf")    @Produces(MediaType.APPLICATION_JSON)    public String allOf(@QueryParam("left") String left,                        @QueryParam("right") String right) throws Exception {        if (left == null || right == null) {            throw new WebApplicationException(Response.Status.BAD_REQUEST)        }        try (var executor :ExecutorService = Executors.newVirtualThreadExecutor()) {            Callable<String> task1 = () -> query(left);            Callable<String> task2 = () -> query(right);            // if one falls, the other is cancelled            return executor.invokeAll(List.of(task1, task2), cancelOnException: true) List<Future<String>>                    .stream() Stream<Future<String>>                    .map(Future::join) Stream<String>                    .collect(Collectors.joining(delimiter:", ", prefix:"{", suffix:" }"));        }    }    private String query(String endpoint) {...}}

Здесь у нас несколько сервисов, они находятся в этом исходном файле под названием AggregatorServices. Здесь есть две службы, два метода я бы сказал: anyOf и allOf. anyOf выполняет левый и правый запросы и выбирает тот, который возвращается первым, а другой отменяет.


Начнем с anyOf. Я вызвал curl-команду:


curl http://localhost:8081/anyOf?left=/greeting\&right=/sleep?millis=200

localhost:8081 это текущий порт, эндпоинт anyOf, и я дал ей два параметра left и right. Я выполняю это и получаю hello world:


{"message":"Hello World!"}$


Причина в том, что сервис приветствия просто выводит hello world, а сервис сна спит 200 мс. Я предполагаю, что большую часть времени hello world будет быстрее, чем 200 мс, и всегда будет возвращаться hello world.


Если я уменьшу сон до 1 мс, то, возможно, сервис сна завершится раньше, чем другой сервис.


Теперь давайте изменим запрос на allOf, который объединит два результата:


curl http://localhost:8081/allOf?left=/greeting\&right=/sleep?millis=1

Запускаю и получаю два результата.


{ {"message":"Hello World!"}, { "millis": "1" } }$


Что интересно в allOf, он делает два запроса параллельно.


private String query(String endpoint) {        URI uri = URI.create("http://localhost:8081").resolve(endpoint);        return ClientBuilder.newClient() Client                    .target(uri) WebTarget                    .request(MediaType.APPLICATION_JSON) Invocation.Builder                    .get(String.class);    }

Кстати, это блокирующий код. Он использует клиентский API JAX-RS для подключения к этому эндпойнту. Он использует вызов invokeAll(), а затем .stream (), .map для получения результата, а затем Collectors.joining(), для объединения в JSON.


Это простой пример разветвления. Интересно то, что тут invokeAll() это вариант, в котором есть параметр cancelOnException. Если вы хотите вызвать несколько задач одновременно, но если одна из них не работает, вы отменяете все остальные. Это важно сделать, чтобы не застрять в ожидании завершения всех остальных задач.


В этих примерах я использую сборку для раннего доступа Loom. Мы очень близки к первому рампдауну JDK 16, поэтому код, над которым я работаю это JDK 16, каков он сейчас, плюс вся реализация Loom.


Ограничения


Поговорим об ограничениях.


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


Первый сценарий возникает, когда вы используете нативные фреймы. Если у вас есть код JNI, вы вызываете код JNI, он обращается обратно в код Java, а затем этот код Java пытается заблокироваться или совершить IO-операцию. На континуации есть нативный фрейм, мы мало что можем сделать. Это потенциально постоянное ограничение, но подобное должно происходить очень и очень редко.


Второй случай более проблематичен, и это то, что я показал в демонстрации: попытка
парковки, удерживая монитор. Скорее всего, первая версия будет с этим ограничением, это особенность реализации, влияющая на качество сервиса. В настоящее время ведутся исследования по реимплементации мониторов, чтобы преодолеть это ограничение. Но это серьезный объем работы, на это потребуется время.


На самом деле это не очень критично. По той простой причине, что всё, что сегодня использует мониторы Java, можно механически преобразовать из использования synchronized и wait-notify в использование блокировок из java.util.concurrent. Так что существуют эквиваленты мониторов в блокировках java.util.concurrent и различные формы блокировок, самый простой из которых ReentrantLock, они очень хорошо работают с виртуальными потоками.


Что вы можете сделать при подготовке к Loom?


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


Предположим, у вас миллион потоков и код, который использует много ThreadLocals. Хотя виртуальные потоки поддерживают ThreadLocals, при их большом количестве требуется много памяти. Тут есть над чем подумать. Мы уже довольно давно работаем в JDK над устранением многих из ThreadLocals, которые использовались в различных местах.


Распространенным является кэширование объектов SimpleDateFormat.
SimpleDateFormat может быть дорогостоящим в создании, они не являются потокобезопасными, поэтому люди повсеместно кэшируют их в ThreadLocals.


В JDK мы заменили кэширование SimpleDateFormats на новый неизменяемый формат даты java.date dateformatter. Он неизменяем, вы можете сохранить его
в static final поле, это достаточно хорошо. Мы удалили ThreadLocals и из некоторых других мест.


Другая сложность сводится к масштабированию приложения и обработке десятков тысяч запросов. Если у вас много данных на запрос или на транзакцию, это может занимать много места. Если у вас миллион TCP-соединений, это миллион буферов сокетов. Если вы оборачиваете каждый из них в BufferedOutputStream, PrintStream или что-то в этом роде, это много памяти. Мы работали над подобными вещами и в JDK, но я уверен, что дальше по стеку у людей будет много данных на запрос или на транзакцию.


Третье, как я уже говорил, переход от мониторов к java.util.concurrent позволяет избежать краткосрочных проблем.


Я говорил в основном о виртуальном потоке как о потоке в коде, но давайте поговорим о нескольких других вещах.


Расскажу немного об отладчике.



При отладке действительно важно, чтобы при движении по шагам, вы
работали в каком-то контексте. Обычно отладчики Java (в IntelliJ, NetBeans, Eclipse) используют интерфейс отладчика под названием JDI, где под капотом находится wire protocol, а в виртуальной машине есть интерфейс инструментов, называемый JVM Tool Interface или JVM TI, как мы его иногда называем. Это все необходимо обновить, чтобы иметь возможность поддерживать виртуальные потоки.


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


Кроме того, наш подход к поддержке подобного в отладчиках оказался сбивающим с толку. Отладчик видит два потока: основной носитель (поток нашей ОС) и виртуальный поток. С этим было связано с множеством проблем, поэтому мы решили остановиться и пересмотреть все это. Так что это область сейчас работает не очень хорошо, но мы близки к тому, чтобы решить эти проблемы. Так что в это время ведется гигантский объем работы для повторной реализации и перестройки частей JVM TI для лучшей поддержки виртуальных потоков.


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


И последнее, что нужно сказать об отладчиках: кто-то спрашивает, когда мы все это доделаем, будут ли имеющиеся отладчики просто работать? Мы ожидаем, что в отладчики и инструментарий потребуется внести хотя бы некоторые небольшие изменения, чтобы они могли работать с виртуальными потоками. В основном на фронте масштабируемости, не имеет смысла пытаться визуализировать миллион потоков в отладчике. Такие вещи, как группы потоков это уже легаси, и попытки визуализировать что-либо в группах потоков, вероятно, не будут работать хорошо.


Перейдем к виртуальным потокам в профилировщике.


Это тоже очень важная область. Java Flight Recorder был обновлен в сборках Loom для поддержки виртуальных потоков. Я не был уверен, что во время доклада успею продемонстрировать использование JFR с виртуальными потоками, поэтому вместо этого я просто зафиксировал вывод команды print в JFR, просто чтобы показать вам, на что он способен.


В данном случае я сделал запись с JFR.



Он просто называется server.jfr, это имя файла записи. Эта конкретная запись была сделана при запуске сервера Jetty, настроенного для использования виртуальных потоков. Выходные данные показывают одно событие, чтение сокета. И оно произошло в виртуальном потоке. JFR по умолчанию имеет порог, кажется, около 200 мс, он может захватывать медленную операцию чтения, которая занимает больше времени, чем время порога.


Давайте расскажу, что именно здесь запечатлено. virtual = true указывает на то, что это виртуальный поток. Я распечатал всю трассировку стека, поэтому вы можете увидеть, что это действительно работает в виртуальном потоке, мы видим все фреймы, тут используются java.net.url и HTTP для чтения сокета, и это блокирует более чем на 200 мс. Это записано здесь в этой трассировке стека. Это то, что вы можете делать с JFR, что весьма полезно.


Помимо Flight Recorder, поддерживающего виртуальные потоки, существует множество других инструментов и профилировщиков, использующих JVM TI, поэтому нам приходится работать над множеством вещей, чтобы иметь возможность поддерживать профилировщики на основе JVM TI, работающие с виртуальными потоками.


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


То же самое и с профилировщиками. Если их используют для приложения с миллионом потоков, не думаю, что следует пытаться визуализировать их все, это будет неудобно для пользователя. Это область, которая, вероятно, не будет масштабироваться, по крайней мере, с точки зрения пользовательского интерфейса. Это тип проблем, с которыми мы сталкиваемся при работе с некоторыми инструментами.


Serviceability


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


Я показал вам довольно простую распечатку трассировки стека, когда потоки закреплены. Будут и другие сценарии, значимые для разработчиков. Они не смогут идентифицировать, например, запущенные виртуальные потоки, выполняющие вычислительные задачи (упирающиеся в CPU), они никогда не блокируются. Было бы полезно идентифицировать их.


Дамп потоков это то, с чем мы боролись в течение некоторого времени. Люди привыкли использовать дампы потоков для устранения неполадок, но что это значит, если у вас миллион потоков? Вы хотите просто увидеть все потоки, но дедуплицировать их? Вы хотите иметь другие формы? Это те вещи, которые нам еще предстоит изучить.


Текущий статус того, где мы находимся с Loom


Цель состоит в том, чтобы получить первую демо-версию с виртуальными потоками. У нас был ряд проблем со стабильностью, неприятные сбои, но мы думаем, что уже решили большинство из этих проблем.


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


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


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


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


Что еще нужно сделать для нашего первого Preview: нам необходимо выполнить перенос на ARM64 или Aarch64, мы были сосредоточены на 64-разрядной версии Intel на сегодняшний день; и нам нужно что-то сделать с дампом потоков.


Направления для будущего развития


Я должен упомянуть еще несколько аспектов этого проекта. Это такой список из будущего: мы не ожидаем, что перечисленное в нём будет в первой версии.


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


Как вы видите в других моделях программирования, CSP или Actors. У других языков есть каналы, у Erlang есть почтовые ящики. В Java есть вещи, близкие к этому: есть BlockingQueues, SynchronousQueue, у которой нет емкости, LinkedTransferQueue, у которой есть емкость.


Профессор Даг Ли работал с нами над этим проектом, и он обновил реализации блокирующих очередей в java.util.concurrent, так что они дружелюбны к виртуальным потокам. Он также изучает то, что ближе к каналам. Текущее рабочее название этого проекта conduits, а не каналы, потому что у нас есть каналы в пакете java.nio.channels. Посмотрим, как это пойдет.


Другая область это структурированная многопоточность. При структурированном программировании последовательное выполнение ограничено каким-либо четко
определенным блоком кода. Структурированная многопоточность заключается в распространении контроля на многопоточную среду. По сути, если задача управления разделяется на несколько задач или потоков в некоторой области, то им необходимо снова объединиться, прежде чем выйти из этой области.


В ранних прототипах Project Loom у нас действительно были первые прототипы для исследований в этой области. И мы вернемся к этому, есть проблемные области, связанные с этим. Распространение исключений и ошибок, отмена выполнения и так далее. На данный момент мы сделали, и я показывал это в демонстрациях, модифицировали ExecutorService, чтоб он расширял AutoCloseable, чтобы, по крайней мере, мы могли иметь некоторую конструкцию, которая гарантирует, что все потоки завершатся до продолжения основного потока.


Со структурированной многопоточностью связано то, что мы называем структурированным serviceability или структурированным observability. Я упоминал о проблемах профилировщиков, отладчиков и других инструментов, пытающихся
визуализировать миллионы потоков. Что, если бы эти инструменты каким-то образом исследовали бы структуру или отношения между потоками. Тогда, возможно, нам лучше бы удалось это визуализировать. На это мы готовы потратить больше времени.


Последний пункт в этом списке отмена. Мы сделали несколько прототипов в этой области, несколько прототипов кооперативной отмены. В Java есть механизм прерывания, это устаревший механизм, но на самом деле он очень хорошо работает с виртуальными потоками. Для большинства разработчиков этот механизм находится на слишком низком уровне. Мы хотим понять, сможем ли мы сделать что-то лучше. У нас были механизмы отмены в ранних прототипах. Я полагаю, что основная проблема заключается в том, что наличие двух механизмов одновременно может сбивать с толку, поэтому необходимо подумать над этим немного времени, прежде чем принимать какие-то решения по этому поводу.


Главные выводы


Основные выводы из этого доклада:


Виртуальный поток это поток в коде, во время выполнения, в отладчике, профилировщике и других инструментах.


Виртуальный поток это не оболочка вокруг потока ОС, а, по сути, просто объект Java.


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


Блокировка в виртуальном потоке стоит мало, что позволяет использовать синхронный стиль.


Немного дополнительной информации


Один из замечательных способов внести свой вклад в такой проект, как Project Loom, это загружать его сборки (или делать их самостоятельно из кода) и пробовать его с реальными приложениями. Отправляйте отзывы о производительности, сообщениях об ошибках, проблемах и опыте. Такие вещи очень полезны для такого проекта.


Вот ссылки на сборки раннего доступа: https://jdk.java.net/loom
Список рассылки: loom-dev@openjdk.java.net
И вики-страница: https://wiki.openjdk.java.net/display/loom/Main


У нас не очень получается поддерживать вики-страницу, поэтому список рассылки лучшее место для поиска чего-либо.


Это все, что я хотел рассказать.


Напоследок традиционный слайд Safe harbor: не верьте ничему, что я говорю.



Как можно понять по этому докладу, на наших Java-конференциях хватает хардкора: тут про Java-платформу порой рассказывают те люди, которые её и делают. В апреле мы проведём JPoint, и там тоже будет интересный состав спикеров (многие знают, например, Джоша Лонга из VMware). Часть имён уже названа на сайте, а другие позже появятся там же.
Подробнее..

Application performance management (APM) от Broadcom для мониторинга производительности приложений (включая мобильные)

24.02.2021 08:04:01 | Автор: admin
Всем привет! В этой статье расскажем о возможностях мониторинга производительности приложений одного из лидеров квадранта Gartner c APM-решениями Broadcom.

image

Appdynamics, Dynatrace и New Relic достаточно известны на российском рынке. Broadcom чуть менее знаком, этакая серая лошадка, однако, имеет не уступающий всем троим функционал мониторинга приложений. А использование APM-решения от Broadcom в комплексе с другим их продуктом, зонтичной AIOps-системой DX Operations Intelligence, позволит создать единое окно мониторинга для разнокалиберного ПО и инфраструктуры. Под катом текст и скриншоты.

Для мониторинга производительности приложений Broadcom поставляет два решения: DX APM и DX AXA. Первое работает с бэкэндом, второе с фронтэндом и мобильными приложениями.

DX APM


Архитектура DX APM


DX Applications Performance Management (APM) предназначен для мониторинга производительности приложений, написанных на Java, .NET, C++, PHP, Node.js, Python, Go и использующих другие технологии. Полный список поддерживаемых технологий можно посмотреть в Compatibility Guide. На ниже приведена область задач мониторинга, которые закрывает DX APM.



Основные особенности DX APM:

  • Распределенная (микросервисная) архитектура решения;
  • Простота в установке, использовании и обновлении;
  • Простота развертывания агентов, в том числе для микросервисных приложений, развернутых в кластере Kubernetes или Openshift;
  • Способность преждевременно выявлять нештатные ситуации до того, как это отразится на опыте конечных пользователей;
  • Автоматический поиск первопричины отказа или возникновения нештатных ситуаций как на программном так и на инфраструктурном уровнях;
  • Является поставщиком необходимой и достаточной информации для разработчиков, операционных подразделений заказчика и бизнес-ориентированных групп.

В спектр задач, решаемых DX APM входят:

  • Мониторинг производительности приложений;
  • Мониторинг опыта пользователей и бизнес-контекста;
  • Мониторинг отклика БД, инфраструктурных компонентов приложения и внешних сервисов;
  • Аналитика и root cause analysis.



DX APM предоставляет различные варианты для визуализации данных:

Experience View. Представление данных с точки зрения оценки опыта конечных пользователей. Данные представлены в виде Experience Cards. Experience card предоставляет верхнеуровневый обзор здоровья для транзакций. Транзакции объединены в Experience Card по заданным атрибутам.

Так выглядит набор Experience Cards:


А так отдельная Experience Card:


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



В DX APM есть возможность интеллектуальной группировки компонент приложения по атрибутам, что помогает упростить и адаптировать вид транзакционной карты приложений для каждой роли пользователей. Например, можно сделать специальное представление для ответственных за определённую часть приложения.



Если приложение микросервисное, DX APM распознает используемые технологии в рамках поддерживаемых и создаст соответствующую визуализацию.



Ещё одно важное преимущество решения от Broadcom наличие универсального агента Universal Monitoring Agent (UMA) для различных технологий. UMA устанавливается единожды на кластер, где развернуто микросервисное приложение, далее агент сам отслеживает динамические изменения и ведет мониторинг как инфраструктурных компонент кластера (nodes, pods, containers) так и осуществляет технологический мониторинг приложений в части исполнения кода. С точки зрения автоматизации мониторинга самое оно.



Расследование проблем DX APM


DX APM для ускорения поиска первопричины проблемы в снижении производительности использует в работе запатентованные технологии: Differential Analysis, Timeline View и Assisted Triage, Topology View/Layers. Во многих случаях упреждающие оповещения (на основе аномального поведения), генерируемые DX APM, позволяют избежать реальных проблем в будущем.

Assisted Triage сигнализирует о наличии проблем и аномалий в работе приложений и в автоматическом режиме предоставляет заключение о первоисточнике проблемы, тем самым обеспечивая root-cause analysis. Аномалии указывают на нестрандартное поведение в работе приложении, но при этом воздействия на опыт конечных пользователей еще нет. Так выглядит работа Assisted Triage



Для детального анализа оповещений, генерируемых Assistage Triage, и выявления проблемных компонентов в транзакционной цепочке по клику на оповещение можно перейти в центр расследований Analysis Notebook. Тут, на представлении в виде таймлайна можно увидеть процесс развития проблемы и возникновение параллельных событий.



Так выглядит сопоставление проблемных транзакций с компонентами приложения и инфраструктурой.



Функция Timeline позволяет быстро увидеть изменения в архитектуре приложения во времени в контексте проблем с производительностью, не покидая Map View. Особенно это эффективно при обновлении релиза приложения позволит увидеть все проблемы разом.



При возникновения проблем в работе приложения, разработчикам будет интересно и полезно проанализировать транзакционные трейсы. DX APM предусматривает как функционал автоматической записи трейсов Smart Instrumentation, так и возможности запуска ручной трассировки. DX APM автоматически записывает трассировки транзакций при возникновении следующих событий:

  • В случае ошибок;
  • В случае нестабильного поведения в работе приложения (на основе изменяющегося времени отклика между компонентами приложения или так называемого Differential Analysis).



Использование коммерческими решения открытых решений заметный тренд последнего времени. DX APM поддерживает технологию OpenTracing. При этом решение получает данные о показателях и трассировках транзакций из приложений, оснащенных трассировщиками, совместимыми с OpenTracing. Как результат, можно видеть в UI DX APM целостную транзакционную цепочку (MAP) и сквозной транзакционный трейс. Это особенно актуально для распределённых микросервисных приложений.



Ещё одной важной функцией при расследовании проблем снижения производительности в работе приложения является анализ SQL-запросов к базам данных и мониторинг производительности баз данных. DX APM предоставляет такие возможности для наиболее популярных баз данных, таких как Oracle, MS SQL и некоторых других.



Business Payload Analyzer


Business Payload Analyzer (BPA) это запатентованная функция сбора и анализа данных (Payload транзакций), которая помогает использовать бизнес-контекст для именования транзакций. На рисунке 23 представлено позиционирования BPA по отношению к AXA и APM. По сути, как и AXA (через Browser agent и мобильный SDK) BPA является поставщиком метаданных для APM и помогает в определении бизнес-транзакций.



Физически, BPA является плагином, который устанавливается на web-сервер приложения. Плагин собирает сырые http-данные (после дешифрования серверов https-трафика) каждого запроса и ответа и заливает их в DX APM для дальнейшей обработки и формирования бизнес-транзакций. В текущей версии DX APM 20.2 плагин BPA доступен для:

  • Apache Web Server Plugin for Linux and Windows;
  • IIS Plugin;
  • Nginx Web Server Plugin.

DX AXA


DX AXA (Application Experience Analytics) ориентирован на мониторинг взаимодействия пользователeй с фронтэндом через браузер или мобильное приложение на своём гаджете. Данные, собираемые AXA, могут быть использованы как разработчиками для оптимизации работы приложений, так и бизнес-аналитиками для формирования отчетности о доступности сервисов и планирования бизнес-KPI. Фокус AXA в задаче мониторинга опыта конечных пользователей представлен на рисунке ниже.



DX AXA получает данные по транзакциям пользователей мобильных приложений с помощью интеграции SDK в приложение. В список поддерживаемых платформ включены: Android, iOS, WatchOS. Стоит отметить, что процедура встраивания инструментария SDK в приложения Android очень проста, осуществляется в web-интерфейсе AXA в несколько кликов мыши и не требует привлечения разработчиков.

Также AXA покрывает мониторинг и web-транзакций пользователей с помощью Browser Agent. Browser agent это snippet (скрипт), который встраивается в домашнюю страницу приложения, и при взимодейсвии пользователя с приложением собирает и отправляет метрики взаимодействия на сервер AXA для анализа. Таким образом, это не требует установки агента на рабочих станциях конечных пользователей. Browser agent имеет широкий спектр возможностей по кастомизации и сбору данных. При этом поддерживаются web-транзакции во всех популярных браузерах.



Основной спектр задач, который решает AXA для команд эксплуатации являются:
  • Сегментация данных по версии приложения, провайдеру / wifi, местоположению, платформе, ОС;
  • Оповещения в режиме реального времени о снижении в производительности в работе приложений, пользовательскго опыта и нарушнении SLA, и потенциальных рисков для доходов компании;
  • Ускорение выявления первопричины проблемы.



В список функций, предназначенных для разработчиков приложений входят:

1. Просмотр скриншотов и видео взаимодействия пользователя с приложением,
оптимизация приложений на основе анализа наиболее популярных действий пользователя в приложении.



2. Сегментация сбоев по платформе, устройству. Индикация и детальные данные по App Crashes, HTTP и JavaScript Errors.



3. Просмотр параметров производительности для каждой сессии пользователя.



4. Функция Resource Waterfall обеспечивает более глубокое понимание производительности веб-приложений, отображая подробную информацию о времени загрузки всех компонентов веб-сайта.



Фунционал по разработке отчетности и визуализации данных способен удовлетворить требования бизнеса по планированию доходов и оценке затрат на модернизацию приложений:

  • Приоритезация проблем путем оценки влияния на доходы компании;
  • Возможность задания KPI для оценки ROI;
  • Дополнительные данные для формирования OPEX и CAPEX.





DX AXA имеет глубокую интеграцию с продуктом DX Application Performance Management (APM) для расследования проблем, не связанных с фунционированием фронтэнда. DX AXA при этом является дополнительным поставщиком данных для DX APM по транзакциям, совершаемым пользователями с помощью мобильных приложений.



Интеграция DX APM и DX AXA с DX Operational Intelligence


DX Operations Intelligence это зонтичная система мониторинга, в которой реализованы функции Machine Learning и Artificial Intelligence (ML и AI) над поступающими в платформу данными. Одними из поставщиков таких данных (наравне с Zabbix, Prometheus и прочими) являются DX APM и DX AXA.

DX AXA и DX APM работают в составе платформы DX. Платформа DX устанавливается и работает под управлением кластеров Kubernetes или OpenShift. Установщик платформы DX это консольное приложение, которое запускается пв докер-контейнере и поэтому имеет минимальные зависимости от операционной системы. Программа установки взаимодействует с кластером и выполняет все необходимые действия для создания готового к использованию экземпляра платформы DX. Установщик платформы DX также поддерживает развертывание с хоста, который не является частью кластера.
Используя установщик платформы DX, вы можете установить следующие компоненты:

  • Мониторинг производительности приложений DX APM
  • Мониторинг мобильных приложений DX AXA
  • Зонтичное решение DX OI



Администрирование, масштабирование и обновление платформы DX выполняется в административной консоли. Консоль поддерживает мультитенантную архитектуру, которая позволяет использовать один экземпляр консоли для администрирования нескольких предприятий или нескольких бизнес-единиц в рамках предприятия. В этой модели каждое предприятие может быть настроено индивидуально как арендатор со своим собственным набором конфигураций.
Консоль администрирования это веб-инструмент для управления операциями и системой, который предоставляет администраторам согласованный унифицированный интерфейс для выполнения следующих задач:

  • Создание и управление тенантами;
  • Мониторинг и управление ресурсами кластера и сервисами;
  • Создание учетных записей администраторов и пользователей и управление ими;
  • Управление учетными записями пользователей на основе LDAP;
  • Создание и управление учетными записями пользователей, не использующих LDAP;
  • Настройка параметров почтового сервера.





Broadcom безвозмездно предоставит в пользование продукт DX Operational Intelligence Foundation (DX OI) при приобретении лицензий DX APM. DX OI Foundation позволит реализовать фукнции Machine Learning над поступающими в платформу данными (логи, метрики, аварийные сообщения, топология) и оценить/спрогнозировать доступность сервисов на базе анализа поступающих данных. Кроме того, DX OI Foundation может стать единой точкой концентрации аварийных сообщений и интеграции с системой Service Desk.

К сведению: по сравнению с полной версией DX OI, версия Foundation имеет ограничения по времени хранения данных, также есть ограничения по функциям Predictive Insights, Capacity Analytics и интеграции со сторонними системами через Open RESTful APIs. Для снятия этих ограничений необходимо отдельно приобрести лицензии на решение DX OI.

Ну, и напоследок, важное замечание: все перечисленные в этой статье решения Broadcom можно использовать как on-premise так и в SaaS-формате.

Если у вас появились вопросы или вы хотите узнать больше об этом решении, оставьте заявку на демонстрацию или пилотный проект удобным для вас способом на нашем сайте.

В ближайшее время мы проведём вебинар по DX APM и DX AXA. Если вы хотели бы узнать подробнее об этих решениях, оставьте заявку и вам вышлем приглашение как только анонсируем вебинар.

А ещё у нас есть:

Запись нашего вебинара по DX OI

Статья на Хабре о зонтичной AIOps-системе мониторинга DX OI

Группа в Facebook

Канал в Youtube
Подробнее..

Мониторинг производительности приложений в Broadcom DX APM анонс вебинара

02.03.2021 10:09:04 | Автор: admin
image

Единый агент для всех популярных технологий, динамическое отслеживание изменений инфраструктуры, низкий оверхед, искусственный интеллект, оценка эффективности релизов, контекстный мониторинг, мониторинг реальных транзакций обо всём этом и многом другом вы узнаете на вебинаре, посвящённому инструменту для мониторинга производительности приложений и инфраструктуры под ними Broadcom DX APM. Вебинар состоится 5 марта в 11 часов утра по московскому времени.

Регистрация на вебинар

Под катом вы найдёте квадрант Gartner за 2020 год по APM-решениям и дополнительные материалы по DX APM и другим решениям Broadcom.


DX APM несколько лет подряд сохраняет лидерство. Решение регулярно обновляется, появляется новый функционал. Особенность продукта использование под капотом открытых технологий, например, OpenTelemetry. Этот тренд, кстати, распространяется и на некоторых других лидеров квадранта.

image

А ещё у нас есть:

Как устроен и работает DX APM

Запись нашего вебинара по зонтичной AIOps-системе мониторинг DX OI

Статья на Хабре о зонтичной AIOps-системе мониторинга DX OI

Группа в Facebook

Канал в Youtube
Подробнее..

Перевод Использование Google Protocol Buffers (protobuf) в Java

25.02.2021 20:10:38 | Автор: admin

Привет, хабровчане. В рамках курса "Java Developer. Professional" подготовили для вас перевод полезного материала.

Также приглашаем посетить открытый вебинар на тему gRPC для микросервисов или не REST-ом единым.


Недавно вышло третье издание книги "Effective Java" (Java: эффективное программирование), и мне было интересно, что появилось нового в этой классической книге по Java, так как предыдущее издание охватывало только Java 6. Очевидно, что появились совершенно новые разделы, связанные с Java 7, Java 8 и Java 9, такие как глава 7 "Lambdas and Streams" (Лямбда-выражения и потоки), раздел 9 "Prefer try-with-resources to try-finally" (в русском издании 2.9. Предпочитайте try-с-ресурсами использованию try-finally) и раздел 55 "Return optionals judiciously" (в русском издании 8.7. Возвращайте Optional с осторожностью). Но я был слегка удивлен, когда обнаружил новый раздел, не связанный с нововведениями в Java, а обусловленный изменениями в мире разработки программного обеспечения. Именно этот раздел 85 "Prefer alternatives to Java Serialization" (в русском издании 12.1 Предпочитайте альтернативы сериализации Java) и побудил меня написать данную статью об использовании Google Protocol Buffers в Java.

В разделе 85 "Prefer alternatives to Java Serialization" (12.1 Предпочитайте альтернативы сериализации Java) Джошуа Блох (Josh Bloch) выделяет жирным шрифтом следующие два утверждения, связанные с сериализацией в Java:

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

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

После описания в общих чертах проблем с десериализацией в Java и, сделав эти смелые заявления, Блох рекомендует использовать то, что он называет кроссплатформенным представлением структурированных данных (чтобы избежать путаницы, связанной с термином сериализация при обсуждении Java). Блох говорит, что основными решениями здесь являются JSON (JavaScript Object Notation) и Protocol Buffers (protobuf). Мне показалось интересным упоминание о Protocol Buffers, так как в последнее время я немного читал о них и игрался с ними. В интернете есть довольно много материалов по использованию JSON (даже в Java), в то время как осведомленность о Protocol Buffers среди java-разработчиков гораздо меньше. Поэтому я думаю, что статья об использовании Protocol Buffers в Java будет полезной.

На странице проекта Google Protocol Buffers описывается как не зависящий от языка и платформы расширяемый механизм для сериализации структурированных данных. Также там есть пояснение: Как XML, но меньше, быстрее и проще. И хотя одним из преимуществ Protocol Buffers является поддержка различных языков программирования, в этой статье речь пойдет исключительно про использование Protocol Buffers в Java.

Есть несколько полезных онлайн-ресурсов, связанных с Protocol Buffers, включая главную страницу проекта, страницу проекта protobuf на GitHub, proto3 Language Guide (также доступен proto2 Language Guide), туториал Protocol Buffer Basics: Java, руководство Java Generated Code Guide, API-документация Java API (Javadoc) Documentation, страница релизов Protocol Buffers и страница Maven-репозитория. Примеры в этой статье основаны на Protocol Buffers 3.5.1.

Использование Protocol Buffers в Java описано в туториале "Protocol Buffer Basics: Java". В нем рассматривается гораздо больше возможностей и вещей, которые необходимо учитывать в Java, по сравнению с тем, что я расскажу здесь. Первым шагом является определение формата Protocol Buffers, не зависящего от языка программирования. Он описывается в текстовом файле с расширением .proto. Для примера опишем формат протокола в файле album.proto, который показан в следующем листинге кода.

album.proto

syntax = "proto3";option java_outer_classname = "AlbumProtos";option java_package = "dustin.examples.protobuf";message Album {    string title = 1;    repeated string artist = 2;    int32 release_year = 3;    repeated string song_title = 4;}

Несмотря на простоту приведенного выше определения формата протокола, в нем присутствует довольно много информации. В первой строке явно указано, что используется proto3 вместо proto2, используемого по умолчанию, если явно ничего не указано. Две строки, начинающиеся с option, указывают параметры генерации Java-кода (имя генерируемого класса и пакет этого класса) и они нужны только при использовании Java.

Ключевое слово "message" определяет структуру "Album", которую мы хотим представить. В ней есть четыре поля, три из которых строки (string), а одно целое число (int32). Два из них могут присутствовать в сообщении более одного раза, так как для них указано зарезервированное слово repeated. Обратите внимание, что формат сообщения определяется независимо от Java за исключением двух option, которые определяют детали генерации Java-классов по данной спецификации.

Файл album.proto, приведенный выше, теперь необходимо скомпилировать в файл исходного класса Java (AlbumProtos.java в пакете dustin.examples.protobuf), который можно использовать для записи и чтения бинарного формата Protocol Buffers. Генерация файла исходного кода Java выполняется с помощью компилятора protoc, соответствующего вашей операционной системе. Я запускаю этот пример в Windows 10, поэтому я скачал и распаковал файл protoc-3.5.1-win32.zip. На изображении ниже показан мой запущенный protoc для album.proto с помощью команды protoc --proto_path=src --java_out=dist\generated album.proto

Перед запуском вышеуказанной команды я поместил файл album.proto в каталог src, на который указывает --proto_path, и создал пустой каталог build\generated для размещения сгенерированного исходного кода Java, что указано в параметре --java_out.

Сгенерированный Java-класс AlbumProtos.java содержит более 1000 строк, и я не буду приводить его здесь, он доступен на GitHub. Среди нескольких интересных моментов относительно сгенерированного кода я хотел бы отметить отсутствие выражений import (вместо них используются полные имена классов с пакетами). Более подробная информация об исходном коде Java, сгенерированном protoc, доступна в руководстве Java Generated Code. Важно отметить, что данный сгенерированный класс AlbumProtos пока никак не связан с моим Java-приложением, и сгенерирован исключительно из текстового файла album.proto, приведенного ранее.

Теперь исходный Java-код AlbumProtos надо добавить в вашем IDE в перечень исходного кода проекта. Или его можно использовать как библиотеку, скомпилировав в .class или .jar.

Прежде чем двигаться дальше, нам понадобится простой Java-класс для демонстрации Protocol Buffers. Для этого я буду использовать класс Album, который приведен ниже (код на GitHub).

Album.java

package dustin.examples.protobuf;import java.util.ArrayList;import java.util.List;/** * Music album. */public class Album {    private final String title;    private final List < String > artists;    private final int releaseYear;    private final List < String > songsTitles;    private Album(final String newTitle, final List < String > newArtists,        final int newYear, final List < String > newSongsTitles) {        title = newTitle;        artists = newArtists;        releaseYear = newYear;        songsTitles = newSongsTitles;    }    public String getTitle() {        return title;    }    public List < String > getArtists() {        return artists;    }    public int getReleaseYear() {        return releaseYear;    }    public List < String > getSongsTitles() {        return songsTitles;    }    @Override    public String toString() {        return "'" + title + "' (" + releaseYear + ") by " + artists + " features songs " + songsTitles;    }    /**     * Builder class for instantiating an instance of     * enclosing Album class.     */    public static class Builder {        private String title;        private ArrayList < String > artists = new ArrayList < > ();        private int releaseYear;        private ArrayList < String > songsTitles = new ArrayList < > ();        public Builder(final String newTitle, final int newReleaseYear) {            title = newTitle;            releaseYear = newReleaseYear;        }        public Builder songTitle(final String newSongTitle) {            songsTitles.add(newSongTitle);            return this;        }        public Builder songsTitles(final List < String > newSongsTitles) {            songsTitles.addAll(newSongsTitles);            return this;        }        public Builder artist(final String newArtist) {            artists.add(newArtist);            return this;        }        public Builder artists(final List < String > newArtists) {            artists.addAll(newArtists);            return this;        }        public Album build() {            return new Album(title, artists, releaseYear, songsTitles);        }    }}

Теперь у нас есть data-класс Album, Protocol Buffers-класс, представляющий этот Album (AlbumProtos.java) и мы готовы написать Java-приложение для "сериализации" информации об Album без использования Java-сериализации. Код приложения находится в классе AlbumDemo, полный код которого доступен на GitHub.

Создадим экземпляр Album с помощью следующего кода:

/** * Generates instance of Album to be used in demonstration. * * @return Instance of Album to be used in demonstration. */public Album generateAlbum(){   return new Album.Builder("Songs from the Big Chair", 1985)      .artist("Tears For Fears")      .songTitle("Shout")      .songTitle("The Working Hour")      .songTitle("Everybody Wants to Rule the World")      .songTitle("Mothers Talk")      .songTitle("I Believe")      .songTitle("Broken")      .songTitle("Head Over Heels")      .songTitle("Listen")      .build();}

Класс AlbumProtos, сгенерированныйProtocol Buffers, включает в себя вложенный класс AlbumProtos.Album, который используется для бинарной сериализации Album. Следующий листинг демонстрирует, как это делается.

final Album album = instance.generateAlbum();final AlbumProtos.Album albumMessage    = AlbumProtos.Album.newBuilder()        .setTitle(album.getTitle())        .addAllArtist(album.getArtists())        .setReleaseYear(album.getReleaseYear())        .addAllSongTitle(album.getSongsTitles())        .build();

Как видно из предыдущего примера, для заполнения иммутабельного экземпляра класса, сгенерированного Protocol Buffers, используется паттерн Строитель (Builder). Через ссылку экземпляр этого класса теперь можно легко преобразовать объект в бинарный вид Protocol Buffers, используя метод toByteArray(), как показано в следующем листинге:

final byte[] binaryAlbum = albumMessage.toByteArray();

Чтение массива byte[] обратно в экземпляр Album может быть выполнено следующим образом:

/** * Generates an instance of Album based on the provided * bytes array. * * @param binaryAlbum Bytes array that should represent an *    AlbumProtos.Album based on Google Protocol Buffers *    binary format. * @return Instance of Album based on the provided binary form *    of an Album; may be {@code null} if an error is encountered *    while trying to process the provided binary data. */public Album instantiateAlbumFromBinary(final byte[] binaryAlbum) {    Album album = null;    try {        final AlbumProtos.Album copiedAlbumProtos = AlbumProtos.Album.parseFrom(binaryAlbum);        final List <String> copiedArtists = copiedAlbumProtos.getArtistList();        final List <String> copiedSongsTitles = copiedAlbumProtos.getSongTitleList();        album = new Album.Builder(                copiedAlbumProtos.getTitle(), copiedAlbumProtos.getReleaseYear())            .artists(copiedArtists)            .songsTitles(copiedSongsTitles)            .build();    } catch (InvalidProtocolBufferException ipbe) {        out.println("ERROR: Unable to instantiate AlbumProtos.Album instance from provided binary data - " +            ipbe);    }    return album;}

Как вы заметили, при вызове статического метода parseFrom(byte []) может быть брошено проверяемое исключение InvalidProtocolBufferException. Для получения десериализованного экземпляра сгенерированного класса, по сути, нужна только одна строка, а остальной код это создание исходного класса Album из полученных данных.

Демонстрационный класс включает в себя две строки, которые выводят содержимое исходного экземпляра Album и экземпляра, полученного из бинарного представления. В них есть вызов метода System.identityHashCode() на обоих экземплярах, чтобы показать, что это разные объекты даже при совпадении их содержимого. Если этот код выполнить с примером Album, приведенным выше, то результат будет следующим:

BEFORE Album (1323165413): 'Songs from the Big Chair' (1985) by [Tears For Fears] features songs [Shout, The Working Hour, Everybody Wants to Rule the World, Mothers Talk, I Believe, Broken, Head Over Heels, Listen]AFTER Album (1880587981): 'Songs from the Big Chair' (1985) by [Tears For Fears] features songs [Shout, The Working Hour, Everybody Wants to Rule the World, Mothers Talk, I Believe, Broken, Head Over Heels, Listen]

Здесь мы видим, что в обоих экземплярах соответствующие поля одинаковы и эти два экземпляра действительно разные. При использовании Protocol Buffers, действительно, нужно сделать немного больше работы, чем припочти автоматическом механизме сериализации Java, когда надо просто наследоваться от интерфейса Serializable, но есть важные преимущества, которые оправдывают затраты. В третьем издании книги Effective Java (Java: эффективное программирование) Джошуа Блох обсуждает уязвимости безопасности, связанные со стандартной десериализацией в Java, и утверждает, что Нет никаких оснований для использования сериализации Java в любой новой системе, которую вы пишете.


Узнать подробнее о курсе "Java Developer. Professional".

Смотреть открытый вебинар на тему gRPC для микросервисов или не REST-ом единым.

Подробнее..

Перевод Реализация мультиарендности с использованием Spring Boot, MongoDB и Redis

28.02.2021 18:05:07 | Автор: admin

В этом руководстве мы рассмотрим, как реализовать мультиарендность в Spring Boot приложении с использованием MongoDB и Redis.

Используются:

  • Spring Boot 2.4

  • Maven 3.6. +

  • JAVA 8+

  • Монго 4.4

  • Redis 5

Что такое мультиарендность?

Мультиарендность (англ. multitenancy множественная аренда) это программная архитектура, в которой один экземпляр программного приложения обслуживает нескольких клиентов.Все должно быть общим, за исключением данных разных клиентов, которые должны быть должным образом разделены.Несмотря на то, что они совместно используют ресурсы, арендаторы не знают друг друга, и их данные хранятся совершенно отдельно.Каждый покупатель называется арендатором.

Предложение программное обеспечение как услуга (SaaS) является примером мультиарендной архитектуры.Более подробно.

Модели с несколькими арендаторами

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

  1. База данных для каждого арендатора: каждый арендатор имеет свою собственную базу данных и изолирован от других арендаторов.

  2. Общая база данных, общая схема:все арендаторы совместно используют базу данных и таблицы.В каждой таблице есть столбец с идентификатором клиента, который показывает владельца строки.

  3. Общая база данных, отдельная схема: все арендаторы совместно используют базу данных, но имеют свои собственные схемы и таблицы базы данных.

Начнем

В этом руководстве мы реализуем мультиарендность на основе базы данных для каждого клиента.

Мы начнем с создания простого проекта Spring Boot наstart.spring.ioсо следующими зависимостями:

<dependencies>    <dependency>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-starter-data-mongodb</artifactId>    </dependency>    <dependency>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-starter-web</artifactId>    </dependency>    <dependency>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-starter-data-redis</artifactId>    </dependency>    <dependency>        <groupId>redis.clients</groupId>        <artifactId>jedis</artifactId>    </dependency>    <dependency>        <groupId>org.projectlombok</groupId>        <artifactId>lombok</artifactId>        <optional>true</optional>    </dependency></dependencies>

Определение текущего идентификатора клиента

Идентификатор клиента необходимо определить для каждого клиентского запроса.Для этого мы включим поле идентификатора клиента в заголовок HTTP-запроса.

Давайте добавим перехватчик, который получает идентификатор клиента из http заголовкаX-Tenant.

@Slf4j@Componentpublic class TenantInterceptor implements WebRequestInterceptor {    private static final String TENANT_HEADER = "X-Tenant";    @Override    public void preHandle(WebRequest request) {        String tenantId = request.getHeader(TENANT_HEADER);        if (tenantId != null && !tenantId.isEmpty()) {            TenantContext.setTenantId(tenantId);            log.info("Tenant header get: {}", tenantId);        } else {            log.error("Tenant header not found.");            throw new TenantAliasNotFoundException("Tenant header not found.");        }    }    @Override    public void postHandle(WebRequest webRequest, ModelMap modelMap) {        TenantContext.clear();    }    @Override    public void afterCompletion(WebRequest webRequest, Exception e) {    }}

TenantContextэто хранилище, содержащее переменную ThreadLocal.ThreadLocal можно рассматривать как область доступа (scope of access), такую как область запроса (request scope) или область сеанса (session scope).

Сохраняя tenantId в ThreadLocal, мы можем быть уверены, что каждый поток имеет свою собственную копию этой переменной и что текущий поток не имеет доступа к другому tenantId:

@Slf4jpublic class TenantContext {    private static final ThreadLocal<String> CONTEXT = new ThreadLocal<>();    public static void setTenantId(String tenantId) {        log.debug("Setting tenantId to " + tenantId);        CONTEXT.set(tenantId);    }    public static String getTenantId() {        return CONTEXT.get();    }    public static void clear() {        CONTEXT.remove();    }}

Настройка источников данных клиента (Tenant Datasources)

В нашей архитектуре у нас есть экземпляр Redis, представляющий базу метаданных (master database), в которой централизована вся информация о базе данных клиента.Таким образом, из каждого предоставленного идентификатора клиента информация о подключении к базе данных извлекается из базы метаданных .

RedisDatasourceService.java это класс, отвечающий за управление всеми взаимодействиями с базой метаданных .

@Servicepublic class RedisDatasourceService {    private final RedisTemplate redisTemplate;    private final ApplicationProperties applicationProperties;    private final DataSourceProperties dataSourceProperties;public RedisDatasourceService(RedisTemplate redisTemplate, ApplicationProperties applicationProperties, DataSourceProperties dataSourceProperties) {        this.redisTemplate = redisTemplate;        this.applicationProperties = applicationProperties;        this.dataSourceProperties = dataSourceProperties;    }        /**     * Save tenant datasource infos     *     * @param tenantDatasource data of datasource     * @return status if true save successfully , false error     */        public boolean save(TenantDatasource tenantDatasource) {        try {            Map ruleHash = new ObjectMapper().convertValue(tenantDatasource, Map.class);            redisTemplate.opsForHash().put(applicationProperties.getServiceKey(), String.format("%s_%s", applicationProperties.getTenantKey(), tenantDatasource.getAlias()), ruleHash);            return true;        } catch (Exception e) {            return false;        }    }        /**     * Get all of keys     *     * @return list of datasource     */         public List findAll() {        return redisTemplate.opsForHash().values(applicationProperties.getServiceKey());    }        /**     * Get datasource     *     * @return map key and datasource infos     */         public Map<String, TenantDatasource> loadServiceDatasources() {        List<Map<String, Object>> datasourceConfigList = findAll();        // Save datasource credentials first time        // In production mode, this part can be skip        if (datasourceConfigList.isEmpty()) {            List<DataSourceProperties.Tenant> tenants = dataSourceProperties.getDatasources();            tenants.forEach(d -> {                TenantDatasource tenant = TenantDatasource.builder()                        .alias(d.getAlias())                        .database(d.getDatabase())                        .host(d.getHost())                        .port(d.getPort())                        .username(d.getUsername())                        .password(d.getPassword())                        .build();                save(tenant);            });        }        return getDataSourceHashMap();    }        /**     * Get all tenant alias     *     * @return list of alias     */         public List<String> getTenantsAlias() {        // get list all datasource for this microservice        List<Map<String, Object>> datasourceConfigList = findAll();        return datasourceConfigList.stream().map(data -> (String) data.get("alias")).collect(Collectors.toList());    }        /**     * Fill the data sources list.     *     * @return Map<String, TenantDatasource>     */         private Map<String, TenantDatasource> getDataSourceHashMap() {        Map<String, TenantDatasource> datasourceMap = new HashMap<>();        // get list all datasource for this microservice        List<Map<String, Object>> datasourceConfigList = findAll();        datasourceConfigList.forEach(data -> datasourceMap.put(String.format("%s_%s", applicationProperties.getTenantKey(), (String) data.get("alias")), new TenantDatasource((String) data.get("alias"), (String) data.get("host"), (int) data.get("port"), (String) data.get("database"), (String) data.get("username"), (String) data.get("password"))));        return datasourceMap;    }}

В этом руководстве мы заполнили информацию о клиенте из yml-файла (tenants.yml).В производственном режиме можно создать конечные точки для сохранения информации о клиенте в базе метаданных.

Чтобы иметь возможность динамически переключаться на подключение к базе данных mongo, мы создаемкласс MultiTenantMongoDBFactory, расширяющий класс SimpleMongoClientDatabaseFactory из org.springframework.data.mongodb.core.Он вернетэкземплярMongoDatabase, связанный с текущим арендатором.

@Configurationpublic class MultiTenantMongoDBFactory extends SimpleMongoClientDatabaseFactory {@Autowired    MongoDataSources mongoDataSources;public MultiTenantMongoDBFactory(@Qualifier("getMongoClient") MongoClient mongoClient, String databaseName) {        super(mongoClient, databaseName);    }    @Override    protected MongoDatabase doGetMongoDatabase(String dbName) {        return mongoDataSources.mongoDatabaseCurrentTenantResolver();    }}

Нам нужно инициализироватьконструктор MongoDBFactoryMultiTenantс параметрами по умолчанию (MongoClientиdatabaseName).

Это реализует прозрачный механизм для получения текущего клиента.

@Component@Slf4jpublic class MongoDataSources {    /**     * Key: String tenant alias     * Value: TenantDatasource     */    private Map<String, TenantDatasource> tenantClients;    private final ApplicationProperties applicationProperties;    private final RedisDatasourceService redisDatasourceService;    public MongoDataSources(ApplicationProperties applicationProperties, RedisDatasourceService redisDatasourceService) {        this.applicationProperties = applicationProperties;        this.redisDatasourceService = redisDatasourceService;    }    /**     * Initialize all mongo datasource     */    @PostConstruct    @Lazy    public void initTenant() {        tenantClients = new HashMap<>();        tenantClients = redisDatasourceService.loadServiceDatasources();    }    /**     * Default Database name for spring initialization. It is used to be injected into the constructor of MultiTenantMongoDBFactory.     *     * @return String of default database.     */    @Bean    public String databaseName() {        return applicationProperties.getDatasourceDefault().getDatabase();    }    /**     * Default Mongo Connection for spring initialization.     * It is used to be injected into the constructor of MultiTenantMongoDBFactory.     */    @Bean    public MongoClient getMongoClient() {        MongoCredential credential = MongoCredential.createCredential(applicationProperties.getDatasourceDefault().getUsername(), applicationProperties.getDatasourceDefault().getDatabase(), applicationProperties.getDatasourceDefault().getPassword().toCharArray());        return MongoClients.create(MongoClientSettings.builder()                .applyToClusterSettings(builder ->                        builder.hosts(Collections.singletonList(new ServerAddress(applicationProperties.getDatasourceDefault().getHost(), Integer.parseInt(applicationProperties.getDatasourceDefault().getPort())))))                .credential(credential)                .build());    }    /**     * This will get called for each DB operations     *     * @return MongoDatabase     */    public MongoDatabase mongoDatabaseCurrentTenantResolver() {        try {            final String tenantId = TenantContext.getTenantId();            // Compose tenant alias. (tenantAlias = key + tenantId)            String tenantAlias = String.format("%s_%s", applicationProperties.getTenantKey(), tenantId);            return tenantClients.get(tenantAlias).getClient().                    getDatabase(tenantClients.get(tenantAlias).getDatabase());        } catch (NullPointerException exception) {            throw new TenantAliasNotFoundException("Tenant Datasource alias not found.");        }    }73}

Тест

Давайте создадим CRUD пример с документом Employee.

@Builder@Data@AllArgsConstructor@NoArgsConstructor@Accessors(chain = true)@Document(collection = "employee")public class Employee  {    @Id    private String id;    private String firstName;    private String lastName;    private String email;}

Также нам нужно создать классы EmployeeRepository, EmployeeServiceиEmployeeController.Для тестирования при запуске приложения мы загружаем фиктивные данные в каждую базу данных клиента.

@Overridepublic void run(String... args) throws Exception {    List<String> aliasList = redisDatasourceService.getTenantsAlias();    if (!aliasList.isEmpty()) {        //perform actions for each tenant        aliasList.forEach(alias -> {            TenantContext.setTenantId(alias);            employeeRepository.deleteAll();            Employee employee = Employee.builder()                    .firstName(alias)                    .lastName(alias)                    .email(String.format("%s%s", alias, "@localhost.com" ))                    .build();            employeeRepository.save(employee);            TenantContext.clear();        });    }}

Теперь мы можем запустить наше приложение и протестировать его.

Итак, мы все сделали. Надеюсь, это руководство поможет вам понять, что такое мультиарендность и как она может быть реализована в Spring Boot проекте с использованием MongoDB и Redis.

Полный исходный код примера можно найти наGitHub.

Подробнее..

Mockito. Из чего он приготовлен и как его подавать?

12.02.2021 16:06:23 | Автор: admin

Думаю, многим довелось выпить какой-нибудь напиток, который глубоко впился в наши вкусовые рецепторы, что нам хочется пить его каждый день. Так вот для меня таким напитком стал Mockito. Один раз написав простенький тест, можно вернуть себе веру в магию. Я всё ещё помню, как удивлялся тому, как он работает.

Чему же я удивился? Например, этому:

private static class Apple {   private String color;   public String getName() {return color;}}@Testpublic void basic() {   Apple apple = mock(Apple.class);   when(apple.getName()).thenReturn("Red");   assertEquals("Red", apple.getName()); // true}

С точки зрения написания кода, это очень красиво и понятно:

  • Мы создаём экземпляр-заглушку для класса Apple.
  • Затем мы как бы говорим, когда вызывается метод apple.getColor(), то верни Red.
  • Далее мы просто проверяем действительно ли apple.getColor() возвращает то, что мы хотим, и это работает!

Внимание! Не читайте дальше, если и дальше хотите верить в магию. Дальнейшее содержание статьи отнимет у вас и эту толику детского счастья.



Что такое Mockito?


Mockito является открытой библиотекой с лицензией MIT License.

Приведённый выше пример работы позволяет заменить логику компонента, что очень полезно при тестировании. Например, если есть какой-то компонент, который должен использовать внешний API для получения данных, то с помощью Mockito мы можем сделать заглушку без обращения к внешнему API. Ещё более важным может быть изменение возвращаемых значений, которое можно задавать сразу в логике модульного теста.

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

Чуть-чуть отойдём от темы и представим себе волшебника, который взмахом палочки по воздуху переместил яблоко с одного стола на другой. Согласитесь, результат для нас вполне очевиден. Адам может и сам перенести райское яблоко с одного стола на другой. Тем не менее благодаря самому процессу как яблоко пролетело по воздуху именно это делает его магией.

Так и здесь. Результат для нас может вполне очевиден, но как же он реализован?

Присмотримся к коду ещё раз и акцентируем внимание на второй строке:

when(human.getName()).thenReturn("Red");

Внутри метода when по сути мы помещаем возвращаемое значение из метода getName(), а потом говорим thenReturn. Но как так получается? Как when может изменить наш метод getName, просто получив то значение, которое он возвращает?

Более того, мы знаем что поле name не инициализировано, а значит, там будет null.

За это уже можно влюбиться в неё и начать вовсю использовать.

По моему личному мнению, Mockito полезная вещь, которую стоит изучить при наличии свободного времени. Но если изучить досконально не получится тоже не страшно, то, что вы будете иметь о ней представление, уже хорошо. Тем более лучшие практики подтверждают, что если ваш код трудно тестировать, то с вашим кодом явно что-то не так. В пользу ознакомления, а не глубокого изучения, говорит и то, что в 2018 году появился такой инструмент, как TestContainers, который умеет поднимать реальную базу в Docker и реально выполнять запросы в БД/Kafka/RabbitMQ.

Егор Воронянский, Java Middle Developer в BPC Banking Technologies.
Ментор раздела backend на курсе SkillFactory Java-разработка

Учимся показывать фокусы


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

Редко хороший фокус удаётся без предварительной подготовки. Так, например, фокусник может привязать прозрачную леску к яблоку.

Нашим же приготовлением был вызов метода mock:

Apple apple = mock(Apple.class);

Отсюда мы понимаем, что наш apple это уже необычное яблоко.

И действительно, если вы попробуете передать обычный экземпляр класса в метод when, то получите ошибку.

Попробуем узнать, кем оно теперь является:

@Testpublic void basic2() {   Apple apple = mock(Apple.class);   System.out.println(apple.getClass().getCanonicalName());   // org.own.ArticleExample1$Apple$MockitoMock$692964397   System.out.println(apple.getClass().getSuperclass().getCanonicalName());   // org.own.ArticleExample1.Apple   assertNotEquals(apple.getClass(), Apple.class); // true}

Итак, с кем же мы имеем дело? Кто же этот самозванец, который выдаёт себя за наше яблоко?

Обычно такими делами занимается паттерн Proxy. Суть его в том, чтобы подсунуть нам не конкретно наш экземпляр, который мы хотим получить (в нашем случае Apple), а его наследника, который может иметь какие-либо необходимые модификации.

Что касается именно нашей библиотеки Mockito, то она действительно основана на проксировании. Тем не менее есть библиотеки, занимающиеся тем же, но основанные не на проксировании, а, например, на изменении байт-кода. Примером такой библиотеки может служить PowerMock с лицензией Apache-2.0 License.

Ну, и разница между библиотекой, работающей с Java API, и той, которая манипулирует байт-кодом, наверное, очевидна. Но зачастую подключение PowerMock избыточно, хотя случаев его использования довольно много.

Далее мы разберём, в чём же минусы решения через проксирование.

Proxy


На прокси, с одной стороны, можно смотреть как на заменителя экземпляра какого-то типа, а с другой как на смотрящий или проверяющий за происходящими вызовами метод.

Практическое его использование сводится к тому, чтобы создать экземпляр класса, соответствующий типу целевого объекта, и добавить к вызову метода операции до или после, а иногда и вовсе заменить исходный метод.

Индейская пословица гласит:

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

Так вот, легче будет понять через практику с реальным кодом:

ProxyExample

import java.lang.reflect.Proxy;/** * @author Arthur Kupriyanov */public class ProxyExample {interface IApple {String getColor();}private static class Apple implements IApple {private String color = "red";public String getColor() {return color;}}public static void main(String[] args) {Object proxyInstance = Proxy.newProxyInstance(ProxyExample.class.getClassLoader(),Apple.class.getInterfaces(), (proxy, method, args1) -> {System.out.println("Called getColor() method on Apple");return method.invoke(new Apple(), args1);});IApple appleProxy = (IApple) proxyInstance;System.out.println(appleProxy.getColor());}}

На выводе мы получим:

Called getColor() method on Applered

Попробуйте, например, вместо вызова method.invoke сделать return Green.

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

Теперь из-за принципов работы Proxy мы сразу можем понять, какие ограничения на него наложены:

  • Мы не можем перехватывать вызовы статических, приватных и ненаследуемых (final) методов.
  • Сделать прокси из ненаследуемого класса (final).

Показываем фокус


На самом деле, имея лишь этот арсенал, можно сделать что-то наподобие Mockito.

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

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

  1. Создадим прокси типа с нашим InvocationHandler с необходимой нам логикой.
  2. Создадим метод when, который вместе с thenReturn запомнит вызов метода, его аргументы и значение, которое нужно вернуть.
  3. При вызове метода из нашего прокси объекта будем проверять сохранённые значения из пункта 2. Если есть сохранение заданного метода с такими же аргументами, то вернём сохранённое значение. Если нет, то вернем null.

Исходный код можно найти в репозитории или же поиграть в онлайн-редакторе.

private static MockInvocationHandler lastMockInvocationHandler;@SuppressWarnings("unchecked")public static <T> T mock(Class<T> clazz) {   MockInvocationHandler invocationHandler = new MockInvocationHandler();   T proxy = (T) Proxy.newProxyInstance(Bourbon.class.getClassLoader(), new Class[]{clazz}, invocationHandler);   return proxy;}public static <T> When<T> when(T obj) {   return new When<>();}public static class When<T> {   public void thenReturn(T retObj) {   lastMockInvocationHandler.setRetObj(retObj);   }}private static class MockInvocationHandler implements InvocationHandler {   private Method lastMethod;   private Object[] lastArgs;   private final List<StoredData> storedData = new ArrayList<>();   private Optional<Object> searchInStoredData(Method method, Object[] args) {   for (StoredData storedData : this.storedData) {   if (storedData.getMethod().equals(method) && Arrays.deepEquals(storedData.getArgs(), args)) {   // если данные есть, то возвращаем сохраненный   return Optional.ofNullable(storedData.getRetObj());   }   }   return Optional.empty();   }   @Override   public Object invoke(Object proxy, Method method, Object[] args) {   lastMockInvocationHandler = this;   lastMethod = method;   lastArgs = args;   // проверяем в сохраненных данных   return searchInStoredData(method, args).orElse(null);   }   public void setRetObj(Object retObj) {   storedData.add(new StoredData(lastMethod, lastArgs, retObj));   }   private static class StoredData {   private final Object[] args;   private final Method method;   private final Object retObj;   private StoredData(Method method, Object[] args, Object retObj) {   this.args = args;   this.method = method;   this.retObj = retObj;   }   private Object[] getArgs() {   return args;   }   private Method getMethod() {   return method;   }   private Object getRetObj() {   return retObj;   }   }}

Этот код не претендует на какое-либо качество кода, но он вполне нагляден.

Основным классом здесь является MockInvocationHandler, в который мы вставляем всю нашу логику с поиском сохранённых значений. Все сохранённые значения мы храним в виде списка StoredData, а затем при вызове любого из методов запроксированного объекта проверяем, было ли сохранено какое-либо значение.

Те сомнения, которые не разрешает теория, разрешит тебе практика. Людвиг Файербах


Поэтому смело открываем IDE, копируем код (думаю, в этом мы все профи), практикуемся и смотрим каждую строчку кода. Более ленивые могут открыть онлайн-редактор (ссылка также была наверху перед кодом) и редактировать уже там.

Заключение


Mockito имеет не только конструкцию when-thenReturn, но и ещё много других не менее интересных и не уступающих по красоте конструкций. Разработчики Mockito смогли не только найти весьма любопытный способ создавать заглушки, но и выбрали правильные имена и способ подачи разработчикам. Согласитесь, что та же конструкция, которую мы рассмотрели ранее, выглядит, как единая строчка текста.

Простота библиотеки в использовании и является ключевым фактором фокуса. Это выглядит так просто и очевидно при использовании, что кажется магией, хотя за кадром остаются тяжёлая подготовка (создание Proxy) и исполнение (поиск сохраненных значений).

Для ознакомления с методами использования библиотеки уже есть довольно много других статей на разных языках, в том числе на русском. Поэтому вам осталось самое интересное: изучить внутренности самого Mockito, (хорошо, что исходники есть в репозитории на GitHub) и понять, как он хорошо интегрируется в Spring Boot для тестирования. А я пожелаю вам удачи в этом пути!



image



Подробнее..

Настройка GitLab CI CD для Java приложения

19.02.2021 14:12:20 | Автор: admin

Из-за прекращения поддержи Bitbucket Setver пришлось переехать на GitLab.


В Bitbucket Server не было встроенного CI/CD, поэтому использовали Teamcity. Из-за проблемы интеграции Teamcity с GitLab, мы попробовали GitLab Pipline. И остались довольны.


Disclamer: У меня не так много опыта в CI/CD, так что статья скорее для новичков. Буду рад услышать конструктивную критику с предложениями по оптимизации скрипта сборки :)


Коротко о Gitlab Pipline


Если говорить простыми словами: сборка делится на задачи. Какие-то задачи выполняются последовательно и передают результаты следующим задачам, какие-то задачи распаралеливаются: например можно одновременно деплоить на сервер и в nexus.


Раннеры и задачи


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


Раннеры бывают разных типов. Мы рассмотрим executor docker. Для каждой задачи создается новый чистый контейнер. Но между контейнерами можно передавать промежуточные результаты это называется кэширование.


Кэширование и его особенности


Механизм кэширования разрабатывал какой-то одаренный человек. Поэтому сразу разобраться, как оно работает, будет не просто. В отдельной статье можно прочитать о кэшировании подробнее.


Каждый раннер хранит кэш в папке /cache. Для каждого проекта в этой папке создается еще папка. Сам кэш хранится в виде zip архива.


Из-за наличия у каждого раннера своей папки для кэша, возникает проблема. Если один раннер кэшировал папку в первой задаче, а второй раннер взялся за выполнение второй задачи, то у него не окажется кэша из первой задачи. Чуть далее рассмотрим как это исправить.


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


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


Так же стоит знать, что кэш не удаляется после окончания сборки. При следующей такой же сборке старый кэш будет доступен.


Эти особенности усложняют создание инструкций для CI CD.


Артефакты


Помимо кэша между сборками можно передавать артефакты.


Артефакт это файлы, которые считаются законченным продуктом сборки. Например .jar файлы приложения.


В отличие от кэша, артефакт передается между раннерами. Из-за этого многие злоупотребляют использованием артефактов там, где стоит использовать кэш.


Следуйте следующим правилам:


  1. Если текущее задание может выполняться самостоятельно, но в присутствии контента работа будет идти быстрее, используйте кэш.
  2. Если текущее задание зависит от результатов предыдущего, то есть не может выполняться само по себе, используйте артефакты и зависимости.

Установка Gitlab Runner


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


mkdir ~/runner_name

Само создание ранера выполняется в одну команду. Можно создать сколько угодно ранеров.


docker run -d --name gitlab-runner-name \  --restart always \  -v /var/run/docker.sock:/var/run/docker.sock \  -v /home/user/runner_name:/etc/gitlab-runner:z \  gitlab/gitlab-runner:latest

Мало создать раннер, теперь его нужно зарегистрировать в GitLab. Зарегистрировать можно на уровне всего GitLab, тогда сборки будут выполняться для любого проекта; на уровне группы выполнятся только для группы, и на уровне проекта.


Заходим в контейнер.


sudo docker exec -ti gitlab-runner-name bash

Внутри контейнера выполним команду регистрации. Регистрация происходит в интерактивном режиме.


gitlab-runner register

Отвечаем на вопросы:


Runtime platform                                    arch=amd64 os=linux pid=27 revision=888ff53t version=13.8.0Running in system-mode.                            Enter the GitLab instance URL (for example, https://gitlab.com/):http://git.company.name/Enter the registration token:vuQ6bcjuEPqc8dVRRhgYEnter a description for the runner:[c6558hyonbri]: runner_twoEnter tags for the runner (comma-separated):Registering runner... succeeded                     runner=YJt3v3QgEnter an executor: parallels, shell, virtualbox, docker+machine, kubernetes, custom, docker, docker-ssh+machine, docker-ssh, ssh:dockerEnter the default Docker image (for example, ruby:2.6):maven:3.3.9-jdk-8Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded! 

Тут все просто:


  1. Адрес вашего gitlab.
  2. Токен авторизации. Посмотреть его можно в настройках гурппы/проекта в разделе CI/CD Runners.
  3. Название раннера.
  4. Теги ранера, можно пропустить нажав Enter.
  5. Исполнитель сборки. Вводим docker.
  6. Образ, который будет использоваться по умолчанию, если не установлен другой.

После этого в настройках проекта можно посмотреть доступные раннеры.


Добавленный ранер GitLab


После регистрации, в папке /home/user/runner_name появится файл с настройками конфигурации config.toml. Нам нужно добавить docker volume для кэширования промежуточных результатов.


volumes = ["gitlab-runner-builds:/builds", "gitlab-runner-cache:/cache"]

Проблема кэширования.
В начале статьи я рассказал о проблеме кеширования. Ее можно решить с помощью монтирования одного volume к разным раннерам. То есть во втором своем раннере так же укажите volumes = ["gitlab-runner-cache:/cache"]. Таким образом разные раннеры будут иметь единый кэш.


В итоге файл конфигурации выглядит так:


concurrent = 1check_interval = 0[session_server]  session_timeout = 1800[[runners]]  name = "runner_name"  url = "gitlab_url"  token = "token_value"  executor = "docker"  [runners.custom_build_dir]  [runners.cache]    [runners.cache.s3]    [runners.cache.gcs]    [runners.cache.azure]  [runners.docker]    tls_verify = false    image = "maven:3.3.9-jdk-8"    privileged = false    disable_entrypoint_overwrite = false    oom_kill_disable = false    disable_cache = false    volumes = ["gitlab-runner-builds:/builds", "gitlab-runner-cache:/cache"]    shm_size = 0

После изменения перезапускаем раннер.


docker restart gitlab-runner-name

Что хотим получить от CI CD?


У нас на проекте было 3 контура:


  • dev-сервер, на него все попадает сразу после MR;
  • пре-прод-сервер, на него все попадает перед попаданием на прод, там проходит полное регресс тестирование;
  • прод-сервер, собственно сама прод среда.

Что нам было необходимо от нашего CI/CD:


  • Запуск unit-тестов для всех MergeRequest
  • При мерже в dev ветку повторный запуск тестов и автоматический деплой на dev-сервер.
  • Автоматическая сборка, тестирвоание и деплой веток формата release/* на пре-прод-сервер.
  • При мерже в master ничего не происходит. Релиз собирается при обнаружении тега формата release-*. Одновременно с деплоем на прод-сервер будет происходить загрузка в корпоративный nexus.
  • Бонусом настроим уведомления о статусе деплоя в Telegram.

Настройка GitLab CI для Maven


Что делать если у вас Gradle? Загляните в оригинал статьи, там я рассказываю про настройку и для Gradle. Она не сильно отличается.


Создайте в корне проекта файл .gitlab-ci.yml.


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


Вы можете указать нужный образ, вместо дефолтного образа у раннера.


image: maven:latest

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


// ... ... ... ... ...variables:  MAVEN_OPTS: "-Dmaven.repo.local=./.m2/repository"// ... ... ... ... ...

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


// ... ... ... ... ...stages:  - build  - test  - package  - deploy  - notify// ... ... ... ... ...

  • build стадия сборки.
  • test стадия тестирования.
  • package стадия упаковки в jar.
  • deploy стадия деплоя на сервер.
  • notify стадия уведомления о провале.

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


Сборка Build


// ... ... ... ... ...build:  stage: build  only:    - dev    - merge_requests    - /^release\/.*$/  except:    - tags  script:    - 'mvn --settings $MAVEN_SETTINGS compile'  cache:    paths:      - ./target      - ./.m2// ... ... ... ... ...

Раздел script выполняет linux команды.


Переменная GitLab CI/CD $MAVEN_SETTINGS необходима для передачи файла settings.xml, если вы используете нестандартные настройки, например корпоративные репозитории. Переменная создается в настройках CI/CD для группы/проекта. Тип переменной File.


Раздел only указывает для каких веток и тегов выполнять задачу. Чтобы не собирать каждую запушенную ветку устанавливаем: dev, merge_requests и ветки формата /release/*.


Раздел only не разделяет ветка это или тег. Поэтому мы указываем параметр except, который исключает теги. Из-за этого поведения за сборку на прод отвечают отдельные задачи. В противном случае, если бы кто-то создал тег формата release/*, то он бы запустил сборку.


Для защиты от случайного деплоя в прод джуном, рекомендую установить защиту на ветки dev, master, /release/*, а так же на теги release-*. Делается это в настройках проекта GitLab.


Раздел cache отвечает за кэширование. Чтобы каждый раз не выкачивать зависимости добавляем в кэш папку ./target и ./.m2.


Запуск unit тестов test


Создаем задачу для запука тестирования.


// ... ... ... ... ...test:  stage: test  only:    - dev    - merge_requests    - /^release\/.*$/  except:    - tags  script:    - 'mvn --settings $MAVEN_SETTINGS test'  cache:    paths:      - ./target      - ./.m2// ... ... ... ... ...

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


Упаковка package


Следом добавляем задачу упаковки с выключенными тестами. Она уже выполняется только для веток dev и release/*. Упаковывать Merge Request смысла нет.


// ... ... ... ... ...package:  stage: package  only:    - dev    - /^release\/.*$/  except:    - tags  script:    - 'mvn --settings $MAVEN_SETTINGS package -Dmaven.test.skip=true'  artifacts:    paths:      - target/*.jar  cache:    policy: pull    paths:      - ./target      - ./.m2// ... ... ... ... ...

Обратите внимание на policy: pull и artifacts. В следующих задачах не нужны исходники и зависимости, так что policy: pull отключает кэширование. Для сохранения результатов сборки используем artifacts, который сохраняет .jar файлы и передает их следующим задачам.


Деплой deploy


Теперь осталось задеплоить артефакт на dev-сервер с помощью ssh и scp.


// ... ... ... ... ...deploy_dev_server:  stage: deploy  only:    - dev  except:    - tags  before_script:    - which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )    - eval $(ssh-agent -s)    - echo "$SSH_PRIVATE_KEY" | ssh-add -    - mkdir -p ~/.ssh    - chmod 700 ~/.ssh    - ssh-keyscan $DEV_HOST >> ~/.ssh/known_hosts    - chmod 644 ~/.ssh/known_hosts  script:    - ssh $DEV_USER@$DEV_HOST "[ ! -f $DEV_APP_PATH/app_name.jar ] || mv $DEV_APP_PATH/app_name.jar $DEV_APP_PATH/app_name-build-$CI_PIPELINE_ID.jar"    - scp target/app_name.jar $DEV_USER@$DEV_HOST:$DEV_APP_PATH/    - ssh $DEV_USER@$DEV_HOST "sudo systemctl stop app_name_service && sudo systemctl start app_name_service"    - sh ci-notify.sh // ... ... ... ... ...

Не забудьте создать переменные в GitLab CI CD:


  • $DEV_USER пользователь системы, от чьего имени будет происходить деплой.
  • $DEV_HOST ip адрес сервера.
  • $DEV_APP_PATH путь до папки приложения.
  • $SSH_PRIVATE_KEY приватный ключ.

Раздел before_script отвечает за выполнение настроек перед основным скриптом. Мы проверяем наличие ssh-agent, устанавливаем его при отсутствии. После чего добавляем приватный ключ, устанавливаем правильные права на папки.


В разделе script происходит деплой на сервер:


  1. Проверяем наличие старого jar и переименовываем его. $CI_PIPELINE_ID это глобальный номер сборки Pipeline.
  2. Копируем новый jar на сервер.
  3. Останавливаем и запускаем службу, отвечающую за приложение.
  4. Отправляем уведомление об успехе в телеграм. Об этом ниже.

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


На пре-прод делаем по аналогии, только меняем переменные на $PRE_PROD_*.


// ... ... ... ... ...deploy_pre_prod:  stage: deploy  only:    - /^release\/.*$/  except:    - tags  before_script:    - which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )    - eval $(ssh-agent -s)    - echo "$SSH_PRIVATE_KEY" | ssh-add -    - mkdir -p ~/.ssh    - chmod 700 ~/.ssh    - ssh-keyscan $PRE_PROD_HOST >> ~/.ssh/known_hosts    - chmod 644 ~/.ssh/known_hosts  script:    - ssh $PRE_PROD_USER@$PRE_PROD_HOST "[ ! -f $PRE_PROD_APP_PATH/app_name.jar ] || mv $PRE_PROD_APP_PATH/app_name.jar $PRE_PROD_APP_PATH/app_name-build-$CI_PIPELINE_ID.jar"    - scp target/app_name.jar $DEV_USER@$PRE_PROD_HOST:$PRE_PROD_APP_PATH/    - ssh $PRE_PROD_USER@$PRE_PROD_HOST "sudo systemctl stop app_name_service && sudo systemctl start app_name_service"    - sh ci-notify.sh // ... ... ... ... ...

Настройка деплоя на прод


Для прод-деплоя можно объединить сборку, тестирование и упаковку в одну задачу.


// ... ... ... ... ...package_prod:  stage: package  only:    - /^release-.*$/  except:    - branches  script:    - 'mvn --settings $MAVEN_SETTINGS package'  artifacts:    paths:      - target/*.jar// ... ... ... ... ...

Мы защищаемся от срабатывания на ветки формата release-*, нам нужно срабатывание только по тегу.


Деплой аналогичен пре-проду, изменяется только only и переменные.


Дополнительно появляется задача с отправкой артефакта в корпоративный nexus. Деплой на сервер и в нексус работает параллельно.


// ... ... ... ... ...deploy_prod:  stage: deploy  only:    - /^release-.*$/  except:    - branches  ...deploy_nexus_server:  stage: deploy  only:    - /^release-.*$/  except:    - branches  script:    - 'mvn --settings $MAVEN_SETTINGS deploy -Dmaven.test.skip=true'// ... ... ... ... ...

Итоговый .gitlab-ci.yml:


image: maven:latestvariables:  MAVEN_OPTS: "-Dmaven.repo.local=./.m2/repository"stages:  - build  - test  - package  - deploy  - notifybuild:  stage: build  only:    - dev    - merge_requests    - /^release\/.*$/  except:    - tags  script:    - 'mvn --settings $MAVEN_SETTINGS compile'  cache:    paths:      - ./target      - ./.m2test:  stage: test  only:    - dev    - merge_requests    - /^release\/.*$/  except:    - tags  script:    - 'mvn --settings $MAVEN_SETTINGS test'  cache:    paths:      - ./target      - ./.m2package:  stage: package  only:    - dev    - /^release\/.*$/  except:    - tags  script:    - 'mvn --settings $MAVEN_SETTINGS package -Dmaven.test.skip=true'  artifacts:    paths:      - target/*.jar  cache:    policy: pull    paths:      - ./target      - ./.m2deploy_dev_server:  stage: deploy  only:    - dev  except:    - tags  before_script:    - which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )    - eval $(ssh-agent -s)    - echo "$SSH_PRIVATE_KEY" | ssh-add -    - mkdir -p ~/.ssh    - chmod 700 ~/.ssh    - ssh-keyscan $DEV_HOST >> ~/.ssh/known_hosts    - chmod 644 ~/.ssh/known_hosts  script:    - ssh $DEV_USER@$DEV_HOST "[ ! -f $DEV_APP_PATH/app_name.jar ] || mv $DEV_APP_PATH/app_name.jar $DEV_APP_PATH/app_name-build-$CI_PIPELINE_ID.jar"    - scp target/app_name.jar $DEV_USER@$DEV_HOST:$DEV_APP_PATH/    - ssh $DEV_USER@$DEV_HOST "sudo systemctl stop app_name_service && sudo systemctl start app_name_service"deploy_pre_prod:  stage: deploy  only:    - /^release\/.*$/  except:    - tags  before_script:    - which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )    - eval $(ssh-agent -s)    - echo "$SSH_PRIVATE_KEY" | ssh-add -    - mkdir -p ~/.ssh    - chmod 700 ~/.ssh    - ssh-keyscan $PRE_PROD_HOST >> ~/.ssh/known_hosts    - chmod 644 ~/.ssh/known_hosts  script:    - ssh $PRE_PROD_USER@$PRE_PROD_HOST "[ ! -f $PRE_PROD_APP_PATH/app_name.jar ] || mv $PRE_PROD_APP_PATH/app_name.jar $PRE_PROD_APP_PATH/app_name-build-$CI_PIPELINE_ID.jar"    - scp target/app_name.jar $DEV_USER@$DEV_HOST:$DEV_APP_PATH/    - ssh $PRE_PROD_USER@$PRE_PROD_HOST "sudo systemctl stop app_name_service && sudo systemctl start app_name_service"package_prod:  stage: package  only:    - /^release-.*$/  except:    - branches  script:    - 'mvn --settings $MAVEN_SETTINGS package'  artifacts:    paths:      - target/*.jardeploy_prod:  stage: deploy  only:    - /^release-.*$/  except:    - branches  before_script:    - which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )    - eval $(ssh-agent -s)    - echo "$SSH_PRIVATE_KEY" | ssh-add -    - mkdir -p ~/.ssh    - chmod 700 ~/.ssh    - ssh-keyscan $PROD_HOST >> ~/.ssh/known_hosts    - chmod 644 ~/.ssh/known_hosts  script:    - ssh $PROD_USER@$PROD_HOST "[ ! -f $PROD_APP_PATH/app_name.jar ] || mv $PROD_APP_PATH/app_name.jar $PROD_APP_PATH/app_name-build-$CI_PIPELINE_ID.jar"    - scp target/app_name.jar $PROD_USER@$PROD_HOST:$PROD_APP_PATH/    - ssh $PROD_USER@$PROD_HOST "sudo systemctl stop app_name_service && sudo systemctl start app_name_service"

Бонус: уведомления о деплое в Telegram


Полезная фишка для уведомления менеджеров. После сборки в телеграм отправляется статус сборки, название проекта и ветка сборки.


В задачах деплоя последней командой пропишите:


// ... ... ... ... ...script:  - ...  - sh ci-notify.sh // ... ... ... ... ...

Сам файл необходимо добавить в корень проекта, рядом с файлом .gitlab-ci.yml.


Содержимое файла:


#!/bin/bashTIME="10"URL="http://personeltest.ru/aways/api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage"TEXT="Deploy status: $1%0A-- -- -- -- --%0ABranch:+$CI_COMMIT_REF_SLUG%0AProject:+$CI_PROJECT_TITLE"curl -s --max-time $TIME -d "chat_id=$TELEGRAM_CHAT_ID&disable_web_page_preview=1&text=$TEXT" $URL >/dev/null

Скрипт отправляет запрос к API Telegram, через curl. Параметром скрипта передается emoji статуса билда.


Не забудьте добавить новые параметры в CI/CD:


  • $TELEGRAM_BOT_TOKEN токен бота в телеграмм. Получить его можно при создании своего бота.
  • $TELEGRAM_CHAT_ID идентификатор чата или беседы, в которую отправляется сообщение. Узнать идентификатор можно с помощью специального бота.

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


// ... ... ... ... ...notify_error:  stage: notify  only:    - dev    - /^release\/.*$/  script:    - sh ci-notify.sh   when: on_failurenotify_error_release:  stage: notify  only:    - /^release-.*$/  except:    - branches  script:    - sh ci-notify.sh   when: on_failure// ... ... ... ... ...

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


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

Подробнее..
Категории: Gitlab , Devops , Java , Gitlab-ci , Maven , Nexus , Gitlab-runner

Начало работы с нейронными сетями

15.02.2021 02:12:27 | Автор: admin

В этой главе мы познакомимся с нейронными сетями и узнаем для чего они были спроектированы. Эта глава служит фундаментом для последующих глав, в то время как эта показывает базовые понятия нейронных сетей. В этой главе мы покроем следующие темы:

  • Искусственные нейроны

  • Весы(weights) и смещения(biases)

  • Активационные функции(activation functions)

  • Слои нейронов(layers)

  • Реализация нейронной сети на Java

Раскрывая нейронные сети

Во-первых, термин нейронные сети может создать снимок мозга в вашем сознании, в частности для тех, кто ранее познакомился с ним. В действительности это правда, мы считаем мозг большая и естественная нейронная сеть. Однако что мы можем сказать об искусственных нейронных сетях (ANN artificial neural network)? Хорошо, он начинается с антонима естественный и первая мысль, которая приходит в нашу голову это картинка искусственного мозга или робота учитывает термин искусственный. В этом случае, мы так же имеем дело с созданием структуры, похожей и вдохновленной человеческим мозгом; поэтому это названо искусственным интеллектом. Поэтому читатель, который не имел прошлого опыта с ANN, сейчас может думать, что книга учит, как строить интеллектуальные системы, включая искусственный мозг, способный эмулировать человеческое сознание, используя Java программы, не так ли? Конечно мы не будем покрывать создание искусственного мышления машин как в трилогии Матрицы; однако эта книга растолкует несколько неимоверных способностей и что могут эти структуры. Мы предоставим читателю Java исходники с определением и созданием основных нейросетевых структур, воспользоваться всеми преимуществами языка программирования Java.

Почему искусственные нейронные сети?

Мы не можем начать говорить про нейросети без понимания их происхождения, включая также термин. Мы используем термины нейронные сети (NN) и ANN взаимозаменяемо в этой книге, хотя NN более общий, покрывая также
естественные нейронные сети. Таким образом, что же такое на самом деле ANN? Давайте изучим немного историю этого термина.

В 1940-ых нейрофизиолог Warren McCulloch и математик Walter Pits спроектировали первую математическую реализацию искусственного нейрона, комбинируя нейронаучный фундамент с математическими операциями. В то время многие исследования осуществлялись на понимании человеческого мозга и как и если бы мог смоделирован, но в пределах области неврологии. Идея McCulloch и Pits была реально уникальна, потому что добавлен математический компонент. Далее, считая, что мозг состоит из миллиардов нейронов, каждый из них взаимосвязан с другими миллионами, в результате чего в некоторых триллионах соединениях, мы говорим о гигантской структуре сети. Однако, каждый нейрон очень простой, действуя как простой процессор, способный суммировать и распространять сигналы.

На базе этого факта, McCulloch и Pits спроектировали простую модель для одного нейрона, первоначально симулируя человеческое зрение. Доступные калькуляторы или компьютеры в то время были очень редкими, но способные иметь дело с математическими операциями достаточно хорошо; с другой стороны, даже современные задачи, такие как компьютерное зрение и распознавание звуков не очень легко программируются без специальных фреймворков, основанных на математических операциях и функциях. Тем не менее, человеческий мозг может выполнять эти последние задачи эффективнее чем первые, и этот факт реально побуждает ученых исследователей.

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

Задачи, быстро решаемые человеком

Задачи, быстро решаемые компьютером

Классификация изображений Распознавание голоса идентификация лиц Прогнозирование событий на основе предыдущего опыта

Комплексные вычисления Исправление грамматических ошибок Обработка сигналов Управление операционной системой

Как устроены нейронные сети

Можно сказать, что ANN это естественная структура, таким образом она имеет схожести с человеческим мозгом. Как показано на следующей картинке, естественный нейрон состоит из ядра, дендритов и аксона. Аксон продолжается в несколько ветвей, формируя синапсы с другими дендритами нейронов.

Таким образом, искусственный нейрон имеет похожую структуру. Он состоит из ядра(единицы обработки), несколько дендритов(аналогично входам), и одного аксона(аналогично выходу), как показано на следующей картинке:

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

Самый базовый элемент искусственный нейрон

Доказано, что естественные нейроны обработчики сигналов поскольку они получают микросигналы в дендритах, что вызывает сигнал в аксонах в зависимости от их силы или величины. Мы можем поэтому подумать, что нейрон как имеющий сборщик сигналов во входах(inputs) и активационную единицу в выходе(output), что вызывает сигнал, который будет передаваться другим нейронам. Таким образом, мы можем определить искусственную нейронную структуру, как показано на следующем рисунке:

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

Давая жизнь нейронам активационная функция

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

Четыре самых используемых активационных функций:

  • Сигмоида (Sygmoid)

  • Гиперболический тангенс(Hyberbolic tangent)

  • Жесткая пороговая функция(Hard limiting threshold)

  • Линейная(linear)

Уравнения и графики ассоциирующиеся с этими функциями, показаны
в следующей таблице:

Фундаментальные величины весы(weights)

В нейронных сетях, синапсы представляют собой соединения между нейронами и имеют возможность усиливать или смягчать нейронные сигналы, например, перемножать сигналы, таким образом улучшать их. Итак, путем модификации нейронных сетей, нейронные весы(weights) могут повлиять на нейронный вывод(output), следовательно нейронная активация может быть зависима от ввода и от весов. При условии, что inputs идут от других нейронов или от внешнего мира, весы(weights) считаются установленными нейронными соединениями между нейронами. Таким образом, с тех пор как весы являются внутренними для нейронных сетей, мы можем считать их как знания нейронных сетей, предоставленные изменения весов будут изменять возможности нейронных сетей и поэтому действия.

Важный параметр смещение

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

Части образующие целое слои

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

Нейронные сети могут быть составлены из нескольких соединенных слоев, которые называются многослойными сетями. Обычные нейронные сети могут быть разделены на 3 класса:
1. Input layer;
2. Hidden layer;
3. Output layer;
На практике, дополнительный нейронный слой добавляет другой уровень
абстракции внешней стимуляции, тем самым повышая способность
нейронных сетей представлять больше комплексных данных.

Каждая нейросеть имеет как минимум входной/выходной слой независимо от количества слоев. В случае с многослойной сетью, слои между входом и выходом названы скрытыми.

Изучение архитектуры нейронных сетей

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

1. Нейронные соединения:
1.1 Однослойные(monolayer) сети;
1.2 Многослойные(multilayer) сети;
2. Поток сигналов:
2.1 Сети прямой связи(Feedforward networks);
2.2 Сети обратной связи(Feedback networks);

Однослойные сети

Нейронная сеть получает на вход сигналы и кормит их в нейроны, которые в очереди продуцируют выходные сигналы. Нейроны могут быть соединены с другими с или без использования рекуррентности. Примеры таких архитектур: однослойный персептрон, Adaline(адаптивный линейный нейрон), самоорганизованная карта, нейронная сеть Элмана(Elman) и Хопфилда.

Многослойные сети

В этой категории нейроны делятся во много слоев, каждый слой соответствует параллельному расположению нейронов, которые делят одни и те же входные данные, как показано на рисунке:

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

Сети прямой связи(feedforward networks)

Поток сигналов в нейронных сетях может быть только в одном направлении или рекуррентности. В первом случае мы называем архитектуру нейронных сетей feedforward, начиная с входных сигналов кормили во входной слой; затем, после обработки, они отправляются в следующий слой, как показано на ричунке про многослойную секцию. Многослойные персептроны и радиальные базисные функции хорошие примеры feedforward сети.

Сети обратной связи(Feedback networks)

Когда нейронная сеть имеет некоторый вид внутреннего рецидива, это значит, что сигналы вернулись обратно в нейрон или слой, который уже получил и обработал сигнал, сеть это тип feedback-а. Посмотрите на картинку:

Специальная причина добавить рекуррентность в сеть это выработка динамического поведения, в частности когда сеть адресует проблемы, включая временные ряды или распознавание образов, которые требуют внутреннюю память для подкрепления обучающего процесса. Тем не менее, такие сети особенно трудны в тренировке, в конечном счете не в состоянии учиться. Многие feedback сети однослойные, такие как сети Элмана(Elman) и Хопфилда(Hopfield), но возможно и построить рекуррентную многослойную сеть, такие как эхо и рекуррентные многослойные персептронные сети.

От незнания к знаниям процесс обучения

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

Процесс, показанный на предыдущей схеме, называется контролируемое обучение(supervised learning), потому что это желаемый вывод, но нейронные сети могут обучаться только входных данных, без желаемого результата(контролируемое обучение). Во второй главе, Как обучаются нейронные сети, мы собираемся глубже погрузиться в процесс обучения нейронных сетей.

Давайте начнем реализацию! Нейронные сети на практике

В этой книге мы покроем все процессы реализации нейронных сетей на Java. Java это объектно-ориентированный язык программирования, созданный в 1990-ые маленькой группой инженеров из Sun Microsystems, позже приобретенной компанией Oracle в 2010-ых. Сегодня, Java представлена во многих устройствах, которые участвуют в нашей повседневной жизни. В объектно-ориентированном языке, таком как Java, мы имеем дело склассами и объектами. Класс план чего-то в реальной жизни, а объект образец такого плана, например, car(класс, ссылающийся на все машины) и my car(объект, ссылающийся на конкретную машину мою). Java классы обычно состоят из атрибутов и методов(или функций), которые включают принципы объектно-ориентированного программирования(ООП). Мы собираемся кратко рассмотреть эти принципы без углубления в них, поскольку цель этой книги просто спроектировать и создать нейронные сети с практической точки зрения. В этом процессе четыре принципа уместны и нуждаются в рассмотрении:

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

  • Инкапсуляция: Аналогично инкапсуляции продукта, при которой некоторые соответствующие функции раскрыты открыто (публичные(public) методы), в то время как другие хранится скрытым в пределах своего домена (частного(private) или защищенного(protected)), избегая неправильное использование или избыток информации.

  • Наследование: В реальной мире, много классов этих объектов представляют собой атрибуты и методы в иерархической манере; например, велосипед может быть супер-классом для машин и грузовиков.Таким образом, в ООП эта концепция позволяет из одного класса перенимать все свойства в другой класс, тем самым избегая переписывания кода.

  • Полиморфизм: Во многом схожа с наследованием, но с изменениями в методах со схожими сигнатурами, представляющие разные поведения в разных классах.

Используя концепции нейронных сетей, представленные в этой главе и коцепции ООП, мы сейчас собираемся проектировать самый первый класс, реализующий нейронную сеть. Как можно увидеть, нейронная сеть состоит из слоев, нейронов, весов, активационных функций и смещений, и трех типов слоев: входные, скрытые и выходные. Каждый слой может иметь один или несколько нейронов. Каждый нейрон соединен друг с другом входом/выходом или другими нейронами, и эти соединения называются весами.

Важно выделить, что нейронная сеть может иметь много скрытых слоев или вообще их не иметь, количество нейронов в слое может различаться. Тем не менее, входные и выходные слои имеют одинаковое кол-во нейронов, как количество нейронных входов/выходов соответственно. Так начнем же реализацию. Сначала, мы собираемся определить 6 классов, Детально показанные тут:

Имя класса: Neuron

Атрибуты

private ArrayList listOfWeightIn

Переменная ArrayList дробных чисел представляет список входных весов

private ArrayList listOfWeightOut

Переменная ArrayList дробных чисел представляет список выходных весов

Методы

public double initNeuron()

Инициализирует функции listOfWeightIn, listOfWeightOut с псевдослучайными числами

Параметры: нет

Возвращает: Псевдослучайное число

public ArrayList getListOfWeightIn()

Геттер ListOfWeightIn

Параметры: нет

Возвращает: список дробных чисел, сохраненной в переменной ListOfWeightIn

public void setListOfWeightIn(ArrayList listOfWeightIn)

Сеттер ListOfWeightIn

Параметры: список дробных чисел, сохранненных в объекте класса

Возвращает: ничего

public ArrayList getListOfWeightOut()

Геттер ListOfWeightOut

Параметры: нет

Возвращает: список дробных чисел, сохраненной в переменной ListOfWeightOut

public void setListOfWeightOut(ArrayList listOfWeightOut)

Сеттер ListOfWeightOut

Параметры: список дробных чисел, сохранненных в объекте класса

Возвращает: ничего

Реализация класса: файл Neuron.java

Имя класса: Layer

Заметка: Этот класс абстрактный и не может быть проинициализирован.

Атрибуты

private ArrayList listOfNeurons

Переменная ArrayList объектов класса Neuron

private int numberOfNeuronsInLayer

Целочисленное значение для хранения количества нейронов, которая является частью слоя.

Методы

public ArrayList getListOfNeurons()

Геттер listOfNeurons

Параметры: нет

Возвращает: listOfNeurons

public void setListOfNeurons(ArrayList listOfNeurons)

Сеттер listOfNeurons

Параметры: listOfNeurons

Возвращает: ничего

public int getNumberOfNeuronsInLayer()

Геттер numberOfNeuronsInLayer

Параметры: нет

Возвращает: numberOfNeuronsInLayer

public void setNumberOfNeuronsInLayer(int numberOfNeuronsInLayer)

Сеттер numberOfNeuronsInLayer

Параметры: numberOfNeuronsInLayer

Возвращает: ничего

Реализация класса: файл Layer.java

Имя класса: InputLayer

Заметка: Этот класс наследует атрибуты и методы от класса Layer

Атрибуты

Нет

Методы

public void initLayer(InputLayer inputLayer)

Инициализирует входной слой с дробными псевдорандомными числами

Параметры: Объект класса InputLayer

Возвращает: ничего

public void printLayer(InputLayer inputLayer)

Выводит входные весы слоя

Параметры: Объект класса InputLayer

Возвращает: ничего

Реализация класса: файл InputLayer.java

Имя класса: HiddenLayer

Заметка: Этот класс наследует атрибуты и методы от класса Layer

Атрибуты

Нет

Методы

public ArrayList initLayer( HiddenLayer hiddenLayer, ArrayList listOfHiddenLayers, InputLayer inputLayer, OutputLayer outputLayer )

Инициализирует скрытый слой(и) с дробными псевдослучайными числами

Параметры: Объект класса HiddenLayer, список объектов класса HiddenLayer, объект класса InputLayer, объект класса OutputLayer

Возвращает: список скрытых слоев с добавленным слоем

public void printLayer(ArrayList listOfHiddenLayers)

Выводит входные весы слоя(ев)

Параметры: Список объектов класса HiddenLayer

Возвращает: ничего

Реализация класса: файл HiddenLayer.java

Имя класса: OutputLayer

Заметка: Этот класс наследует атрибуты и методы от класса Layer

Атрибуты

Нет

Методы

public void initLayer(OutputLayer outputLayer)

Инициализирует выходной слой с дробными псевдорандомными числами

Параметры: Объект класса OutputLayer

Возвращает: ничего

public void printLayer(OutputLayer outputLayer)

Выводит входные весы слоя

Параметры: Объект класса OutputLayer

Возвращает: ничего

Реализация класса: файл OutputLayer.java

Имя класса: NeuralNet

Заметка: Значения в топологии нейросети фиксированы в этом классе(два нейрона во входном слое, два скрытых слоя с тремя нейронами в каждом, и один нейрон в выходном слое). Напоминание: Это первая версия.

Атрибуты

private InputLayer inputLayer

Объект класса InputLayer

private HiddenLayer hiddenLayer

Объект класса HiddenLayer

private ArrayList listOfHiddenLayer

Переменная ArrayList объектов класса HiddenLayer. Может иметь больше одного скрытого слоя

private OutputLayer outputLayer

Объект класса OutputLayer

private int numberOfHiddenLayers

Целочисленное значение для хранения количества слоев, что является частью скрытого слоя

Методы

public void initNet()

Инициализирует нейросеть. Слои созданы и каждый список весов нейронов созданы случайно

Параметры: нет

Возвращает: ничего

public void printNet()

Печатает нейросеть. Показываются каждое входное и выходное значения каждого слоя.

Параметры: нет

Возвращает: ничего

Реализация класса: файл NeuralNet.java

Огромное преимущество ООП легко документировать программу в унифицированный язык моделирования(UML). Диаграммы классов UML представляют классы, атрибуты, методы, и отношения между классами очень простым и понятным образом, таким образом, помогая программисту и/или заинтересованным сторонам понять проект в целом. На следующем рисунке представлена самая первая версия диаграммы классов проекта: Сейчас давайте применим эти классы, чтобы получить некоторые результаты.

Показанный следующий код имеет тестовый класс, главный метод объектом класса NeuralNet, названный n. Когда этоn метод вызывается (путем выполнения класса), он вызывает initNet () и printNet () методы из объекта n, генерирующие следующий результат, показанный на рисунке справа после кода. Он представляет собой нейронную сеть с двумя нейронами во входном слое, три в скрытом слое и один в выходном слое:

public class NeuralNetTest {    public static void main(String[] args) {        NeuralNet n = new NeuralNet();        n.initNet();        n.printNet();    }}

Важно помнить, что каждый раз, когда код запускается, он генерирует новые псевдослучайные значения веса. Итак, когда вы запускаете код, другие значения появятся в консоли:

В сумме

В этой главе мы увидели введение в нейронные сети, что они собой представляют, для чего они используются, и их основные понятия. Мы также видели очень простую реализацию нейронной сети на языке программирования Java, в которой мы применили теоретические концепции нейронной сети на практике, кодируя каждый из элементов нейронной сети. Важно понять основные понятия, прежде чем мы перейти к передовым концепциям. То же самое относится и к коду, реализованному на Java. В следующей главе мы углубимся в процесс обучения нейронной сети и изучим различные типы наклонов на простых примерах.

От переводчика

Оригинал книги: Neural Network Programming with Java

Подробнее..

Перевод Запись событий Spring при тестировании приложений Spring Boot

24.02.2021 18:11:35 | Автор: admin

Одна из основных функций Spring - функция публикации событий.Мы можем использовать события для разделения частей нашего приложения и реализации шаблона публикации-подписки.Одна часть нашего приложения может публиковать событие, на которое реагируют несколько слушателей (даже асинхронно).В рамкахSpring Framework 5.3.3(Spring Boot 2.4.2) теперь мы можем записывать и проверять все опубликованные события (ApplicationEvent) при тестировании приложений Spring Boot с использованием@RecrodApplicationEvents.

Настройка для записи ApplicationEvent с помощью Spring Boot

Чтобы использовать эту функцию, нам нужен толькоSpring Boot Starter Test,который является частью каждого проекта Spring Boot, который вы загружаете наstart.spring.io.

<dependency>  <groupId>org.springframework.boot</groupId>  <artifactId>spring-boot-starter-test</artifactId>  <scope>test</scope></dependency>

Обязательно используйте версию Spring Boot >= 2.4.2, так как нам нужна версия Spring Framework >= 5.3.3.

Для наших тестов есть одно дополнительное требование: нам нужно работать со SpringTestContextпоскольку публикация событий является основной функциональностью платформыApplicationContext.

Следовательно, она не работает для модульного теста, где неиспользуется поддержка инфраструктуры Spring TestContext.Есть несколькоаннотаций тестовых срезов Spring Boot,которые удобно загружают контекст для нашего теста.

Введение в публикацию событий Spring

В качестве примера мы протестируем класс Java, который выдает UserCreationEvent,когда мы успешно создаем нового пользователя.Событие включает метаданные о пользователе, актуальные для последующих задач:

public class UserCreationEvent extends ApplicationEvent {   private final String username;  private final Long id;   public UserCreationEvent(Object source, String username, Long id) {    super(source);    this.username = username;    this.id = id;  }   // getters}

Начиная со Spring Framework 4.2, нам не нужно расширять абстрактныйкласс ApplicationEventи мы можем использовать любой POJO в качестве нашего класса событий.В следующий статье привеленоотличное введение в события приложенийс помощью Spring Boot.

НашUserServiceсоздает и хранит наших новых пользователей.Мы можем создать как одного пользователя, так и группу пользователей:

@Servicepublic class UserService {   private final ApplicationEventPublisher eventPublisher;   public UserService(ApplicationEventPublisher eventPublisher) {    this.eventPublisher = eventPublisher;  }   public Long createUser(String username) {    // logic to create a user and store it in a database    Long primaryKey = ThreadLocalRandom.current().nextLong(1, 1000);     this.eventPublisher.publishEvent(new UserCreationEvent(this, username, primaryKey));     return primaryKey;  }   public List<Long> createUser(List<String> usernames) {    List<Long> resultIds = new ArrayList<>();     for (String username : usernames) {      resultIds.add(createUser(username));    }     return resultIds;  }}

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

Например, наше приложение выполняет две дополнительные операции всякий раз, когда мы запускаем такоеUserCreationEvent:

@Componentpublic class ReportingListener {   @EventListener(UserCreationEvent.class)  public void reportUserCreation(UserCreationEvent event) {    // e.g. increment a counter to report the total amount of new users    System.out.println("Increment counter as new user was created: " + event);  }   @EventListener(UserCreationEvent.class)  public void syncUserToExternalSystem(UserCreationEvent event) {    // e.g. send a message to a messaging queue to inform other systems    System.out.println("informing other systems about new user: " + event);  }}

Запись и проверка событий приложения с помощью Spring Boot

Давайте напишем наш первый тест, который проверяет,UserServiceгенерирует событие всякий раз, когда мы создаем нового пользователя.Мы инструктируем Spring фиксировать наши события с помощью@RecordApplicationEventsаннотации поверх нашего тестового класса:

@SpringBootTest@RecordApplicationEventsclass UserServiceFullContextTest {   @Autowired  private ApplicationEvents applicationEvents;   @Autowired  private UserService userService;   @Test  void userCreationShouldPublishEvent() {     this.userService.createUser("duke");     assertEquals(1, applicationEvents      .stream(UserCreationEvent.class)      .filter(event -> event.getUsername().equals("duke"))      .count());     // There are multiple events recorded    // PrepareInstanceEvent    // BeforeTestMethodEvent    // BeforeTestExecutionEvent    // UserCreationEvent    applicationEvents.stream().forEach(System.out::println);  }}

После того, какмы выполняем публичный метод нашего класса испытываемый (createUserизUserServiceв этом примере), мы можем запросить все захваченные события из биновApplicationEvents,которые мы внедряем в наш тест.

Открытый.stream()методкласса ApplicationEventsпозволяет просмотреть все события, записанные для теста.Есть перегруженная версия .stream(),вкоторой мы запрашиваем поток только определенных событий.

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

Поскольку мы используем JUnit Jupiter иSpringExtension(зарегистрированный для нас при использовании@SpringBootTest), мы также можем внедритьbean-компонент ApplicationEventsв метод жизненного цикла JUnit или непосредственно в тест:

@Testvoid batchUserCreationShouldPublishEvents(@Autowired ApplicationEvents events) {  List<Long> result = this.userService.createUser(List.of("duke", "mike", "alice"));   assertEquals(3, result.size());  assertEquals(3, events.stream(UserCreationEvent.class).count());}

ЭкземплярApplicationEventsсоздается до и удаляется после каждого теста как часть текущего потока.Следовательно, вы даже можете использовать внедрение поля и@TestInstance(TestInstance.Lifecycle.PER_CLASS)делить тестовый экземпляр между несколькими тестами (PER_METHODпо умолчанию).

Обратите внимание, что запуск всего контекста Spring@SpringBootTestдля такого тестаможет быть излишним.Мы также могли бы написать тест, который заполняет минимальный SpringTestContextтолько нашимbean-компонентом UserService, чтобы убедиться, чтоUserCreationEvent опубликован:

@RecordApplicationEvents@ExtendWith(SpringExtension.class)@ContextConfiguration(classes = UserService.class)class UserServicePerClassTest {   @Autowired  private ApplicationEvents applicationEvents;   @Autowired  private UserService userService;   @Test  void userCreationShouldPublishEvent() {     this.userService.createUser("duke");     assertEquals(1, applicationEvents      .stream(UserCreationEvent.class)      .filter(event -> event.getUsername().equals("duke"))      .count());     applicationEvents.stream().forEach(System.out::println);  }}

Или используйте альтернативный подход к тестированию.

Альтернативы тестированию весенних событий

В зависимости от того, чего вы хотите достичь с помощью теста, может быть достаточно проверить эту функциональность с помощью модульного теста:

@ExtendWith(MockitoExtension.class)class UserServiceUnitTest {   @Mock  private ApplicationEventPublisher applicationEventPublisher;   @Captor  private ArgumentCaptor<UserCreationEvent> eventArgumentCaptor;   @InjectMocks  private UserService userService;   @Test  void userCreationShouldPublishEvent() {     Long result = this.userService.createUser("duke");     Mockito.verify(applicationEventPublisher).publishEvent(eventArgumentCaptor.capture());     assertEquals("duke", eventArgumentCaptor.getValue().getUsername());  }   @Test  void batchUserCreationShouldPublishEvents() {    List<Long> result = this.userService.createUser(List.of("duke", "mike", "alice"));     Mockito      .verify(applicationEventPublisher, Mockito.times(3))      .publishEvent(any(UserCreationEvent.class));  }}

Обратите внимание, что здесь мы не используем никакой поддержки Spring Test иполагаемсяисключительно наMockitoи JUnit Jupiter.

Другой подход заключается в том, чтобы не проверять события публикации явно, а проверять весь сценарий использования с помощью интеграционного теста:

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)class ApplicationIT {   @Autowired  private TestRestTemplate testRestTemplate;   @Test  void shouldCreateUserAndPerformReporting() {     ResponseEntity<Void> result = this.testRestTemplate      .postForEntity("/api/users", "duke", Void.class);     assertEquals(201, result.getStatusCodeValue());    assertTrue(result.getHeaders().containsKey("Location"),      "Response doesn't contain Location header");     // additional assertion to verify the counter was incremented    // additional assertion that a new message is part of the queue  }}

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

Резюме тестирования событий Spring с помощью Spring Boot

Все различные подходы сводятся к тестированию поведения и состояния.Благодаря новойфункции @RecordApplicationEvents вSpring Test у насможетвозникнуть соблазн провести больше поведенческих тестов и проверить внутреннюю часть нашей реализации.В общем, мы должны сосредоточиться на тестировании состояния (также известном как результат), поскольку оно поддерживает беспроблемный рефакторинг.

Представьте себе следующее: мы используем,ApplicationEventчтобы разделять части нашего приложения и гарантировать, что это событие запускается во время теста.Через две недели мы решаем убрать / переработать эту развязку (по каким-то причинам).Наш вариант использования может по-прежнему работать, как ожидалось, но наш тест теперь не проходит, потому что мы делаем предположения о технической реализации, проверяя, сколько событий мы опубликовали.

Помните об этом и не перегружайте свои тесты деталями реализации (если вы хотите провести рефакторинг в будущем :).Тем не менее, есть определенные тестовые сценарии, когда функция@RecordApplicationEvents очень помогает.

Исходный код со всеми альтернативными вариантами для тестирования Spring Event с помощью Spring Bootдоступен на GitHub.

Подробнее..
Категории: Events , Java , Testing , Spring boot

Partial Update library. Частичное обновление сущности в Java Web Services

17.02.2021 12:10:47 | Автор: admin

Введение

В структуре веб-сервисов типичным базовым набором операций над экземплярами сущностей(объектами) является CRUD (Create, Read, Update и Delete). Этим операциям в REST соответствуют HTTP методы POST, GET, PUT и DELETE. Но зачастую у разработчика возникает необходимость частичного изменения объекта, соответствующего HTTP методу PATCH. Смысл его состоит в том, чтобы на стороне сервера изменить только те поля объекта, которые были переданы в запросе. Причины для этого могут быть различные:

  • большое количество полей в сущности;

  • большая вероятность одновременного изменения одного и того же объекта при высокой нагрузке, в результате которого произойдет перезапись не только модифицируемых полей;

  • невозможность или более высокая сложность изменения полей в нескольких или всех объектах в хранилище(bulk update);

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

Рассмотрим наиболее часто применяемые варианты решения задачи частичного обновления.

Использование обычного контроллера и DTO

Один из наиболее часто встречаемых вариантов реализации метода PATCH. В контроллере пришедший объект десериализуется в обычный DTO, и далее по стеку слоев приложения считается, что все поля в DTO со значением null не подлежат обработке.

К плюсам данного метода можно отнести "привычность" реализации.

К минусам относится во-первых потеря валидности значения null для обработки (после десериализации мы не знаем отсутствовало ли это поле в передаваемом объекте или оно пришло нам со значением null).

Вторым минусом является необходимость явной обработки каждого поля при конвертировании DTO в модель и далее по стеку в сущность. Особенно сильно это чувствуется в случае обработки сущностей с большим количеством полей, сложной структурой. Частично вторую проблему возможно решить с использованием ObjectMapper(сериализация/десериализация POJO, аннотированных @JsonInclude(Include.NON_NULL) ) ,а так же библиотекой MapStruct, генерирующей код конвертеров.

Использование Map<String, Object> вместо POJO

Map<String, Object> является универсальной структурой для представления данных и десериализации. Практически любой JSON объект может быть десериализован в эту структуру. Но, как мы можем понять из типов обобщения, мы теряем контроль типов на этапе компиляции (а соответственно и на этапе написания исходного кода в IDE).

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

Недостатки же в данном случае глобальны: потеря контроля типов на этапе написания исходного кода и компиляции, необходимость явного приведения типов, высокая сложность рефакторинга, обнаружение практически всех ошибок, связанных с типами данных и именованием полей только в runtime(тесты или реальный запуск приложения).

Использование JSON Patch и JSON Merge Patch

JSON Patch и JSON Merge Patch являются стандартизованными и наиболее универсальными методами описания частичного изменения объекта. Спецификация Java EE содержит интерфейсы, описывающие работу с обоими этими форматами: JsonPatch и JsonMergePatch. Существуют реализации этих интерфейсов, одной из которых является библиотека json-patch. Оба формата кратко описаны в статье Michael Scharhag REST: Partial updates with PATCH.

Достоинства метода: стандартизация, универсальность, возможность реализовать не только изменение значения в объекте, но и добавление, удаление, перемещение, копирование и проверку значений полей в объекте.

К недостаткам метода можно отнести несколько большую сложность структуры данных, описывающих изменения в объекте и ее визуальное несоответствие типовому DTO объекта, более высокую сложность передачи данных об изменениях между слоями приложения, усложнение процесса валидации, усложненный процесс преобразования структуры описания изменений к запросам множественного обновления объектов в БД, etc.

Partial Update library

Основной целью создания библиотеки стало объединение положительных и исключение отрицательных сторон первых двух методов из описанных: использование классических DTO в фасадах и гибкости структуры Map<String, Object> "под капотом".

Ключевыми элементами библиотеки являются интерфейс ChangeLogger и класс ChangeLoggerProducer.

Класс ChangeLoggerProducer предназначен для создания "оберток" POJO, перехватывающих вызовы сеттеров и реализующих интерфейс ChangeLogger для получения изменений, произведенных вызовами сеттеров в виде структуры Map<String, Object>.

Для дальнейших примеров будут использоваться вот такие POJO:

public class UserModel {private String login;private String firstName;private String lastName;private String birthDate;private String email;private String phoneNumber;}@ChangeLoggerpublic class UserDto extends UserModel {}

Вот пример работы с такой "оберткой":

ChangeLoggerProducer<UserDto> producer = new ChangeLoggerProducer<>(UserDto.class);UserDto user = producer.produceEntity();user.setLogin("userlogin");user.setPhoneNumber("+123(45)678-90-12");Map<String, Object> changeLog = ((ChangeLogger) user).changelog();/*    changeLog in JSON notation will contains:    {        "login": "userlogin",        "phoneNumber": "+123(45)678-90-12"    }*/

Суть "обертки" состоит в следующем: при вызове сеттера его имя добавляется в Set<String>, при дальнейшем вызове метода Map<String, Object> changelog() он вернет ассоциативный список, ключом в котором будет имя поля, а соответствующим ключу значением будет объект, возвращенный соответствующим геттером. В случае, если объект, возвращаемый геттером реализует интерфейс ChangeLogger, то в значение поля пойдет результат вызова метода Map<String, Object> changelog().

Для сериализации/десериализации "оберток" реализован класс ChangeLoggerAnnotationIntrospector. Это класс представляет собой Annotation Introspector для ObjectMapper. Основной задачей класса является создание "обертки" при десериализации класса, аннотированного @ChangeLogger аннотацией библиотеки и сериализацией результата вызова метода Map<String, Object> changelog() вместо обычной сериализации всего объекта. Примеры использования ObjectMapper с ChangeLoggerAnnotationIntrospector приведены ниже.

Сериализация:

ObjectMapper mapper = new ObjectMapper.setAnnotationIntrospector(new ChangeLoggerAnnotationIntrospector());ChangeLoggerProducer<UserDto> producer = new ChangeLoggerProducer<>(UserDto.class);UserDto user = producer.produceEntity();user.setLogin("userlogin");user.setPhoneNumber("+123(45)678-90-12");String result = mapper.writeValueAsString(user);/*    result should be equal    "{\"login\": \"userlogin\",\"phoneNumber\": \"+123(45)678-90-12\"}"*/

Десериализация:

ObjectMapper mapper = new ObjectMapper.setAnnotationIntrospector(new ChangeLoggerAnnotationIntrospector());String source = "{\"login\": \"userlogin\",\"phoneNumber\": \"+123(45)678-90-12\"}";UserDto user = mapper.readValue(source, UserDto.class);Map<String, Object> changeLog = ((ChangeLogger) user).changelog();/*    changeLog in JSON notation will contains:    {        "login": "userlogin",        "phoneNumber": "+123(45)678-90-12"    }*/

Используя ObjectMapper с ChangeLoggerAnnotationIntrospector мы можем десериализовать пришедший нам в контроллер JSON с полями для частичного апдейта и далее передавать эти данные в подлежащие слои сервисов для реализации логики. В библиотеке присутствует инфраструктура для реализации мапперов DTO, Model, Entity с использованием "оберток". Пример полного стека приложения реализован в тестовом проекте Partial Update Example.

Итог

Partial Update library позволяет с рядом ограничений реализовать наиболее типичную задачу частичного изменения объекта, используя максимально близкий к типовому способ организации стека приложения. При этом универсальность ассоциативного списка объединена с сохранением контроля типов данных в процессе написания исходного кода и компиляции, что позволяет избежать большого числа ошибок в runtime.

В настоящее время функционал имеет ряд ограничений:

  • реализован только простейший маппинг "поле в поле", что не позволяет автоматизировать ситуации с разными именами одного и того же поля в DTO, Model, Entity;

  • не реализован модуль интеграции со Spring, в связи с чем для реализации сериализации/десериализации "оберток" DTO необходимо реализовать конфигурацию(как в примере), добавляющую ChangeLoggerAnnotationIntrospector в стандартный ObjectMapper контроллера приложения;

  • не реализованы утилиты формирования SQL/HQL запросов для bulk update операций с БД;

В последующих версиях планируется добавление недостающего функционала.

Формат данной статьи не позволяет более детально рассмотреть инфраструктуру для создания мапперов и показать применение библиотеки в типичном стеке приложения. В дальнейшем я могу более детально разобрать Partial Update Example и уделить больше внимания описанию внутренней реализации библиотеки.

Подробнее..
Категории: Java , Api , Rest , Patch , Controller

Кастомная (де) сериализация даты и времени в Spring

24.02.2021 18:11:35 | Автор: admin

Представьте довольно распространённую ситуацию: ваше приложение взаимодействует с клиентами, которые находятся в разных часовых поясах. Вам часто приходится работать с датами, а для корректной работы системы, они передаются с указанием часового пояса отправителя. При этом, вам нужно:

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

  2. В ответ возвращать дату и время с указанием серверного часового пояса

Для решения этой задачи Spring предоставляет удобный механизм для написания кастомной сериализации и десериализации. Главным его преимуществом является возможность вынести преобразования дат (и других типов данных) в отдельный конфигурационный класс и не вызывать методы преобразования каждый раз в исходном коде.

Десериализация

Для того, чтобы Spring понимал, что именно наш класс нужно использовать для (де)сериализации, его необходимо пометить аннотацией @JsonComponent

Ну а чтобы код был максимально кратким, я буду использовать внутренний статический класс, который должен быть унаследован от JsonDeserializerи параметризован нужным нам типом данных. Поскольку JsonDeserializerэто абстрактный класс, нам необходимо переопределить его абстрактный метод deserialize()

@JsonComponentpublic class CustomDateSerializer {        public static class LocalDateTimeDeserializer extends JsonDeserializer<LocalDateTime> {            @Override        public LocalDateTime deserialize(JsonParser jsonParser, DeserializationContext deserializationContext) {            return null;        }    }}

Из параметров метода получаем переданную клиентом строку, проверяем её на null и получаем из неё объект класса ZonedDateTime

public LocalDateTime deserialize(JsonParser jsonParser, DeserializationContext deserializationContext) {    String date = jsonParser.getText();    if (date.isEmpty() || isNull(date) {        return null;    }    ZonedDateTime userDateTime = ZonedDateTime.parse(date);}

Для получения разницы во времени, у переменной userDateTime нужно вызвать метод withZoneSameInstant() и передать в него текущую серверную таймзону. Нам остаётся лишь преобразовать полученную дату кLocalDateTime

Для надежности, предположим, что нам может прийти дата без таймзоны, либо вообще некорректные данные. Для этого случая, добавим обработку исключений. Полностью десериализатор будет выглядеть так

public static class LocalDateTimeDeserializer extends JsonDeserializer<LocalDateTime> {    @Override    public LocalDateTime deserialize(JsonParser jsonParser, DeserializationContext deserializationContext) throws IOException {        String date = jsonParser.getText();        if (date.isEmpty()) {            return null;        }        try {            ZonedDateTime userDateTime = ZonedDateTime.parse(date);            ZonedDateTime serverTime = userDateTime.withZoneSameInstant(ZoneId.systemDefault());            return serverTime.toLocalDateTime();        } catch (DateTimeParseException e) {            try {                return LocalDateTime.parse(date);            } catch (DateTimeParseException ex) {                throw new IllegalArgumentException("Error while parsing date", ex);            }        }    }}

Предположим, что серверное времяUTC+03. Таким образом, когда клиент передаёт дату 2021-01-21T22:00:00+07:00, в нашем контроллере мы уже можем работать с серверным временем

public class Subscription {    private LocalDateTime startDate;      // standart getters and setters}
@RestController public class TestController {    @PostMapping  public void process(@RequestBody Subscription subscription) {    // к этому моменту поле startDate объекта subscription будет равно 2021-01-21T18:00  }}

Сериализация

С сериализацией алгоритм действий похожий. Нам нужно унаследовать класс от JsonSerializer, параметризовать его и переопределить абстрактный метод serialize()

Внутри метода мы проверим нашу дату на null, добавим к ней серверную таймзону и получим из неё строку. Остаётся лишь отдать её клиенту

public static class LocalDateTimeSerializer extends JsonSerializer<LocalDateTime> {    @Override    public void serialize(LocalDateTime localDateTime, JsonGenerator jsonGenerator, SerializerProvider serializerProvider) throws IOException {        if (isNull(localDateTime)) {            return;        }        OffsetDateTime timeUtc = localDateTime.atOffset(ZoneOffset.systemDefault().getRules().getOffset(LocalDateTime.now()));        jsonGenerator.writeString(timeUtc.toString());    }}

Круто? Можно в прод? Не совсем. В целом, этот код будет работать, но могут начаться проблемы, если серверная таймзона будет равна UTC+00. Дело в том, что конкретно для этого часового пояса id таймзоны отличается от стандартного формата. Посмотрим в документацию класса ZoneOffset

Таким образом, имея серверную таймзону UTC+03, на выходе мы получим строку следующего вида: 2021-02-21T18:00+03:00.Но если же оно UTC+00, то получим 2021-02-21T18:00Z

Поскольку мы работаем со строкой, нам не составит труда немного изменить код, дабы на выходе мы всегда получали дату в одном формате. Объявим две константы одна из них будет равна дефолтному id UTC+00, а вторая которую мы хотим отдавать клиенту, и добавим проверку - если серверное время находится в нулевой таймзоне, то заменим Z на +00:00. В итоге наш сериализотор будет выглядеть следующим образом

public static class LocalDateTimeSerializer extends JsonSerializer<LocalDateTime> {    private static final String UTC_0_OFFSET_ID = "Z";    private static final String UTC_0_TIMEZONE = "+00:00";    @Override    public void serialize(LocalDateTime localDateTime, JsonGenerator jsonGenerator, SerializerProvider serializerProvider) throws IOException {        if (!isNull(localDateTime)) {            String date;            OffsetDateTime timeUtc = localDateTime.atOffset(ZoneOffset.systemDefault().getRules().getOffset(LocalDateTime.now()));            if (UTC_0_OFFSET_ID.equals(timeUtc.getOffset().getId())) {                date = timeUtc.toString().replace(UTC_0_OFFSET_ID, UTC_0_TIMEZONE);            } else {                date = timeUtc.toString();            }            jsonGenerator.writeString(date);        }    }}

Итого

Благодаря встроенным механизмам спринга мы получили возможность автоматически конвертировать дату и время в требуемом формате, без каких-либо явных вызовов методов в коде

Полностью исходный код можно посмотреть здесь

Подробнее..
Категории: Java , Spring , Json , Maven , Spring-boot , Serialization , Date , Deserialization

Еще раз о регекспах, бэктрекинге и том, как можно положить на лопатки JVM двумя строками безобидного кода

01.03.2021 00:05:02 | Автор: admin

Раннее утро, десятая чашка кофе, безуспешные попытки понять почему ваше клиентское (или еще хуже серверное) java-приложение намертво зависло при вычислении простого регекспа на небольшой строке Если подобная ситуация уже возникала в вашей жизни, вы уже наверняка знаете про бэктрекинг и темную сторону регулярных выражений. Остальным добро пожаловать под кат!

Бэктрекинг, или вечное ожидание результата

Проблема бэктрекинга при матчинге регулярных выражений уже неоднократно поднималась в различных статьях на хабре (раз, два, три), поэтому опишем ее суть без погружения в детали. Рассмотрим простой синтетический пример типичный экземпляр из так называемых "evil regexes" (аналог изначально представлен тут):

@Testpublic void testRegexJDK8Only() {  final Pattern pattern = Pattern.compile("(0*)*1");  Assert.assertFalse(pattern.matcher("0000000000000000000000000000000000000000").matches());}

Напомню: символ * в регулярных выражениях ("ноль или несколько символов") называется квантификатором. Им же являются такие символы, как ?, +, {n} (n количество повторений группы или символа).

Если запустить код на JDK8 (почему на более актуальных версиях воспроизводиться не будет опишем далее), то JVM будет очень долго вычислять результат работы метода matches(). Едва ли вам удастся его дождаться, не состарившись на несколько месяцев или даже лет.

Что же пошло не так? Стандартная реализация Pattern/Matcher из пакета java.util.regex будет искать решение из теста следующим образом:

  1. * - жадный квантификатор, поскольку всегда будет пытаться захватить в себе как можно большее количество символов. Так, в нашем случае группа (0)захватит полностью всю строку, звезда снаружи группы увидит, что может повториться ровно один раз, а единицы в строке не окажется. Первая проверка на соответствие провалилась.

  2. Произведем откат (backtrack) к начальному состоянию. Мы попытались захватить максимальную группу из нулей и нас ждал провал; давайте теперь возьмём на один нолик меньше. Тогда группа (0) захватит все нули без одного, снаружи группы укажет на наличие единственной группы, а оставшийся ноль не равен единице. Снова провал.

  3. Снова откатываемся к начальному состоянию и забираем группой (0) все нули без двух последних. Но ведь оставшиеся два нуля тоже могут заматчиться группой (0)! И теперь эта группа тоже попытается сначала захватить два нуля, после чего попытается взять один ноль, и после этого произойдет откат и попытка матчинга строки уже без трех нулей.

Легко догадаться, что по мере уменьшения "начальной" жадной группы будет появляться множество вариаций соседних групп (0), которые также придется откатывать и проверять все большее количество комбинаций. Сложность будет расти экспоненциально; при наличии достаточного количества нулей в строке прямо как в нашем примере возникнет так называемый катастрофический бэктрекинг, который и приведет к печальным последствиям.

"Но ведь пример абсолютно синтетический! А в жизни так бывает?" - резонно спросите вы. Ответ вполне ожидаем: бывает, и очень часто. Например, для решения бизнес-задачи программисту необходимо составить регулярку, проверяющую, что в строке есть не более 10 слов, разделенных пробелами и знаками препинания. Не заморачиваясь с аккуратным созданием регекспа, на свет может появиться следующий код:

@Testpublic void testRegexAnyJDK() {final Pattern pattern = Pattern.compile("([A-Za-z,.!?]+( |\\-|\\')?){1,10}");  Assert.assertFalse(pattern.matcher("scUojcUOWpBImlSBLxoCTfWxGPvaNhczGpvxsiqagxdHPNTTeqkoOeL3FlxKROMrMzJDf7rvgvSc72kQ").matches());}

Представленная тестовая строка имеет длину 80 символов и сгенерирована случайным образом. Она не заставит JVM на JDK8+ работать вечно всего лишь около 30 минут но этого уже достаточно, чтобы нанести вашему приложению существенный вред. В случае разработки серверных приложений риск многократно увеличивается из-за возможности проведения ReDoS-атак. Причиной же подобного поведения, как и в первом примере, является бэктрекинг, а именно сочетание квантификаторов "+" внутри группы и "{1,10}" снаружи.

Война с бэктрекингом или с разработчиками Java SDK?

Чем запутаннее паттерн, тем сложнее для неопытного человека увидеть проблемы в регулярном выражении. Причем речь сейчас идет вовсе не о внешних пользователях, использующих ваше ПО, а о разработчиках. Так, с конца нулевых было создано значительное количество тикетов с жалобой на бесконечно работающий матчинг. Несколько примеров: JDK-5026912, JDK-7006761, JDK-8139263. Реже можно встретить жалобы на StackOverflowError, который тоже типичен при проведении матчинга (JDK-5050507). Все подобные баги закрывались с одними и теми же формулировками: "неэффективный регексп", "катастрофический бектрекинг", "не является багом".

Альтернативным предложением сообщества в ответ на невозможность "починить" алгоритм было внедрение таймаута при применении регулярного выражения или другого способа остановить матчинг, если тот выполняется слишком долго. Подобный подход можно относительно легко реализовать самостоятельно (например, часто его можно встретить на сервисах для проверки регулярных выражений - таких как этот), но предложение реализации таймаута в API java.util.regex также неоднократно выдвигалось и к разработчикам JDK (тикеты JDK-8234713, JDK-8054028, JDK-7178072). Первый тикет все еще не имеет исполнителя; два остальных были закрыты, поскольку "правильным решением будет улучшить реализацию, которая лучше справляется с кейсами, в которых наблюдается деградация" (пруф).

Доработки алгоритма действительно происходили. Так, в JDK9 реализовано следующее улучшение: каждый раз, когда применяется жадный квантификатор, не соответствующий данным для проверки, выставляется курсор, указывающий на позицию в проверяемом выражении. При повторной проверке после отката достаточно убедиться, что если для текущей позиции проверка уже была провалена, продолжение текущего подхода лишено смысла и проводиться не будет (JDK-6328855, пояснение). Это позволило исключить бесконечный матчинг в тесте testRegexJDK8Only() начиная с версии jdk9-b119, однако второй тест вызывает задержки вне зависимости от версии JDK. Более того, при наличии обратных ссылок в регулярных выражениях оптимизация не используется.

Опасный враг: внешнее управление

Публикации, упомянутые в самом начале статьи, отлично раскрывают варианты оптимизации регулярных выражений, в результате чего катастрофический бектрекинг перестает быть опасным врагом; для сложных случаев потребуется дополнительная экспертиза, но в целом регулярное выражение можно почти всегда записать "безопасным" образом. Да и проверить себя тоже можно, например, на npmjs.com. Проблема остается при составлении очень сложных регулярок, а также в тех сценариях, когда регулярное выражение задается не программистом, а аналитиком, заказчиком после передачи решения, или же пользователем. В последнем случае управление сложностью регулярного выражения оказывается снаружи и вам придется позаботиться о том, чтобы при любых условиях приложение продолжало корректную работу.

Использование стандартной библиотеки в таком случае, очевидно, не лучший выбор. К счастью, существуют сторонние фреймворки, позволяющие производить матчинг за линейное время. Одним из таких фреймворков является RE2, под капотом которого используется DFA - подход. Не будем вдаваться в детали реализации и подробно описывать разницу подходов; отметим лишь его растущую популярность RE2 используется как дефолтный движок в Rust, а также активно применяется во множестве продуктов экосистемы Google. Для JDK7+ существует RE2/J, которая является прямым портом из C++ - версии библиотеки.

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

RE2/J - серебряная пуля?

Может показаться, что переход на RE2/J отличный выбор практически для каждого проекта. Какова цена линейного времени выполнения?

  • У RE2/J отсутствует ряд методов API у Matcher;

  • Синтаксис регулярных выражений совпадает не полностью (у RE2/J отствутет часть конструкций, в том числе обратные ссылки, backreferences). Вполне вероятно, после замены импорта ваша регулярка перестанет корректно распознаваться;

  • Несмотря на то, что формально код принадлежит Google, библиотека не является официальной, а основным ее мейнтейнером является единственный разработчик Джеймс Ринг.

  • Разработчик фреймворка подчеркивает: "Основная задача RE2/J заключается в обеспечении линейного времени выполнения матчинга при наличии регулярных выражений от внешних источников. Если все регулярные выражения находятся под контролем разработчика, вероятно, использование java.util.regex является лучшим выбором".

Надеюсь, этих пунктов достаточно, чтобы убедиться: RE2/J не серебряная пуля; фреймворк не является бескомпромиссным решением для проверки на соответствие регулярным выражениям. Реализация при создании кода повлечет ограниченный функционал, а прямая замена импорта в уже существующем коде может негативно сказаться на стабильности работы приложения.

Итоги

  1. Даже простые регулярные выражения при невнимательном написании могут сделать ваш продукт уязвимым для ReDoS.

  2. Движков регулярных выражений, которые были бы одновременно максимально функциональны, быстры и стабильны, не существует.

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

Если возможность самостоятельно задавать регулярное выражение есть не только у разработчика, то стоит реализовать защиту от вечной проверки с помощью создания таймаута или использования сторонних решений, позволяющих решать задачу матчинга за линейное время например, таких, как RE2/J.

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru