WCF Pub/Sub z buforowaniem subskrybentów

Question

Problem: dostarczenie rozproszonego, skalowalnego i odpornego na awarie serwisu pub/sub z funkcją WCF.

Szczegóły:

Należy zauważyć, że takie podejście jest rozważane oprócz rozwiązań powiadamianie/middleware, takich jak Tibco EMS.

Zajmuję się WCF, w szczególności w jaki sposób może być stosowany do oferowania pub/sub. Na ten temat artykuł ten jest bardzo dobry: WCF pub-sub.

W artykule autor stara się rozwiązać problem posiadania wielu wydawców (tak jak w przypadku warstwy usługowej skalowanej na kilka pól). Problem polega na tym, że jeśli klient A rejestruje się z Wydawcą A, ale Wydawca B chce opublikować wydarzenie, wówczas wydawca B nie będzie wiedział o kliencie A. Oznacza to, że nikt nie powiedział wydawcy B, że klient A chciał zostać powiadomiony o zdarzeniach. Autor sugeruje rozwiązanie pub/sub jako rozwiązanie. Usługa pub/sub będzie centralnie przechowywać subskrypcje. Jednakże, jeśli chciałbym uczynić system pub/sub service odpornym na awarie przez posiadanie drugiego/podwójnego serwisu pub/sub, to mam ten sam pierwotny problem.

Tak, myślę, że istnieje kilka rozwiązań tego problemu:

1. dane abonenckie Przechowywać w rozproszonej pamięci podręcznej (patrz pytania: q1 i q2).
2. Przechowuj szczegóły subskrybenta w bazie danych/centralnym systemie plików.

ktoś może myśleć o jakichkolwiek innych rozwiązań (tzn ja nie zostały pominięte niektóre fantastyczne magiczną cechę WCF?) Wszelkie uwagi mile widziane.

Answer 1

Miałem ten sam problem i przeprowadziłem wiele badań w tej sprawie. Problem jest w rzeczywistości prosty. Chcesz zachować scentralizowany stan, ale w sposób rozproszony. Odkryłem, że najlepszym sposobem na osiągnięcie tego jest użycie rozproszonego bufora podręcznego. Popatrz na przykład na prędkość. Nie ma natywnego rozwiązania WCF, które znam, może rozwiązać problem zarządzania państwem. Zaglądałem nawet do usług trwałych, gdzie zarządzanie stanem jest obsługiwane przez WCF, jednak nie jest odpowiednie dla usługi pub/sub, ponieważ stan musi być scentralizowany dla wszystkich połączeń klientów. Przechowywanie danych w bazie danych jest również opcją, ale kosztem jest zapotrzebowanie na bazę danych, a nawet w przypadku bazy danych można mieć pojedynczy punkt awarii, jeśli baza danych nie jest klastrowana, co jest zgodne z wieloma komputerami.

Podejrzewałem, że jest naprawdę drogie, aby zaimplementować coś z zerowymi punktami awarii i jeśli zdecydujesz się tam pojechać, spójrz na Azure, przyszłość pamięci masowej będzie w chmurze, usługi Azure będą w pełni skalowalne i dystrybuowane, ale jeszcze nie jesteśmy.

Answer 2

Myślę, że WCF jeszcze tam nie jest. To, czego potrzebujesz, to broker, który zajmuje się tymi wszystkimi szczegółami, abyś mógł zaimplementować logikę biznesową. Jest kilka bardzo dobrych takich jak ActiveMQ. Jeśli potrzebujesz orkiestracji, prawdopodobnie będziesz chciał skorzystać z autobusu, który również może usiąść na brokerze. Uważam, że WCF jest cudowne, ale aby spróbować przekształcić go w coś, co nie jest, nie jest to dobry pomysł.