Moderní finanční instituce každý den zpracovávají miliony obchodů a podkladová infrastruktura, která tento objem podporuje, musí být rychlá, odolná vůči chybám a přesná až do mikrosekundy.V posledních několika letech vznikla architektura založená na událostech jako dominantní vzor pro budování těchto systémů a Apache Kafka se stala páteří mnoha kritických obchodních zpracovatelských potrubí.Tento příspěvek prochází základními architektonickými rozhodnutími, technickými vzorci a provozními lekcemi, které jsem shromáždil při práci na vysoce výkonných obchodních systémech ve výrobních prostředích. Why Event-Driven Architecture for Trade Processing Proč Architektura řízená událostmi pro zpracování obchodu Tradiční systémy poptávky-odpovědi bojují za splnění požadavků na latenci a průtok na kapitálových trzích. Jediný obchod s akciemi, od podání objednávky po potvrzení vypořádání, prochází systémy řízení objednávek, rizikovými motory, směnnými bránami, clearingovými domy a kontrolami dodržování předpisů. Každý hop zavádí latenci a každý synchronní řetězec hovorů vytváří křehký závislostní graf, kde jedna pomalá složka blokuje celý tok. Architektura založená na událostech to řeší tím, že zcela odpojí producenty a spotřebitele. Když je podána objednávka, systém vydává událost. Downstreamové služby, jako je ověřování rizik, kontroly před obchodováním a poziční kalkulačky, tuto událost každý spotřebují nezávisle a svým vlastním tempem. Výsledkem je systém, který se měří horizontálně, elegantně izoluje selhání a poskytuje trvalou auditní stopu, kterou regulační orgány stále více očekávají. Kafka as the Central Nervous System Kafka jako centrální nervový systém Apache Kafka se přirozeně hodí do tohoto modelu, protože byl navržen přesně pro vysoce výkonný, trvanlivý, objednaný přenos událostí.V typickém obchodním potrubí modelujeme každou fázi životního cyklu obchodu jako samostatné téma Kafky: order.submitted, order.validated, order.routed, trade.executed, trade.confirmed a settlement.initiated. Každé téma představuje odlišný přechod stavu a služby se přihlásí pouze k tématům relevantním pro jejich funkci. Jednou z nejdůležitějších voleb designu je strategie rozdělení. Pro obchodní systémy, rozdělení podle identifikátoru nástroje nebo identifikátoru účtu zajišťuje, že všechny události pro dané zabezpečení nebo klienta dorazí do stejného spotřebitelského případu. To je nesmírně důležité pro sledování pozic, kde zpracování mimo objednávku může produkovat nesprávné čisté expozice. Použití komprimovaného tématu pro stav pozice umožňuje spotřebitelům rekonstruovat aktuální pozice z deníku událostí bez skenování celé historie na spuštění. Building for Resilience: Idempotency and Exactly-Once Semantics Budování pro odolnost: Idempotency a Exactly-Once Semantics Jedním z obtížnějších problémů v distribuovaných obchodních systémech je zaručit, že obchod je zpracován přesně jednou. síťové rozdělení, selhání spotřebitelů a volby vedoucích makléřů mohou způsobit, že se zprávy znovu doručí.Pokud není služba zpracování obchodu idempotentní, duplicitní zpráva může mít za následek dvojí rezervace, nesprávné P&L nebo neúspěšné pokyny k vypořádání. Kafkovou semantikou přesně jednou, zavedenou prostřednictvím API transakčního producenta, se toto řeší na komunikační vrstvě. Umožněním idempotentních producentů a zabalením konzumní-transformační-produkční logiky v transakcích můžeme zaručit atomové psaní na více oddílech a tématech. V praxi to znamená zabalení čtení z vstupního tématu, obchodní logiky a psaní do výstupního tématu v rámci jedné Kafkovy transakce. Pokud některá část tohoto selže, celá operace se vrátí zpět a žádný částečný stav není viditelný dolů. V aplikační vrstvě uplatňujeme idempotenci tím, že při zahájení objednávky přiřazujeme globálně jedinečný obchodní identifikátor a používáme jej jako klíč ke zdvojování po celém potrubí.Každá služba udržuje místní vyrovnávací paměť nebo úložiště rychlé klíčové hodnoty s nedávno zpracovanými obchodními identifikátory a jakýkoli duplikát je před provedením obchodní logiky opuštěn.Tento dvoustupňový přístup, transakce na úrovni Kafky plus deduplikace na úrovni aplikace, poskytuje hlubokou obranu proti nejběžnějším neúspěšným scénářům. Schema Management and Contract Stability Řízení schémat a stabilita smluv V prostředí s více týmy, kde různé skupiny vlastní různé spotřebitele, se stabilita schématu stává významným provozním problémem. Pokud se schéma událostí, které byly předloženy, změní bez předchozího upozornění, následní spotřebitelé přeruší. Toto řešíme pomocí registru Confluent Schema s schématy Avro a vynucováním kontrol zpětné a přední kompatibility jako součásti potrubí CI/CD. Žádná změna schématu nemůže být nasazena, pokud neprojde ověřením kompatibility, což zabraňuje tichým změnám, které jsou běžné v systémech založených na JSON. U finančně citlivých polí, jako je cena, množství a noční hodnota, používáme desetinové zastoupení pevných bodů namísto typů plovoucích bodů.Tím se eliminují zaokrouhlovací chyby, které se hromadí v tisících obchodů a zajišťuje, že stejná číselná hodnota znamená stejnou věc pro každého spotřebitele v potrubí, bez ohledu na programovací jazyk nebo prostředí běhu. Operational Patterns: Dead Letter Queues and Circuit Breakers Operační vzory: Dead Letter Queues a Circuit Breakers Dokonce i se silnými smlouvami a obchodní semantikou přijdou neočekávané zprávy. Tržní datový zdroj může produkovat deformovanou cenu. Systém protistrany může poslat potvrzení obchodu s chybějícím požadovaným polem. Bez strukturovaného způsobu, jak se s těmito výjimkami vypořádat, může jediná špatná zpráva zablokovat celý oddíl po celé hodiny, zatímco spotřebitel opakovaně selže a vrací se. Používáme vzorec mrtvého listu, kde jakákoli zpráva, která selže při zpracování po konfigurovatelném počtu retrií, je přesměrována na vyhrazené téma, obvykle pojmenované příponou .dlq. Varovný systém monitoruje zpoždění DLQ a okamžitě informuje tým na volání. Každá zpráva DLQ je obohacená o původní téma, oddíly, kompenzace, stopy výjimek a časovou značku předtím, než je předána, což činí debugování výrazně rychlejším. Pro externí servisní volání uvnitř spotřebitelů, jako jsou volání k cenové službě nebo referenčnímu datovému rozhraní API, implementujeme přerušovače pomocí knihovny, jako je Resilience4j. Pokud vnější služba začne selhat, přerušovač se otevře a spotřebitel se vrátí k vyrovnané nebo výchozí hodnotě spíše než k blokování na dobu neurčitou. Monitoring and Observability in Production Monitorování a sledovatelnost ve výrobě Primární metrikou zdraví pro obchodní potrubí založené na Kafce je zpoždění skupin spotřebitelů, které měří, jak daleko je skupina spotřebitelů za hlavou každé partice. Metriku zpoždění ze všech skupin spotřebitelů vystavujeme do centrálního monitorovacího systému a upozorňujeme, když zpoždění překročí prahové hodnoty kalibrované proti očekávané rychlosti zpracování každé služby. Rizikový motor, který obvykle udržuje podsekundární zpoždění, by měl spustit upozornění, pokud zpoždění stoupne nad pět sekund, protože tato mezera přímo ovlivňuje přesnost rizikových pozic v reálném čase. Rozdělené sledování s OpenTelemetry nám umožňuje vizualizovat celou cestu jednoho obchodu přes služby, což je neocenitelné pro identifikaci mezer.V praxi jsou největšími přispěvateli latence obvykle databáze psaní a synchronní externí hovory, nikoliv samotná Kafka. Looking Ahead Pohled dopředu Architektury založené na událostech postavené na Kafce se ukázaly jako silný základ pro zpracování finančního obchodu, ale zde popsané vzory vyžadují investice do provozní disciplíny, řízení schémat a nástrojů pozorovatelnosti, aby fungovaly dobře v praxi. Jak finanční firmy přecházejí k modelům vypořádání v reálném čase a stále složitějším regulačním požadavkům na podávání zpráv, schopnost opakovat, auditovat a selektivně přepracovávat toky událostí se stává ještě cennější.
