Lightbend Lagom — как рефакторить монолиты Java EE

Я смотрел вебинар Lightbend, посвященный рефакторингу монолитов в микросервисы, и у меня возник вопрос. Основная цель фреймворка — рефакторинг монолитов, но лагом, похоже, работает на собственном контейнере и наборе технологий. Когда я думаю о монолитах и ​​устаревших приложениях Java, основная технология, которая приходит мне на ум, — это Java EE. Я думаю, что большинство приложений в производстве сегодня основано на некоторых технологиях Java EE. Тот, в котором я работаю, в основном основан на EJB. Итак, мой вопрос: как Лагом решает эту проблему? Я предполагаю, что рефакторинг такого приложения включает преобразование удаленного поиска EJB в остальные вызовы. Но как мне сохранить локальные EJB-компоненты моего приложения, если lagom не запускается в контейнере Java EE? Можно ли использовать оба?


person Augusto    schedule 11.04.2016    source источник


Ответы (3)


У меня нет глубоких знаний о Lagom, однако рынок, использующий архитектуры, основанные на микросервисах, сильно зависит от весенней загрузки/облака. В настоящее время я работаю над действительно большим проектом с использованием микросервисов, и кажется, что ребята из весны предоставляют множество фреймворков/инструментов для каждого шаблона микросервисов, которые вы должны иметь в виду, когда думаете о микросервисах. С другой стороны, Netflix (крупнейший пользователь микросервисов) полагается на Spring, и я думаю, что Spring Boot/Cloud — хороший способ реорганизовать монолитное приложение Java EE в микросервисы.

person Rene Enriquez    schedule 12.04.2016
comment
Я согласен с вами, что было бы намного лучше полагаться на Spring Boot, чем на JEE, но дело в том, что мне пришлось бы сделать гораздо больше рефакторинга, чтобы заменить локальные EJB (которое приложение я использую для внедрения зависимостей) использовать эквивалент Spring. - person Augusto; 12.04.2016
comment
Это не ответ, это просто продвижение альтернативных фреймворков по сравнению с рассматриваемым. - person Jon; 12.02.2017

Я предлагаю посмотреть https://vimeo.com/163760711. Ответ заключается в том, что вы не должны просто брать свои EJB и превращать их в сервисы, если вы сделаете это, вы просто привнесете всю сложность и проблемы с производительностью, связанные с наличием множества сервисов, и не получите никаких преимуществ микросервисов. Вам нужно переосмыслить свою архитектуру, если вы хотите извлечь выгоду из микросервисов.

person James Roper    schedule 06.05.2016
comment
Я с тобой согласен. Большая проблема в том, что я не могу переделать 10-летнее приложение с нуля, чтобы сделать это. Я могу реорганизовать вызовы из модуля в модуль, но удаление контейнера JEE потребует переделки приложения. - person Augusto; 06.05.2016
comment
Конечно нет, это нужно делать постепенно. Продумайте, как будет выглядеть конечная архитектура, затем решите, какие наиболее ценные изменения следует внести в первую очередь, а затем начните декомпозировать. Это может занять годы, но это нормально, приложения существуют уже 10 лет, поэтапный подход к их улучшению продлит срок службы еще 10 лет. - person James Roper; 09.05.2016

Вы можете начать с представления существующих EJB-сервисов с помощью набора веб-сервисов REST, которые, в свою очередь, будут использоваться вашими новыми микросервисами на основе Lagom, например так:

[Сервисы EJB] ‹- [Шлюз служб REST на основе EJB] ‹- [Микросервисы на основе Lagom]

или как модули развертывания:

[ваше приложение EJB .EAR] ‹- [шлюз EJB-REST .WAR] ‹- [приложение на основе Lagom]

Поскольку ваше EJB-приложение будет работать в контейнере (например, Wildfly), ваше приложение Lagom будет развернуто независимо (возможно, на другом хосте). Внедрение слоя REST Services позволит вам разрабатывать каждый из модулей независимо, что является ключом к успеху в данном случае.

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

Это именно то, что я сделал, и это работает как шарм.

person monad    schedule 02.04.2018