Jestem jednym z oryginalnych autorów Kafki. Kafka sprawdzi się bardzo dobrze jako log dla event sourcing. Jest odporny na błędy, skaluje się do ogromnych rozmiarów danych i ma wbudowany model partycjonowania.

Używamy go w kilku przypadkach użycia tego formularza na LinkedIn. Na przykład nasz system przetwarzania strumienia open source, Apache Samza, jest wyposażony w wbudowaną obsługę do pozyskiwania zdarzeń.

Myślę, że nie słychać wiele o użyciu Kafka dla event sourcing przede wszystkim dlatego, że wydarzenie terminologia pozyskiwania nie wydaje się być bardzo rozpowszechniona w konsumenckiej przestrzeni internetowej, gdzie Kafka jest najbardziej popularna.

Pisałem trochę o tym stylu użytkowania Kafki tutaj .

Możesz użyć Kafki jako event store, ale nie polecam tego robić, chociaż może to wyglądać na dobry wybór:

• Kafka gwarantuje tylko co najmniej raz dostawę i są duplikaty w magazynie zdarzeń, którego nie można usunąć. Aktualizacja: Tutaj możesz przeczytać, dlaczego jest tak ciężko z Kafką i kilka najnowszych wiadomości o tym, jak w końcu osiągnąć to zachowanie: https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/
• Due aby niezmienność, nie ma sposobu na manipulowanie magazynem zdarzeń, gdy aplikacja ewoluuje i zdarzenia muszą zostać przekształcone (istnieją oczywiście metody takie jak upcasting, ale...). Kiedyś można powiedzieć, że nigdy nie trzeba przekształcać zdarzeń, ale to nie jest prawidłowe założenie, może być sytuacja, w której robisz kopię zapasową oryginału, ale uaktualniasz je do najnowszych wersji. Jest to ważne Wymaganie w architekturach opartych na zdarzeniach.
• Brak miejsca na utrwalanie migawek podmiotów/agregatów i odtwarzanie będzie stawaj się wolniejszy i wolniejszy. Tworzenie migawek jest obowiązkowe dla magazynu zdarzeń z perspektywy długoterminowej.
• biorąc pod uwagę, że partycje Kafki są rozproszone i są trudne do zarządzania i kopia zapasowa porównaj z bazami danych. Bazy danych są po prostu prostsze: -)

Więc zanim dokonasz wyboru, zastanów się dwa razy. Event store jako połączenie interfejsów warstwy aplikacji( monitorowanie i zarządzanie), SQL / NoSQL store i Kafka jako broker jest lepszym Wyborem niż pozostawienie Kafka obsługuje obie role stwórz pełne rozwiązanie funkcji.

Event store jest kompleksową usługą, która wymaga więcej niż to, co Kafka może zaoferować, jeśli poważnie myślisz o stosowaniu Event sourcing, CQRS, Sagas i innych wzorców w architekturze opartej na zdarzeniach i pozostań wysokiej wydajności.

Zapraszam do kwestionowania mojej odpowiedzi! możesz nie lubić tego, co mówię o Twoim ulubionym brokerze z wieloma nakładającymi się możliwościami, ale mimo to Kafka nie została zaprojektowana jako sklep imprezowy, ale bardziej jako wysoka wydajność broker i bufor w tym samym czasie do obsługi szybkich producentów i powolnych konsumentów scenariuszy, na przykład.

Proszę spojrzeć na eventuate.io mikrousług open source framework, aby dowiedzieć się więcej o potencjalnych problemach: http://eventuate.io/

Aktualizacja od 8th Feb 2018

Nie włączam nowych informacji z komentarzy, ale Zgadzam się co do niektórych z tych aspektów. Ta aktualizacja zawiera więcej zaleceń dotyczących platformy sterowanej zdarzeniami mikrousług. Jeśli u pacjenta występuje poważne o mikroserwisie Solidna konstrukcja i najwyższa możliwa wydajność w ogóle podam kilka wskazówek, które mogą Cię zainteresować.

1. nie używaj sprężyny - jest świetna( sama często ją używam), ale jest ciężka i powolna jednocześnie. I wcale nie jest to platforma mikrousług. Jest to" tylko " framework, który pomoże Ci zaimplementować (wiele pracy za tym stoi..). Inne frameworki to" tylko " lekkie frameworki REST lub JPA lub inaczej skupione. Polecam chyba najlepszy w swojej klasie dostępna pełna platforma mikrousług open source, która wraca do czystych korzeni Javy: https://github.com/networknt

