Архитектура приложения — MySQL+PHP+Java против MySQL+чисто Java

Есть один проект который я счас переписываю. Суть такова — это бекэнд одного блог сервера. Блогеры пишут в свои блоги, часть постов (заголовок и таги) записывается в mysql базу. После этого отдельный пхп скрипт раз в 5 минут проверяет новые записи в mysql (по дате изменения) и пересылает новые записи через curl на отдельно стоящий сервак с томкетом где живет джава приложение со сложной логикой. Оно проверяет таги, заголовки и после обработки пишет их в триплстор. Моя задача — добавить пару языков в джава приложение и заодно избавиться от пхп скрипта.

Я настаиваю на том что пхп скрипт должен остаться — он хорошо справляется со своей задачей, его легко модифицировать (не надо тащить кучу зависимостей как для джавы каждый раз когда что то меняется, не надо перекомпилировать, можна менять прямо на серваке в виме), он является независимым законченным модулем (нет никакой зависимости от компонентов других модулей). Солюшин архитектор говорит что пхп скрипт должен быть убран, а джава приложение должно начать само ходить к mysql, проверять обновления и тащить новые данные. Его аргументы — пхп скрипт вносит разброс в технологии и если что то не работает то нада смотреть в логи томкета и в логи джава приложения и еще и в логи пхп. А так останется одна джава и это намного упрощает обслуживание. Я так и не смог уговорить солюшин архитектора, но он сказал что если у меня есть серьезные аргументы то он таки согласится оставить пхп скрипт. Ищу помощи зала — может кто то что посоветует — оставлять пхп или избавляться и добавлять эту функциональность в джава приложение?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А у вас time and materials ? Тоді план дій наступний. Скрипт на PHP — викинути. Замість нього — втикнути Oracle Service Bus. Потратити 3 місяці, для підтримки розкачати команду на 0.5 FTE — інтегратора.

Якщо серьозно, я бачу наступні проблеми з прямою Tomcat-Mysql інтеграцією:
— якщо структура бази блог сервера поміняється, потрібно буде міняти/редеплоїти Джава частину
— якщо база і Томкат не в одній DMZ — потрібно буде настроювати файрволи, виставляти базу назовні, можливо купляти SSL сертифікат і т. п.
— про проблему з кількома Томкат-нодами і шедулінгом вже писали нижче

вынесите этот скрипт в микросервис и скажите что проблема решена :)

Java+PHP+MySQL
Java+RebbitMQ+MySQL
Я дотримуюсь думки архітектора.
Можна спробувати переконати бенчмарком. Інші нюанси архітектор, апріорі, уже розглянув

MySQL+чисто Java.
PHP-скрипт можно или убрать, или переписать.

А почему оно вообще так сделано? И когда блогеры пишут в блоги — в базу тоже php сохраняет? Если да, то почему данные собираются потом отдельным скриптом, а не сразу отправляются на отдельностоящий сервак? Как по мне, вместо этого php-скрипта должен быть сервер очереди (gearman например, но сейчас наверное есть что-то надежнее и удобнее). Блогер пишет пост — в очередь кладется задача, жава приложение из очереди задачу забирает и исполняет. Но это хорошо переписать нужно. А в текущем варианте по-моему пофиг, php там посрединке или java.

И когда блогеры пишут в блоги — в базу тоже php сохраняет?

странная фраза.

Ну в задаче есть блогеры с блогами, php-скрипт, mysql, java-сервер и triple store. php-скрипт раз в 5 минут берет данные из базы и шлет java-серверу. Вот и возник вопрос, а кто кладет их в базу: тот же php скрипт или другой php скрипт, или может какая-то еще java-программа.

Другой скрип кладет, который отвечает за блоги

Ну я считаю что замена того пхп-скрипта, который общается с жавой, на сервер очереди — самое адекватное решение. Иначе нет особо смысла трогать, мало что поменяется от того что его не будет совсем. Сервер же очереди позволит:
1) Обновлять данные не раз в 5 минут, а по мере их поступления и в зависимости от нагрузки на java-сервер
2) Легко масштабировать — если поднять еще пару серверов с java-частью, каждый из них будет забирать задачу из очереди и её обрабатывать. И не будет проблем как писали ниже («отключать таймер»), так как когда обработчик берет задачу — она убирается из очереди и другие обработчики её взять уже не могут.

