skyANAslippery1. нормальная ли это схема в данном случаи(разделение чтения и записи)?
Нормальная, называется она Command Query Responsibility Separation (CQRS) . Почитатйте, посмотрите примеры реализации для Java.
И особое внимание уделите всем недостатком этой архитектуры. На них хотя много букв в описании не потрачено, но остальное можно самому домыслить.

slipperyДобрый день. Попробую описать задачу: был большой проект на JAVA, со временем проект еще больше рос и вносить правки в монолитное приложение было все тяжелее. Тогда было принято решение часть функционала выносить в «сервисы» с которыми ядро будет общаться по REST, но при этом сервисы выполняя вынесенную логику напрямую обращались в базу ядра для записи и чтения данных. То есть это не сервисы, а просто вынесенная часть бизнес логики за пределы монолитного ядра. Между собой сервисы информацией не обмениваются, они работают либо как демоны(выполняя какую-то логику по крону например и изменяя данные в бд), либо принимают http запросы со стороны ядра, вынимают данные из бд, преобразовывают из и отдают ядру. Так же есть сервисы со своим хранилищем(азой), к примеру полнотекстовой поиск, но он опять таки для составления поискового индекса сервис напримую ходит в БД за данными. Со временем появилась идея все же сделать так называемые сервисы более независимыми и начать с того, перекрыть им возможность прямого доступа к данным.

Доступ к данным был разделен на 2 категории:

1. модификация(было решено делать через события и шины сообщений(брокер))
2. Чтения данных. И вот тут возник вопрос, как лучше его сделать. Пока на ум приходят 3 варианта:
2.1. оставить возможность сервисам читать данные напрямую из БД
2.2. делать методы внутренного api на стороне ядра(не хотелось бы, так как лищний раз трогать ядро не стоит)
2.3. оборачивать sql запрос построенный в сервисе в какой-то объект, пересылать его ядру http запросом, уже в ядре проверить, что это именно select, выполнить и вернут ответ обратно сервису в ввиде массива json. А сервис уже его пропарсит в нормальный список объектов с которым и будет работать.

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


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

2. Тут на форуме контроверсно обсуждали ESB. Может быть вам пригодится. Раскажите о вашем опыте и мне в копилку срурильных фактов.

slipperyХотелось бы узнать мнение знатоков по вопросам:

1. нормальная ли это схема в данном случаи(разделение чтения и записи)?
2. какой из вариантов для чтения предпочесть?
3. если все же использовать вариант с пересылкой упакованного sql запроса и выполнения его ядром, какой фрэймворк посоветуете? Я вот обратил внимание на JOOQ не знаю подойдет ли он для этого или нет?


ИМХО.
1. В некоторых случаях - да, но в большинстве - нет. Почему: сервис обновляет данные частично по результатам предварительного чтения. Начинается или возня с доступом к сервису или методы чтение данных дублируются в слое записи. Другой вариант: массивный апдейт с последующим чтением для предоставления результата. Пускаетесь в сложное предприятие по дроблению, синхронизации и предоставлений транзакционной целостности. Но, зависит от сервисов. Может для вас не актуально или не нужно.
2. 2.1 Всё остальное непонятно с какой целью и что будет лучше.

Рассмотрите стоимость архитектуры: сколько и как сложно вам нужно будет менять с 'улучшенной' архитектурой. Изменения в реализации сервиса приведут к изменениям в самом сервисе плюсь его часть которая реализует обработку сообщений 'изменения'.
При Rollout возможно вам придётся всю систему обновлять. При тестировании всё систему через тест прогонять.
Я не заню, как это у вас реализовано, может здесь и проблем не возникнет.

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

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

К примеру у нас есть система по продаже книг. Есть ядро, включаяющая себя практически всю логику, такую как сохранения информации о книгах, авторах, рецензиях, пользователях, покупках + предоставления АПИ клиентам(web, мобильные приложения и т.д.) для работы с этим.
Далее есть действительно много разных сервисов вокруг ядра, рассмотрим несколько:
1. Парсит xml к примре со склада и заносит новые книги в бд. запускается раз в сутки, сам обращается по АПИ на склад(стороняя система) получает данные, парсит и на прямую записывает в базя ядра новые книги. Таких сервисов несколько, так как складов несколько.
2. поисковой сервис, тоже раз в сутки обращается напрямую в базу ядра, вынимает информацию по книгам индексирует ее, также предоставляет АПИ для ядра(метод search), чтобы проводить поиск.
3. Сервис нотификаций по расписанию. Проверяет таблицу расписания из ядра и вызывает нотификации клиентов.
и т.д.

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


Другими словами в настоящий момент база данных является 'централным' сервисом и можно говорить о 2-Tier архитектуре.
'Ядро' - находится во 2 и служит gate для других клиентов (начало 3-Tier).
Интересно, как загрузчики данных узнают, что 'нового' нужно загрузить. Они читают для этого данные из базы? **

Может имеет смысл централизовать сервисы базы данных через процедуры?
Создание очереди загрузки может помочь, но решение зависит от ответа на **.

slipperyКакие есть проблемы:

1. мне не нравится, что сервисы имеют прямой доступ к данным, к примеру поисковой сервис, его по хорошему надо вынести на отдельную машину и чтобы он мог кластеризоваться для устойчивости, тогда получается он будет обращаться к данным ядра по сети. Другой вариант конечно иметь экземпляр сервиса рядом с ядром, тогда к примеру будет 2 машины в кластере, на каждой по ядру и по такому сервису.
Или к примеру сервис который парсит xml со складов, при кластеризации, получается мне его надо вынести или на отдельную машину и тогда снова возникает вопрос к доступу к базе по сети или же тоже делать его на каждой машине и контролировать чтобы запускался только 1 экземпляр.
Вообщем, мне хотелось бы чтобы сервисы были как независимые процессы, имели свой namespace и общались ли бы с ядром как-нибудь по другому, может быть я не прав и доступ напрямую тоже хорошо, может не стоит это менять, у меня нет к сожалению никакого опыта в этом.

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

3. версионность, сейчас есть проблема, разработчик поменял какую-то таблицу в ядре и при этом, "поломал" 3 сервиса от нее зависящих. Сейчас нет никакого механизма, который бы даже вообще сказал бы, какие сервисы упали из-за изменений ядра, надо помнить самому или это уже выясняется в работе, когда сервис перестает работать, хотелось бы решить как то это проблему. У меня уже даже были мысли, что сервис-то знает с какими таблицами он работает, тогда при разработке я могу взять их схему, наложить на нее хеш и запомнить эту строку в сервисе. а при старте сервиса при рукопожатии с ядром запрашивать новых хеш с ядра(передаем на ядро названия таблиц, ядро вынимает их текущую схему, делает хеш и возвращает сервису) и если строки не совпали, то сервис не стартует, так я хотя бы смогу знать что мое изменение в таблице ядра поломала такие-то сервисы. Как вам такая брелдовая идея?)


Вы думаете всё перевести на 3-Tier. Это уже вопрос почти религии. Явных преимуществ я не вижу а ответ зависит от многих факторов: софтварные лицензии, стоимость оборудования, стоимость разработки и поддержки. Тут я не берусь гадать.