JMS bridge или не

Сървърите за които говоря предоставят api към бизнес логиката на приложението (тая част от комуникацията не я коментираме - гол restful в комбинация с broadcast нотификации за събития). Локалните сървъри имплементират бизнес логиката нужна в конкретен обект а централния сървър имплементира логика на централно ниво. С други думи, имаме два (типа) различни сървъра които трябва да комуникират надеждно по между си.

Тук идват брокерите на съобщения.

Употребата на брокер с имплементация на JMS позволява лесно създаване на асинхронна логика за обработка на сървърите. Единия сървър изпраща задача на другия. Той я обработва и евентуално връща резултат. И точно тая комуникация трябва да работи надеждно при липса на връзка между сървърите.
Демек, сървър А изпраща задача на сървър В, но липсва свързаност между двата. Какво правим? Или сървър В е изпълнил някаква задача и връща отговор, но липсва връзката.

Точно тоя проблем се опитвам да изчистя като решение.

Единия вариант е да се ползва стнадртния интерфейс на брокерите и да си обработвам изключенията при липса на свързаност. Другия вариант е да накарам брокерите да се оправят сами с детайлите. Мостовете решават точно тоя проблем. предложението на Lachezar за клъстер изглежда, че също го решава. В предложения от теб брокер гледам, че има функция за репликация която май също върши работа.

А иначе, персистентността на съобщенията си е едно на ръка. Но тя решава проблеми свързани със срив на конкретен сървър които биха довели до загуба на получени но необработени съобщения.

---
Тоя проект все още го обмислям, така че нищо в него не е твърдо зададено.
Тая седмица ще правя тестови постановки на различните решения за да ги видя как се сетъпват и държат в проблемните сценарии.

Това

и това, което каза Лъчезар не са ли едно и също нещо? Имаш трето звено(middleware), което обработва съобщенията и се грижи да ги изпраща на централния сървър? Което не усложнява ли отново конфигурацията (това, което теб те притеснява)?

Трябва да помислиш и какво да правиш, ако се прецака локалната връзка (с презумпцията, че локалния сървър е на отделна машина на обекта).

Колкото до конфигурацията на опашки - до колко усложнява конфигурацията? И като цяло има ли нужда всяка двойка сървъри да е на отделна опашка?

съобщението се прави durable докато бъде acknowledged. В този ред на мисли ще се наложи да се погрижиш консуматора на съобщенията да е idempotent.
https://microservices.io/patterns/communica...t-consumer.html

Клъстеризацията на приложението ще съзададе равноправни логически възли които ще се държат като един мнолитен обект.

При мостът (и евентуалното решение с репликация). Се свързват само само брокерите (по двойки). Като тук се запазва ерархията.

Клъстеризацията ми се струва, че е по-удачна когато се гони оптимизация на натоварване а това което на мен ми трябва се явява страничен ефект.
При мостът (репликацията) се получава само това което ми трябва, но се изисква ръчно създаване на оделните двойки от опашки (може би, ще е по-проблемно, тъй като отваря поле за грешка)

Иначе, разбирасе, че ще се отработи вариант с дублаж на съобщения (където се налага) но и брокерите си имат политики за това. Така че, това са детайли които не са ит значение на тоя етап.
Относно локалните проблеми, в повечето случаи се ползват резервни станции/сървъри, защото в конкретен обект можеш да реагираш.

Deduplicate на съобщения, автоматичен или ръчен acknowledge, durable consumer/subscriber, persistence на стрийма по който текат съобщенията, всичко наготово ти дава Nats с Jetstream но не искаш да експериментираш. Мога да ти помогна ако искаш.

@marquez, защо реши, че не искам да експериментирам? Точно това ще правя - голи тестови постановки с всичко предложено до сега. Но пак подчертавам, проблемът не е в четенето на съобщенията а в подаването им (към недостъпна дестинация).

Това мнение е било редактирано от thrawn на 28-06-2023, 06:08

Може би разбирането ми куца, но клъстеризацията не означава ли, че ще имаш отделни инстанции на централния сървър, който ще е в клъстер с един локален сървър? Де факто един централен сървър за един (или много локални на един обект) сървър?

Усложняването не е ли същото като при дефиниране на нов сет опашки за всеки нов локален сървър?

Нямам много какво да добавя по темата като идеи, но ми е интересно от имплементационна гледна точка как работи.

Клъстер са няколко инстанции работещи като една. С други думи, във всеки обект ще има локален възел на централния сървър (от гледна точка на потребителите в обекта, сървърът си е локален). Това води до автоматичното отпадане на понятието "локален сървър" в контекста в който го коментирахме до сега (не е задължително, но ми се струва, че става излишно да се фрагментита бизнес логиката в отделни приложения при такава архитектура).

Конфигурацията тук ще се свежда до добавяне на възли в клъстерът (не знам дали повече възли няма да му спънат работата)

При мостовете трябва да се създадът по две опашки (изпращане и получаване на данни) и да се направи мост между тях. Тук, не знам дали няма да мога да спестя едната опашка ако ползвам селектор.

С репликацията вече ще стане интересно как (дали) може да се постигне. Или пък там има друго решение

Има ли някой cloud provider който да продава NATS ? За моите нужди Redis върши чудесна работа и е по-евтин от алтернативите

Не мисля че има cloud provider но и няма нужда понеже е cloud native и може да се сетъпне навсякъде лесно.