Jeśli zastanawiasz się nad wydajnością, możesz porównać się z istniejącym pakietem benchmark. https://github.com/networknt/microservices-framework-benchmark

1. W ogóle nie używaj Kafki : -)) to pół żart. Chociaż Kafka jest świetna, jest to kolejny system centryczny dla brokerów. Myślę, że przyszłość jest w komunikacji bez pośredników systemy. Możesz się dziwić, ale są szybsze niż systemy Kafki : -), oczywiście musisz zejść na niższy poziom. Spójrz na Chronicle.

2. Do przechowywania zdarzeń polecam doskonałe rozszerzenie Postgresql o nazwie TimescaleDB, które koncentruje się na wysokiej wydajności przetwarzania danych timeseries (zdarzenia są timeseries) w dużych woluminach. Oczywiście CQRS, Event sourcing (powtórka itp. funkcje) są wbudowane w light4j framework out of the box, który wykorzystuje Postgres jako niski magazyn.

3. Dla wiadomości spróbuj spojrzeć na kolejkę Kroniki, mapę, Silnik, sieć. Mam na myśli pozbycie się tych staromodnych rozwiązań centrycznych i przejście z systemem mikro wiadomości (wbudowanym). Kolejka Kronik jest w rzeczywistości jeszcze szybsza niż Kafka. Ale Zgadzam się, że nie jest to wszystko w jednym rozwiązaniu i trzeba zrobić trochę rozwoju inaczej idziesz i kupić wersję Enterprise(płatną). W końcu wysiłek zbudowania z własnej warstwy komunikatora zostanie opłacony przez usunięcie ciężaru utrzymania gromady Kafki.

ciągle wracam do tego QA. I nie znalazłem istniejących odpowiedzi wystarczająco niuansowe, więc dodaję tę.

TL;DR tak lub nie, w zależności od wykorzystania źródła wydarzenia.

Istnieją dwa podstawowe rodzaje systemów pozyskiwania zdarzeń, o których wiem.

Downstream event processors = Yes

W tego typu systemie zdarzenia dzieją się w świecie rzeczywistym i są zapisywane jako fakty. Takich jak system magazynowy do śledzenia palet produktów. Są zasadniczo żadnych sprzecznych wydarzeń. Wszystko już się wydarzyło, nawet jeśli było złe. (Tj. paleta 123456 umieścić na ciężarówce A, ale został zaplanowany na ciężarówce B.) następnie później fakty są sprawdzane pod kątem WYJĄTKÓW za pomocą mechanizmów raportowania. Kafka wydaje się dobrze przystosowana do tego rodzaju aplikacji przetwarzania zdarzeń w dół strumienia.

W tym kontekście jest zrozumiałe, dlaczego ludzie Kafka opowiadają się za nim jako rozwiązaniem pozyskiwania wydarzeń. Ponieważ jest bardzo podobny do tego, jak jest już stosowany np. w, kliknij strumienie. Jednak osoby używające terminu Event Sourcing (w przeciwieństwie do przetwarzania strumieniowego) prawdopodobnie odnoszą się do drugiego użycia...

Kontrolowane przez aplikację źródło prawdy = Nie

Ten rodzaj aplikacji deklaruje własne zdarzenia w wyniku żądania użytkownika przechodzącego przez logikę biznesową. Kafka nie działa dobrze w tym przypadku z dwóch podstawowych powodów.

Brak izolacji bytu

Ten scenariusz wymaga możliwości załadowania strumienia zdarzeń dla określonego / align = "left" / Częstym powodem tego jest zbudowanie przejściowego modelu zapisu dla logiki biznesowej do przetworzenia żądania. Robienie tego w Kafce jest niepraktyczne. Użycie topic-per-entity może na to pozwolić, z wyjątkiem tego, że jest to nie-starter, gdy mogą istnieć tysiące lub miliony tego podmiotu. Wynika to z ograniczeń technicznych w Kafka / Zookeeper. Użycie topic-per-type jest zalecane zamiast Dla Kafki, ale wymagałoby to załadowania zdarzeń dla każdego encji tego typu tylko po to, aby uzyskać zdarzenia dla jedna istota. Ponieważ nie można stwierdzić po pozycji dziennika, które zdarzenia należą do której jednostki. Nawet przy użyciu migawek , aby rozpocząć od znanej pozycji dziennika, może to być znaczna liczba zdarzeń do przewinięcia. Ale migawki nie mogą pomóc w zmianie kodu. Ponieważ dodanie nowych funkcji do logiki biznesowej może spowodować strukturalną niekompatybilność poprzednich migawek. Tak więc nadal konieczne jest powtórzenie tematu w tych przypadkach, aby zbudować nowy model. Jednym z głównych powodów korzystania z transient write model zamiast persisted jeden jest, aby zmiany logiki biznesowej tanie i łatwe do wdrożenia.