а что такое «сервер очереди» ? вы предлагаете rebbitmq еще добавить ?

Вот я не знаю какой сейчас развит/популярен. RabbitMQ вроде один из. Я gearman использовал, поэтому про другие ничего не могу сказать. Не просто добавить, а добавить его и убрать промежуточный скрипт. Сейчас есть 5-минутный лаг между

Блогеры пишут в свои блоги
и
Оно проверяет таги, заголовки и после обработки пишет их в триплстор.
Сервер очередей способен эту задержку сократить или убрать совсем (в зависимости от загруженности системы). Но дорабатывать нужно будет и жава часть (чтобы читала и обрабатывала задачи из очереди), и php-часть, работающую с блогерами (при посте добавлять в очередь задачу на обработку).

Но это изменение может сказаться положительно на работе системы в целом, а просто убирание php-скрипта и перенос его кода в java ни на чем не скажется, это изменение ради изменения.

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

Та где угодно ставить, ему не обязательно отдельный сервер иметь.

«Не трожь пока работает»- прописная истина

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

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

ИМХО, скрипт на пхп и правда лишний в той конструкции что вы описали. Если нужна гибкость изменения парсинга, то я бы прикрутил какой-то dsl в отдельном файле, и джава приложение в рантайме запускает выполнение актуальной версии.

Решения php+java имеют право на жизнь когда сложная логика на пыхе, а на джаве микросервисы.
А если наоборот — то пхп лишний.

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

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

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

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

что значит отключать таймер ?

java.util.timer или то что вы будете вместо него использовать для того чтобы каждые 5 минут поллить базу. Можно конечно использовать environment переменную и явно передавать будет ли таймер активен или нет.

можна менять прямо на серваке в виме

йшов 2017 рік.

Да и системы контроля версий видимо не очень нужны в 2017. Скачай файлик с прода, чтобы получить актуальную версию.

только хардкор, только все в живую. Ты тогда и не сеньйор если не можешь на продакте поменять файлик в виме.

Кхе, я с самых джуниорских времен так делал, только в блокноте.

А если я nano предпочитаю, то я кто? Наносеньйор или просто хер с горы?

))) вим мало где стоит, я обычно чистый ви пользую

Собственно он прав, чем меньше языков, систем и прочего, тем легче саппортить проект. Тебе просто лень переписывать скрипт на пыхе?

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

Как минимум, потому что все будет в одном месте и на одном языке. Вообще, максима «работает — не трогай» она верна, но раз кастомер захотел и они согласны платить, то, я не пойму, почему вы жалуетесь. Пчелы против меда, как говориться.

А кто-нибудь хорошо знает, как работает PHP скрипт ? Чтобы не было потом — вот в PHP раньше работало, а вы криво переписали.

наврядли это пойдет как аргумент. Если это можна выразить в величинах типа пхп требует 1 час на закрытие тикета и 2а часа на внесение модификаций, в среднем 3и тикета в год и 3и модификации = 270 долларов в год при цене 30 долларов в час,а джава — 2а час на тикет и 4 часа на изменения = 900 долларов в час при цене 50 долларов в час, — то может еще и прокатит, но у меня таких данных нет и 270 против 900 за год ничего не решает.

А есть деньги и время на переписывание php скрипта ? Чтобы просто не было хотелкой ради хотелки и удовл-ния ЧСВ Солушин архитектора

деньги есть, время переписывание скрипта на джаву и интеграцию с основным приложением оценили в 60 часов (полторы недели). С скриптом есть отдельный хмл файл с 6ю или 8ю SQL запросами которые скрипт по очереди читает и исполняет, поэтому это немного сложнее чем просто один стандартный запрос.

Извините за глупый вопрос. На модуль, единственная задача которого раз в 5 минут считать с XML файла 8 SQL запросов и запустить их по очереди дают полторы недели времени?

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

Этого ещё и мало может быть

Подписаться на комментарии