Преимущества и недостатки вертикального развертывания в Jboss / MySQL - PullRequest
0 голосов
/ 09 июня 2011

Я работаю над проектом, в котором для каждого приложения есть один файл WAR, он похож на магазин приложений.
Таким образом, в 10 приложениях развернуто 10 различных файлов WAR.Обычно внутри файла WAR есть DAO, BL как отдельные jar-файлы, которые предоставляют веб-сервисы.
Однако в некоторых случаях мы ссылаемся на библиотеку, обычно DAO / BL, из другого файла WAR.
Я не уверенесли это правильный подход.Кажется, мы сталкиваемся с трудностями при развертывании, чтобы выяснить, какие версии развернутых JAR-файлов используются и т. Д. Другой подход заключается в том, чтобы не общаться с JAR другого приложения (DAO), а в случае необходимости общаться с развернутым веб-сервисом от клиента.

В DAO есть mysql-ds.xml для базы данных в MySQL.
Мы могли бы иметь один источник данных для всех функций, но не уверены, поможет ли это.

Как вы можете понять из моего предыдущего параграфа, я немного смущен и также обеспокоен, если у нас есть 100 различных приложений, тогда поддерживать все 100 из них с их зависимостями было бы очень сложно.Кроме того, как пул соединений может эффективно использоваться из jboss?Было бы хорошо иметь единую базу данных для всех приложений или несколько баз данных - это с точки зрения обслуживания ??Наш стек

Jboss
Apache CXF
Dozer 
DAO (Hibernate)
Entity (POJO)
Hibernate
Mysql

И maven как инструмент для сборки.Я знаю, что мои вопросы носят общий характер, пожалуйста, дайте мне знать, если вам нужна дополнительная информация.

Ответы [ 2 ]

1 голос
/ 09 июня 2011

Подобными сложными инфраструктурами всегда сложно управлять.

Существует три основных подхода, каждый из которых имеет свои плюсы и минусы:

  1. Веб-сервисы для инкапсуляции всего бизнес-уровня / доступа к данным в API. Это сводит к минимуму распространение версий jar-файлов в различных приложениях, но заставляет вас быть более строгими в отношении изменений API.
  2. Создание библиотек, которые могут использоваться несколькими проектами. Мне неясно, что вы имеете в виду, ссылаясь на библиотеку из другого файла WAR, возможно, именно это вы имеете в виду, когда включаете соответствующие файлы jar в недавно развернутую WAR. Это приводит к проблемам совместимости версий, о которых вы упомянули, но может сделать изменение существующих API более гибким, поскольку вам не нужно сразу изменять все существующие приложения.
  3. Инкапсулирует всю логику данных в базе данных. По моему опыту, это наиболее проблематично, поскольку отделяет разработчика от знаний о том, как работает бизнес-логика, и может быть наиболее хрупким - одно изменение хранимой процедуры может быть сложнее обнаружить, когда оно начинает ломать другие приложения, чем другое. подходы.

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

0 голосов
/ 09 июня 2011

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

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

По этой причине я бы рекомендовал вам использовать как можно больше логики в MySQL.

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

Общие идеи и указатели

Вы можете использовать хранимые процедуры / функции, чтобы делать вещи

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

Использовать сохраненные функции для выполнения расчетов на полях. (например, использовать хранимую процедуру для резервирования транзакции)

Price_per_sales_line = price * quantity * 1+tax% * 1-discount%  

Если вы поместите эту логику в функцию MySQL, вам не нужно беспокоиться об отладке этого в приложении A или B, потому что все приложения будут работать одинаково.

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

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

Псевдокод

CREATE table blackhole_new_sales_item (
  name varchar(45) not null
  price decimal(10,2) not null
  category_id integer not null ) 
ENGINE = Blackhole;

DELIMITER $$

CREATE TRIGGER ai_bh_new_sales_item_each FOR EACH ROW
BEGIN
  /*all stuff inside a trigger happens in a single transaction*/
  DECLARE new_item_id INTEGER;
  INSERT IGNORE INTO items (name) VALUES (NEW.name);        
  SELECT id INTO new_item_id FROM items WHERE name = NEW.name;

  INSERT IGNORE INTO item_categories (item_id, cat_id) VALUES (new_item_id, NEW.category_id)

  INSERT INTO price (item_id, price, valid_from, valid_until) VALUES 
     (new_item_id, NEW.price, NOW(), '2038-12-31');
END $$

DELIMITER ;

В своих приложениях вы можете просто сделать один:

INSERT INTO blackhole_new_sales_item VALUES ('test','0.99',2)

И триггер позаботится обо всем, и если вы измените структуру своей базы данных, вам нужно только изменить внутреннюю часть триггера, и все ваши приложения будут работать без изменений.
Если вы добавите дополнительные поля в таблицу blackhole, вам нужно будет изменить только один вызов в каждом приложении.
Вы даже можете создать дополнительную таблицу «черных дыр» и создать для этого отдельный триггер, а также заполнить свой старый триггер таблицы «черных дыр» резервным кодом для поддержки старых приложений.

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

Надеюсь, это поможет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...