Brak wykrywania konfliktów

Po drugie, użytkownicy mogą tworzyć warunki rasowe z powodu równoczesnych żądań przeciwko temu samemu podmiotowi. Może to być dość niepożądane, aby zapisać sprzeczne wydarzenia i rozwiązać je po fakcie. Dlatego ważne jest, aby móc zapobiegać sprzecznym wydarzeniom. Aby skalować obciążenie żądań, powszechne jest korzystanie z usług bezstanowych, zapobiegając konfliktom zapisu użycie zapisu warunkowego (zapis tylko jeśli ostatnim zdarzeniem encji było #x). / Align = "center" bgcolor = "# e0ffe0 " / cesarz chin / / align = center / Kafka nie popiera optymistycznej współbieżności. Nawet gdyby wspierał go na poziomie tematu, musiałby być aż do poziomu podmiotu, aby był skuteczny. Aby korzystać z Kafki i zapobiegać konfliktom, należy użyć stateful, serialized writer na poziomie aplikacji. Jest to istotne Wymaganie/ograniczenie architektoniczne.

Dalsze informacje

Update per comment

To było zbyt duże, aby zmieścić się w komentarzu. Wydaje się, że większość ludzi tworzy własną implementację magazynu zdarzeń na bazie istniejącej bazy danych. W przypadku scenariuszy nieeksploatowanych, takich jak wewnętrzne back-endy lub samodzielne produkty, jest dobrze udokumentowane Jak utworzyć magazyn zdarzeń oparty na SQL. I istnieją biblioteki dostępne na szczycie różnego rodzaju baz danych. Istnieje również EventStore, który jest zbudowany do tego cel.

W scenariuszach rozproszonych widziałem kilka różnych implementacji. Jet ' S Panther project używa usługi Azure CosmosDB, z funkcją Change Feed do powiadamiania słuchaczy. Inną podobną implementacją, o której słyszałem na AWS, jest używanie DynamoDB z funkcją Streams do powiadamiania słuchaczy. Kluczem partycji prawdopodobnie powinien być stream id dla najlepszej dystrybucji danych (aby zmniejszyć ilość nadmiarowej alokacji). Jednak pełna Powtórka na żywo w Dynamo jest drogie (czytane i kosztowne). Więc ten impl był również ustawiony dla strumieni Dynamo do zrzucania zdarzeń do S3. Gdy nowy słuchacz przychodzi online lub istniejący chce pełnej powtórki, czyta S3, aby nadrobić zaległości.

Mój obecny projekt jest scenariuszem multi-tenant, A ja założyłem swój własny na Postgres. Coś takiego jak Citus wydaje się odpowiednie dla skalowalności, partycjonowanie przez tentant + stream.

Kafka jest nadal bardzo przydatna w scenariuszach rozproszonych. Nietrywialnym problemem jest ujawniać zdarzenia każdej usługi innym usługom. Sklep eventowy nie jest zbudowany do tego zazwyczaj, ale to właśnie Kafka robi dobrze. Każda usługa ma swoje wewnętrzne źródło prawdy( może być magazynem zdarzeń lub w inny sposób), ale słucha Kafki, aby wiedzieć, co się dzieje "na zewnątrz". Zespół może również wysyłać swoje wydarzenia serwisowe do Kafki, aby poinformować "Zewnątrz" o ciekawych rzeczach, które zrobił serwis.

Tak, możesz używać Kafki jako sklepu z wydarzeniami. Działa całkiem dobrze, zwłaszcza z wprowadzeniem Kafka Streams, który zapewnia Kafka-natywny sposób przetwarzania zdarzeń do nagromadzonego stanu, który można odpytywać .

Odnośnie:

Możliwość powtórzenia eventlog, który pozwala nowym subskrybentom zarejestrować się w systemie po fakcie.

To może być trudne. Omówiłem to szczegółowo tutaj: https://stackoverflow.com/a/48482974/741970