Проблемы с механикой головки по каким-то косвенным признакам определяются? Потому что меня очень сильно напрягают моменты с очень длительной задержкой к случайным данным.
А не может такого быть, чтобы на самом сайте не было никакого описания апишки плагина, только абстрактное описание, а после покупки в самом архиве была подробная документашка(или как там платные плагины поставляются...)?
padlyuck, это я знаю. А в принципе, я могу использовать неймспейс "rep"? На сайте jackrabbit он отдельно помечен как internal и у него даже нету своего uri. Может я его вообще не должен использовать.
J. Snow, это приобретает смысл, когда вдруг неожиданно понадобится. Ну хорошо, тогда я Вам советую сделать not null и заполнять пустые поля пустой строкой по-умолчанию. Тогда будет вообще одно состояние, будет удобно делать проверки и будет иметь четкий и единственный смысл.
J. Snow, например, регистрируется пользователь и у него есть какие-то дополнительные поля в личном кабинете, которые он может потом заполнить. Изначально, эти поля будут NULL. После того, как он решит их изменить, то те поля, что он оставит пустыми будут ''(пустая строка). Таким образом, у нас есть возможность проверять, либо поля еще не заполнены, либо они уже заполнены и пользователь ничего в них не ввел. Не часто, но бывают случаи, когда нам нужно знать, заполнял ли вообще пользователь поля или нет.
Как-то так. Это первое, что в голову пришло.
Иван Шумов, я тут уже думаю, что может быть проще было бы сделать не цепочку сервисов, когда из одного сервиса происходит запрос в другой сервис, а просто делать в лоб - получил данные с одного сервиса, отправил в другой, получил из другого, отправил в третий
Иван Шумов, грубо говоря, я просто пытаюсь сделать обычное получение/сохранение данных внутри системы, где есть цепочка из микросервисов.
- доступность. могут быть или вообще недоступны, либо уходить в таймаут, если ответ не получен в течении нескольких секунд
- сколько доступа съедят ошибки. в корне дерева очередей ждать, пока выполнятся все дочерние очереди либо не будет фейла одной из важной очереди. если я помечаю в header'e очереди, что она должна быть "required" и она фейлится, то реджектить всё дерево очередей и сообщать об этом всему дереву. только надо посмотреть в мануале rabbitmq, могу ли я сделать reject, если уже выполнился consume
- мой план на реджект очереди. если база данных, то у меня в event sourcing'е есть специальная nosql таблица для транзакционных ивентов. я там сохраняю ивенты, которые потом копируются в основную таблицу с ивентами, если успешно выполнились записи в мускуль или какие-то другие операции. если произошла какая-то ошибка, то данные просто остаются в транзакционной таблице и никуда дальше не идут
Иван Шумов, мне в принципе в обычном дереве запросов микросервисов не особо нужна consistency, мне важно availability и tolerance. Риски по идее должны быть, если бы я делал замкнутую цепочку из систем, когда от результатов нижестоящей очереди зависит работа вышестоящей. А так, мне важно только знать, в каком availability сейчас находятся сервисы.
Иван Шумов, я понимаю, что есть CAP теорема и всё такое, но как-то же нужно понимать остальным микросервисам в цепочке, что в одном из микросервисов произошел сбой? Вот и зацепился за MQ в попытке как-то решить этот вопрос. Возможно, этот вариант не совсем правильный и есть какие-то правильные решения... Просто не хочу делать еще один сервис над сервисами, который будет выполнять эту работу. Хотелось бы сделать каждый сервис более-менее самостоятельным.
Для краткости иногда пишу сервис, вместо микросервиса.
Иван Шумов, я надеюсь, что если делать через RPC, то сообщения не должны застревать и будут сами тут же отваливаться, если произошел какой-то фейл или вышел таймаут. Мне нужно будет только reject обработать и всё=) И по поводу exponential backoff и exponential retry - такого не будет, т.к. мне нужно кровь из носа получать результат прямо здесь и сейчас и как можно быстрее давать ответ пользователю.
Спасибо за подсказки. Значит, я двигаюсь примерно в правильном направлении:D
До облаков пока что не дорос=)
Я планировал оркестрацию делать в самом RabbitMQ через federated exchanges. Если в exchange дереве падает одна из очередей, то посылать другим очередям сигнал о том, что нужно остановиться и сделать rollback. Только что делать с левыми сервисами, которые нужны, но они где-то крутятся на стороне и к ним есть доступ только через API?
⚡ Kotobotov ⚡, я не совсем понял, что у них подразумевается под State. У меня сейчас так работает команда вызывает хандлер -> хандлер формирует состояние аггрегата -> измененные состояние аггрегата сохраняются в even store в виде ивентов -> потом есть проектор, в котором висят отдельные процессы в фоне, которые слушают измения в ивент сторе и при появлении новых ивентов проецирует их в нормализованную ДБ
Возможно, можно что-то улучшить...
⚡ Kotobotov ⚡, нету "командного сурсинга", как и нету "квери сурсинга", есть только ивент сурсинг=) Я тут вообщем немного поразмыслил и пришел к такой идее. Нужно сделать для транзакционных ивентов отдельный стрим. Все ивенты, которые могут подвергаться коллизии изначально сохранять туда, если эксепшина никакого нет при сохранении в нормализованную БД, то как-то делать линк этого события в основной стрим. Если же эксепшин есть, то эти ивенты так и будут оставаться в стриме для транзакции, никуда не будут вылазить и без разницы, какое количество невалидных ивентов создалось. Как-то так. Нужно пробывать.
Дело в том, что я не могу на прямую создавать в нормализованной базе данных пользователя, этим должен заниматься исключительно проектор(т.к. эта база исключительно для чтения). Я могу только проверить, что содержится или нет в ней такая запись. Да и к тому же, похожих моментов с коллизией обычно очень много в проектах случается и из-за этого код очень пованивать начинает...
P.S. Забыл еще добавить, что вся логика ES строится на том, что нам первичнее сохранить ивент, чем сохранить запись в нормализованную БД, т.к. если накроется последняя, то мы быстренько сможем из ивентов восстановить исходную БД, чего не сможем сделать, если накроется база с ивентами.
