Микросервисы глазами простого разработчика

Последние два-три года стало модно говорить о микросервисах. В твиттере и на профильных ресурсах слово "microservice" мелькает уж очень часто. Но...

Microservices is like teenage sex, every body talking about it, but no body is doing it! #TGIF

— Arun Gupta (@arungupta) 26 июня 2015

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

Интересно, что микросервисы как подход к разработке можно было применять и пять лет назад и десять - этому ничего не мешало, просто не было такого тренда. Никто не мешал дробить крупные Java EE-проекты на большое количество маленьких WAR и JAR, разворачивать фермы Glassfish или JBoss и добиваться той же слабой связанности. Так же никто не мешал разрабатывать микросервисы в виде standalone-приложений. В целом этому способствовало и существование OSGi-контейнеров, которые, впрочем, в народе не особо прижились. Наиболее важной причиной увеличения популярности микросервисов на мой взгляд является популярность облачных сервисов: PaaS, IaaS и прочих XaaS.

Standalone или контейнеры?

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

Spring Boot и WildFly Swarm

На волне популярности микросервисов начали появляться фреймворки и проекты, упрощающие разработку микросервисов: к вышеупомянутым OSGi-контейнерам добавился Spring Boot, а так же ведётся разработка WildFly Swarm. Оба проекта предоставляют возможность разрабатывать микросервисы в виде standalone-приложений, минимизируя затрачиваемое время на конфигурирование компонента.

Стоит отметить, что Spring Boot уже является стабильным и достаточно успешным фреймворком, с помощью которого можно без лишней головной боли разрабатывать standalone-приложения, основанные на Spring Framework. Хотя далеко не все рекомендуют это делать, особенно приверженцы Java EE.

А вот с WildFly Swarm всё несколько хуже. Идея проекта заключается в интеграции Java EE в standalone-приложения. Смысл в этом есть, но сам проект ещё находится в разработке и до стабильного релиза, судя по всему, ещё очень далеко. Если при разработке простенького микросервиса с REST в случае со Spring Boot в итоге получается компактный jar на 5-10Мб, то в случае WildFly Swarm у вас в зависимостях будет добрая половина сервера приложений WildFly. Модульность Spring Framework взяла своё в данном случае.

Слово "микросервис" использовано в данном посте 20 раз.

Полезные ссылки

• Spring Boot
• WildFly Swarm 
• Apache Karaf

Spring Framework, Hibernate, JPA: Аннотации или XML?

Споры на данную тему в стане приверженцев Spring Framework существуют с момента релиза третьей версии данного фреймворка. И хотя в версии 2.5 уже можно было частично заменить конфигурирование приложения аннотациями, полностью отказаться от XML было нереально.

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

Стоит отметить забавный момент, что среди разработчиков фреймворка во время Spring Framework 3 не было единого мнения по этому поводу - в книге Pro Spring 3 использовались XML-конфигурации, а в книге Pro Spring MVC: with Web Flow - аннотации.

XML

С XML-конфигурациями в Spring Framework я работаю ещё с версии 2.5. На тот момент альтернатив не было. Зато можно было хотя бы использовать аннотацию @Autowired для внедрения зависимостей, чему я предпочитал непосредственное указание зависимостей в XML через сеттеры и конструкторы. С тех пор я унаследовал привычку конфигурировать практически всё при помощи XML, в том числе JPA и Hibernate. Для меня главным аргументом в пользу XML была возможность изменять настройки приложения на лету без необходимости собирать проект заново. Такая необходимость возникала, но нечасто. Хотя объективности ради стоит заметить, что именяющиеся компоненты Spring-приложения вполне можно конфигурировать properties-файлами или через JNDI.

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

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

Аннотации

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

Отдельно стоит отметить тот факт, что в мире Java EE всё давно конфигурируется при помощи аннтоаций: EJB, CDI, JPA и т.д. и Spring Framework совместим со всеми аннотациями Java EE.

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

Groovy

Отдельно стоит упомянуть возможность конфигурировать Spring-приложения при помощи Groovy-классов. Если классы конфигурации не компилировать, а оставлять скриптами, то приложение можно будет конфигурировать на лету. И при этом сам процесс конфигурирования будет значительно более гибким, чем даже при использовании XML. Но это если в проекте используется Groovy.

Вывод

Вывод прост - нужно стремиться к использованию аннотаций, раз это действительно проще, правильнее и рекомендуется разработчиками Spring Framework. Тем более, что в Java EE это стандарт, а на горизонте маячит Spring Boot, хотя никто не запрещает и там использовать XML.

Однако в плане маппингов JPA и Hibernate я так и остался при мнении, что использование XML значительно удобнее аннотаций, особенно в случаях, когда POJO-классы находятся в отдельной от бизнес-логики библиотеке. В этом случае клиентским Java-приложениям при использовании тех же API не нужно будет тянуть ненужные зависимости.