17 сентября в Киеве пройдет конференция IT NonStop Java Craft. Ее специальным гостем станет Питер Лоури — основатель Performance Java User’s Group и Java Chronicle open-source library, создатель блога Vanilla Java. В Киеве он выступит с двумя докладами, а накануне выступлений проведет воркшоп, посвященный Java 8. DataArt побеседовал с Питером о настоящем и ближайшем будущем Java-экосистемы, популярности микросервисов и основных проблемах модных технологий.
Об архитектуре
— Java 8 сделала огромный шаг к модели реактивного программирования. Последняя версия Spring тоже поддерживает некоторые ее элементы. Каким, на ваш взгляд, будет следующий набор лучших практик разработки приложений для больших предприятий?
— Компания Oracle заранее стремится правильно позиционировать JavaEE, чтобы воспользоваться преимуществами, которые дают микросервисы и реактивное программирование. О планах компании мы услышим совсем скоро, на предстоящей ежегодной конференции JavaOne. В частности, Java 9 получит поддержку Reactive Flow Control в новом Flow API в качестве части пакета по работе с многопоточностью.
— В какой степени новые возможности функционального и реактивного программирования повлияют на процесс программной разработки для корпораций?
— Функциональные модели изменяют способ создания и настройки потоков данных. Я думаю, что в будущем мы увидим меньше конфигураций в XML- или JSON-форматах и больше конфигураций, созданных программно с использованием Java.
Важность и популярность модели реактивного программирования возрастут, хотя, подозреваю, что это будет происходить постепенно.
— Сейчас микросервисы очень популярны. Создается впечатление, что буквально каждый старается задействовать этот подход. Считаете ли вы, что скоро архитектура микросервисов будет доминировать даже в относительно небольших проектах?
— Микросервисы представляют собой набор лучших практик в разработке. Они поддерживают несколько независимо развертываемых компонентов. Я уверен, что наиболее эффективные из этих средств разработки будут доминировать даже в небольших проектах, однако инструменты, которые лучше всего подходят для масштабных приложений, вряд ли найдут широкое применение в этом сегменте.
Наибольшее влияние микросервисов отмечается в следующих областях:
– асинхронный обмен сообщениями для улучшения пропускной способности (по сравнению синхронным обменом);
– частные наборы данных (по сравнению с распределенными наборами); что является значительным испытанием для баз данных, которые исполняют роль централизованного хранилища всех объектов приложения и их состояний.
— Разработка приложения с использованием архитектуры микросервисов обычно несколько сложнее, чем реализация монолитного приложения.
— Использование каждой методологии и инструментов, которые предлагают микросервисы, может быть сложнее, чем создание «монолита». Однако, если вы используете набор инструментов, способных удовлетворить ваши потребности, декомпозиция приложения с разбивкой его на отдельные компоненты с четкой бизнес-целью у каждого, поможет сделать ваш продукт проще. Вы можете реализовать его как монолитное приложение, но для этого нужна идеально налаженная командная работа. Использование же микросервисов само по себе диктует необходимость разделить работу на участки.
О фреймворках
— Когда дело доходит до проверки надежности и производительности, появляются дополнительные сложности.
— То, как вы развертываете приложение, не должно играть большой роли, если вы тестируете его по стратегии черного ящика.
Если же вы тестируете по стратегии белого ящика, микросервисы хороши тем, что помогут установить четкие границы для проверки таймингов.
С точки зрения надежности проблемы могут возникнуть с большим количеством элементов, но при этом более простые сервисы могут быть протестированы индивидуально.
— Нужны ли, на ваш взгляд, дополнительные фреймворки (или расширение существующих), которые упростят тесты микросервисов и/или проверку производительности, латентности и т. д.?
— Я не большой поклонник фреймворков. У нас есть методология для профилирования ключевых взаимодействий end-to-end путем добавления высокоточных счетчиков производительности. В прошлом для этих счетчиков не было четко определенного места. В случае монолитных приложений я бы использовал места, привязанные к каждому событию записи данных и чтения сообщения. Если размеры ваших сервисов примерно одинаковы, это хорошее начало. Впоследствии вы сможете добавлять и другие счетчики по мере необходимости
О средствах сборки
— Поддерживают ли существующие инструменты для автоматической сборки (Maven, Gradle) цикл разработки микросервисов?
— Maven и Gradle поддерживают разработки с множеством модулей. Скорее всего, у вас будет модуль для каждого класса микросервисов (или множественные вхождения одного и того же сервиса), где Maven/Gradle могут быть расширены для тестирования микросервисов и развертывания посредством непрерывной интеграции.
— Что на сегодня стоит улучшать?
— Самая большая трудность — в надлежащем понимании проблем и методологий. Только располагая соответствующими знаниями, вы можете определить, какие инструменты тестирования подходят для вашей конкретной ситуации.
Нередко разработчики начинают активно использовать новые модные инструменты и только позднее находят для них действительно разумное применение. Например, при использовании Docker велика опасность, что вы инвестируете в его изучение время, а инструмент так и не станет оптимальным решением вашей проблемы. В одной ситуации время, потраченное на изучение новых инструментов, оправдывает себя, в другой — нет.
» Подробнее о конференции IT NonStop Java Craft
» Билеты на конференцию
» Билеты на воркшоп Питера Лоури в Киеве Java 8 in Depth
