Współczesne instytucje finansowe przetwarzają miliony transakcji każdego dnia, a podstawowa infrastruktura, która obsługuje tę objętość, musi być szybka, tolerująca błędy i dokładna do mikrosekundy. W ciągu ostatnich kilku lat architektura oparta na wydarzeniach pojawiła się jako dominujący wzorzec budowy tych systemów, a Apache Kafka stała się rdzeniem wielu krytycznych dla misji rurociągów przetwarzania handlu. Ten post przechodzi przez podstawowe decyzje architektoniczne, wzorce techniczne i lekcje operacyjne, które zgromadziłem pracując nad systemami handlowymi o dużej przepustowości w środowiskach produkcyjnych. Why Event-Driven Architecture for Trade Processing Dlaczego Architektura napędzana wydarzeniami dla przetwarzania handlu Tradycyjne systemy odpowiedzi na żądania zmagają się z spełnieniem wymogów opóźnienia i przepływu na rynkach kapitałowych. pojedynczy handel akcjami, od złożenia zamówienia do potwierdzenia rozliczenia, przechodzi przez systemy zarządzania zamówieniami, silniki ryzyka, bramy giełdowe, domy rozliczeniowe i kontrolery zgodności. Każdy skok wprowadza opóźnienie, a każdy synchroniczny łańcuch połączeń tworzy kruchy wykres zależności, w którym jeden powolny komponent blokuje cały przepływ. Architektura oparta na wydarzeniach rozwiązuje ten problem, całkowicie oddzielając producentów od konsumentów. Po złożeniu zamówienia system emituje zdarzenie. Usługi downstream, takie jak walidacja ryzyka, kontrole zgodności przed handlem i kalkulatory pozycji, zużywają to wydarzenie niezależnie i we własnym tempie. Kafka as the Central Nervous System Kafka jako centralny układ nerwowy Apache Kafka naturalnie pasuje do tego modelu, ponieważ został zaprojektowany dokładnie do strumieniowania wydarzeń o dużej przepustowości, trwałego, zorganizowanego.W typowym rurociągu handlowym modelujemy każdy etap cyklu życia handlu jako oddzielny temat Kafki: order.submitted, order.validated, order.routed, trade.executed, trade.confirmed i settlement.initiated. Każdy temat reprezentuje odrębny przejście stanu, a usługi subskrybują tylko tematy związane z ich funkcją. Jednym z najważniejszych wyborów projektowania jest strategia partycjonowania.W przypadku systemów handlowych partycjonowanie według identyfikatora instrumentu lub identyfikatora konta zapewnia, że wszystkie zdarzenia dla danego zabezpieczenia lub klienta przybywają do tego samego przypadku konsumenta.To ma ogromne znaczenie dla śledzenia pozycji, gdzie przetwarzanie poza zamówieniem może wywołać nieprawidłowe ekspozycje netto.Użycie sprężonego tematu dla stanu pozycji pozwala konsumentom odtworzyć bieżące pozycje z dziennika zdarzeń bez skanowania całej historii na start. Building for Resilience: Idempotency and Exactly-Once Semantics Budowanie odporności: Idempotencja i dokładnie raz semantyka Jednym z trudniejszych problemów w systemach handlu rozproszonego jest zagwarantowanie, że transakcja jest przetwarzana dokładnie raz. podziały sieciowe, awarii konsumentów i wybory liderów brokerów mogą spowodować, że wiadomości zostaną ponownie dostarczone. Semantyka Kafki, wprowadzona za pośrednictwem interfejsu API producenta transakcyjnego, zajmuje się tym w warstwie wiadomości. Umożliwiając idempotentnym producentom i pakując logikę konsumpcji-transformacji-produkcji w transakcjach, możemy zagwarantować pisanie atomowe na wielu partycjach i tematach. W praktyce oznacza to pakowanie czytania z tematu wejściowego, logiki biznesowej i pisania do tematu wyjściowego w ramach jednej transakcji Kafki. W warstwie aplikacji egzekwujemy idempotencję, przypisując globalnie unikalny identyfikator handlowy na początku zamówienia i używając go jako klucza deduplikacyjnego w całym rurociągu. Każda usługa utrzymuje lokalną pamięć podręczną lub szybki magazyn wartości klucza z niedawno przetworzonymi identyfikatorami handlowymi, a każdy duplikat zostaje usunięty przed wykonaniem logiki biznesowej. To podejście o dwóch warstwach, transakcje na poziomie Kafki plus deduplikacja na poziomie aplikacji, zapewnia głęboką obronę przed najczęstszymi scenariuszami awarii. Schema Management and Contract Stability Zarządzanie programami i stabilność kontraktów W środowisku z wieloma zespołami, w którym różne grupy posiadają różnych konsumentów, stabilność schematu staje się znaczącym problemem operacyjnym. Jeśli schemat zdarzenia złożonego z zamówieniem ulega zmianie bez powiadomienia, konsumenci w dalszym ciągu się rozpadają. Rozwiązujemy ten problem za pomocą rejestru Schematu Konfluencyjnego z schematami Avro oraz egzekwowaniem kontroli zgodności wstecznej i wstecznej w ramach rurociągu CI/CD. Żadna zmiana schematu nie może być wdrożona, chyba że przejdzie walidację zgodności, co zapobiega cichym zmianom, które są powszechne w systemach opartych na JSON. W przypadku obszarów wrażliwych pod względem finansowym, takich jak cena, ilość i wartość pojęciowa, używamy reprezentacji dziesiętnych w punktach stałych, a nie typów pływających punktów.To eliminuje błędy zaokrąglania, które gromadzą się w tysiącach transakcji i zapewnia, że ta sama wartość numeryczna oznacza to samo dla każdego konsumenta w rurociągu, niezależnie od języka programowania lub środowiska biegu. Operational Patterns: Dead Letter Queues and Circuit Breakers Wzory operacyjne: Dead Letter Queues i Circuit Breakers Nawet przy silnych umowach i semantyce transakcyjnej pojawią się nieoczekiwane wiadomości. Źródło danych rynkowych może wywołać wadliwą cenę. System kontrahenta może wysłać potwierdzenie handlu z brakującym wymaganym polem. Używamy wzorca kolejki martwej litery, w którym każda wiadomość, która nie jest przetwarzana po skonfigurowalnej liczbie powtórzeń, jest przekierowywana do dedykowanego tematu, zwykle nazwanego dodatkiem .dlq. System ostrzegawczy monitoruje opóźnienie DLQ i natychmiast powiadamia zespół dzwoniący. Każda wiadomość DLQ jest wzbogacona o oryginalny temat, partycję, kompensatę, śledzenie stosu wyjątków i znaczną prędkość czasu przed przekazaniem, co znacznie przyspiesza rozliczanie. W przypadku połączeń zewnętrznych usług wewnątrz konsumentów, takich jak połączenia z usługą cenową lub API danych referencyjnych, wdrażamy przełączniki za pomocą biblioteki, takiej jak Resilience4j. Jeśli usługa zewnętrzna zaczyna działać nieprawidłowo, przełącznik otwiera się, a konsument wraca do wartości w pamięci podręcznej lub domyślnej, zamiast blokowania na czas nieokreślony. Monitoring and Observability in Production Monitoring i obserwacja w produkcji Główną miarą zdrowia dla rurociągu handlowego opartego na Kafce jest opóźnienie grupy konsumentów, które mierzy, jak daleko grupa konsumentów znajduje się z tyłu głowy każdej partycji. Eksponujemy metryki opóźnienia ze wszystkich grup konsumentów do centralnego systemu monitorowania i ostrzegamy, gdy opóźnienie przekracza progi kalibrowane w stosunku do oczekiwanej prędkości przetwarzania każdej usługi. Silnik ryzyka, który normalnie utrzymuje opóźnienie podsekundowe, powinien wyzwalać ostrzeżenie, jeśli opóźnienie wzrasta powyżej pięciu sekund, ponieważ to opóźnienie bezpośrednio wpływa na dokładność pozycji ryzyka w czasie rzeczywistym. Śledzenie opóźnienia transakcji od końca do końca odbywa się poprzez stampowanie każdego zdarzenia z znacznikiem czasu tworzenia i mierzenie upływu czasu na każdym etapie. Rozproszone śledzenie z OpenTelemetry pozwala nam wizualizować pełną podróż pojedynczego handlu w ramach usług, co jest nieocenione dla identyfikacji barier. Looking Ahead Patrząc do przodu Architektury oparte na wydarzeniach zbudowane na Kafce okazały się silnym fundamentem dla przetwarzania transakcji finansowych, ale wzorce opisane tutaj wymagają inwestycji w dyscyplinę operacyjną, zarządzanie schematem i narzędzia obserwacji, aby działać dobrze w praktyce. Ponieważ firmy finansowe przechodzą w kierunku modeli rozliczeń w czasie rzeczywistym i coraz bardziej złożonych wymogów regulacyjnych, zdolność do odtwarzania, audytu i selektywnego ponownego przetwarzania strumieni zdarzeń staje się jeszcze bardziej cenna.
