Перенос крупномасштабного приложения от JavaEE на Akka

Question

Предположим, у меня есть очень крупномасштабное веб-приложение на стороне сервера, написанное на JavaEE (и связанные с ним технологии, классически объединенные с ним), и я решил полностью перенести его на Akka (и связанные с ним, в том числе перемещение кода в Scala). Причины решения о миграции не важны: предположим, что я должен это сделать, и все для этого.

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

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

Answer 1

Это открытый вопрос. Но позвольте мне попытаться дать вам некоторые идеи. Работая с системой J2EE, а также с системой Play2/Akka/Spray.io (Scala), я могу предоставить вам следующие рекомендации высокого уровня/общего руководства по миграции.

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

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

Реализовать прототип: Возьмите раздел-кандидат и создайте прототип, который обеспечивает те же функциональные возможности. Теперь оцените и сравните новые возможности со старыми с точки зрения различных атрибутов качества (производительность, изменчивость, расширяемость и т. Д.). Прототип также даст вам оценку технических рисков, проблем и усилий.

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

Поместите прототип: Попробуйте прототип прототипа небольшому подмножеству пользователей/заинтересованных сторон и получите обратную связь. Развязка прототипа с использованием интерфейсов REST/pub-sub - хорошая идея.

План миграции: Создайте план и расписание для отдыха вашей системы.

Я могу быть более конкретным, если вы предоставляете более целенаправленные вопросы.