W serwisie A coś się zmienia w bazie. Serwisy zainteresowane konkretnym typem zmiany powinny zostać o tym powiadomione. Serwisów jest dużo i każdy zainteresowany powinien dostać notyfikację/trigger/cokolwiek co sprawi, że serwisy B, C, D itd. będą wiedziały, że coś się stało, najlepiej z jakimś danymi opisującymi co się zmieniło lub jaki jest aktualny stan.
Czego byście użyli? Myślałem o etcd albo jakichś kolejkach, ale sam już nie wiem.
Serwis A zmienia coś w bazie -> publikacja eventu na topic message brokera z użyciem outbox patternu -> każdy zainteresowany serwis konsumuje z topicu.
damianem napisał(a):
Serwis A zmienia coś w bazie -> publikacja eventu na topic message brokera z użyciem outbox patternu -> każdy zainteresowany serwis konsumuje z topicu.
Myślałem o tym, jakie widzę wady w porównaniu do takiego etcd:
Z wymagań to też nie potrzebuję super tranzakcyjności tj. jak ta sama informacja zostanie zaktualizowana jednocześnie kilka razy to nie ma problemu, że konsumenci dostaną tylko jedną wartość tj. najnowszą
Za bardzo też nie widzę zalet brokera poza tym, że postawienie etcd będzie trudniejsze (nie mam kubernetesa) a kolejkę już mam
Obczaj sobie jak robi się kolejkę wiadomości na Redisie jeśli tak bardzo chcesz iść w storage (etcd) do przechowywania wiadomości https://redis.com/solutions/use-cases/messaging/
A jeśli chodzi o publikację zmian/wiadomości to CDC za pomocą Debezium https://debezium.io/ jako alternatywa dla zdarzeń domenowych/integracyjnych. Ja tak obecnie integruję aplikacje legacy, dla których modyfikacje kodu są nieopłacalne lub czasem wręcz niemożliwe.
Q1) Kto to jest "każdy zainteresowany zmianami w A"?
Q2) Dlaczego te serwisy B,C,D mają wiedzieć, że coś się zmieniło w A? Zmiany w serwisie A chyba nie zachodzą same z siebie, tylko są wyzwalane przez jakąś aktywność? Coś woła A, to dlaczego miałoby nie wołać B,C,D?
yarel napisał(a):
Q1) Kto to jest "każdy zainteresowany zmianami w A"?
Q2) Dlaczego te serwisy B,C,D mają wiedzieć, że coś się zmieniło w A? Zmiany w serwisie A chyba nie zachodzą same z siebie, tylko są wyzwalane przez jakąś aktywność? Coś woła A, to dlaczego miałoby nie wołać B,C,D?
Serwis A odpowiada za konfigurację. Ta konfiguracja może się zmienić na różne sposoby, najczęściej jest to przeklikanie jakiegoś GUIa, Serwisy B, C itd. implementują pewien wspólny interfejs: każdy z nich jest odpowiedzialny za komunikację z innym zewnętrznym dostawcą. Dane o które mi chodzi to właśnie konfiguracja tych serwisów. Oczywiście wszystko jest bardziej skomplikowane, nie tylko te serwisy B, C itd. czytają te dane ale właśnie im najbardziej zależy, żeby te dane były aktualne
@slsy: zerknij na Apache Zookeepera. Wydaje mi się bardzo dobrze pasować do opisanego przypadku. No i masz tę hierarchię konfiguracji (możesz nasłuchiwać zmian w określonych ZNode'ach).