Разрешить модульную разработку, все еще работая в той же JVM? - PullRequest
2 голосов
/ 14 марта 2010

Наше текущее приложение работает в одной JVM.

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

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

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

Что мне не нравится в этом:

  • REST означает, что мы должны упорядочить данные в / из XML
  • Представления БД объединяют системы, что противоречит концепции отдельных сервисов
  • MQ / добавлена ​​системная шина
  • Неизбежно некоторое дублирование кода между службами
  • Вы настроили n конфигураций сервера JBoss, нам нужно выполнить n развертываний, n сценариев настройки и т. Д. И т. Д.

Есть ли лучший способ структурировать внутреннее приложение, чтобы позволить модульную разработку и развертывание, в то же время позволяя приложению работать в одной JVM (и достигая связанных с этим преимуществ)?

Ответы [ 2 ]

3 голосов
/ 14 марта 2010

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

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

Сервер OSGi разрешает выгрузку и обновление пакетов во время выполнения, и приложения должны работать нормально (если ухудшено) при условии соблюдения жизненного цикла пакета OSGi .

0 голосов
/ 15 марта 2010

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

Если вы хотите перезапустить сервер, то одним из подходов может быть скомпилировать код в отдельные файлы JAR и развернуть модуль, вставив новый JAR и перезапустив. Это в основном вопрос структурирования базы кода, чтобы не возникали плохие зависимости, а вызовы между jar-файлами выполняются через неизменяемые интерфейсы. (Или альтернативно, используйте абстрактные классы, чтобы вы могли добавить новый метод с реализацией по умолчанию.) Ваша система сборки может помочь, убедившись, что отдельно развернутые модули могут зависеть только от общих интерфейсов, а все остальное является ошибкой компиляции. Но обратите внимание, что ваш компилятор не поможет вам обнаружить несовместимости, когда вы меняете файлы jar, с которыми вы не компилировали, поэтому я не уверен, что это действительно позволяет избежать хорошего процесса QA.

Если вы хотите развернуть новый код без перезапуска JVM, то OSGI является стандартным способом сделать это. (Но о котором я мало знаю.)

...