Съвременните финансови институции обработват милиони сделки всеки ден, а основната инфраструктура, която поддържа този обем, трябва да бъде бърза, толерантна към грешки и точна до микросекунди. През последните няколко години, архитектурата, базирана на събития, се появи като доминиращ модел за изграждане на тези системи, а Apache Kafka се превърна в гръбнака на много критични за мисията тръбопроводи за обработка на търговия. Why Event-Driven Architecture for Trade Processing Защо Архитектура на събития за обработка на търговия Традиционните системи за търсене и отговор се борят, за да отговорят на изискванията за закъснение и пропуск на капиталовите пазари. Една търговия с акции, от подаването на поръчка до потвърждаване на разплащането, преминава през системи за управление на поръчки, двигатели за рискове, обменни портали, клирингови къщи и проверяващи за съответствие. Архитектурата, ръководена от събития, решава това, като напълно разделя производителите и потребителите.Когато се подаде поръчка, системата издава събитие.Долупосочените услуги като валидиране на риска, проверки за съответствие преди търговията и калкулатори за позиция консумират това събитие независимо и в собствения си темп.Резултатът е система, която скалира хоризонтално, грациозно изолира неуспехите и осигурява постоянна аудиторска следа, която регулаторите все повече очакват. Kafka as the Central Nervous System Кафка като централна нервна система Apache Kafka естествено се вписва в този модел, защото е проектиран точно за високопропускливо, трайно, поръчано излъчване на събития. В типичен търговски тръбопровод моделираме всеки етап от жизнения цикъл на търговията като отделна тема на Kafka: order.submitted, order.validated, order.routed, trade.executed, trade.confirmed и settlement.initiated. Всяка тема представлява различен преход на държавата, а услугите се абонират само за теми, свързани с тяхната функция. Един от най-важните дизайнерски решения е стратегията за разделяне. За търговските системи разделянето по идентификатор на инструмент или идентификатор на акаунт гарантира, че всички събития за дадена сигурност или клиент пристигат за същия потребителски екземпляр. Това е от огромно значение за проследяването на позициите, където обработката извън поръчката може да доведе до неправилни нетни експозиции. Използването на сгъстена тема за състояние на позицията позволява на потребителите да възстановят текущите позиции от дневника на събитията, без да сканират цялата история при стартиране. Building for Resilience: Idempotency and Exactly-Once Semantics Изграждане за устойчивост: Idempotency и точно веднъж семантика Един от най-трудните проблеми в системите за разпределена търговия е да се гарантира, че една търговия се обработва точно веднъж. мрежови раздели, потребителски сривове и избори за лидер на брокера могат да причинят изпращането на съобщения.Ако услугата за обработка на търговия не е ефективна, дублирано съобщение може да доведе до двойно резервиране, неправилно P&L или неуспешни инструкции за сетълмент. Семантиката на Кафка, въведена чрез транзакционния продуцентски API, се занимава с това в слоя на съобщението. Чрез позволяване на потенциални продуценти и опаковане на логиката на потребление-трансформиране-производство в транзакциите, можем да гарантираме атомни писма в множество партиции и теми. На практика това означава опаковане на четенето от входяща тема, бизнес логиката и писането в изходяща тема в рамките на една Kafka транзакция. Ако някоя част от това се провали, цялата операция се върти назад и няма частично състояние, което да се вижда надолу. На нивото на приложението, ние прилагаме idempotency, като присвояваме глобално уникален търговски идентификатор при започване на поръчката и го използваме като ключ за deduplication през целия тръбопровод.Всяка услуга поддържа локален кеш или магазин за бързи ключови стойности с наскоро обработени търговски идентификатори и всеки дубликат се изхвърля, преди бизнес логиката да изпълни.Този двуслоен подход, транзакции на ниво Kafka плюс deduplication на ниво приложение, осигурява задълбочена защита срещу най-често срещаните сценарии за неуспех. Schema Management and Contract Stability Управление на схемите и стабилност на договорите В мулти екипна среда, където различните групи притежават различни потребители, стабилността на схемата се превръща в значителна оперативна загриженост. Ако схемата на събитието се промени без предизвестие, потребителите надолу по веригата прекъсват. Ние се справяме с това с помощта на Confluent Schema Registry с Avro схеми и налагане на проверки за съвместимост назад и напред като част от тръбопровода CI/CD. Не може да се разгърне промяна на схемата, освен ако не премине валидиране на съвместимостта, което предотвратява мълчаливо прекъсване на промените, които са общи в системи, базирани на JSON. За финансово чувствителни полета като цена, количество и номинална стойност, ние използваме десетични изображения с фиксирана точка, а не плаващи точки.Това елиминира закръгляването на грешките, които се натрупват в хиляди сделки и гарантира, че една и съща цифрова стойност означава едно и също нещо за всеки потребител в тръбопровода, независимо от езика на програмиране или средата за изпълнение. Operational Patterns: Dead Letter Queues and Circuit Breakers Оперативни модели: опашки с мъртви букви и прекъсвачи на вериги Дори при силни договори и транзакционна семантика, ще пристигнат неочаквани съобщения. Пазарно предаване на данни може да доведе до деформирана цена. Системата на контрагента може да изпрати потвърждение за търговия с липсващо изисквано поле. Използваме модел на опашка с мъртви букви, при който всяко съобщение, което не може да бъде обработено след конфигурируем брой повторения, се маршрутизира към специална тема, обикновено наречена със суфикс .dlq. Системата за предупреждение наблюдава закъснението на DLQ и незабавно уведомява екипа по повикване. Всяко съобщение за DLQ е обогатено с оригиналната тема, разделяне, компенсиране, проследяване на изключенията и времева марка, преди да бъде препратено, което прави дебагирането значително по-бързо. За външни повиквания към услуги в рамките на потребителите, като например повиквания към услуга за ценообразуване или API за референтни данни, прилагаме прекъсвачи на вериги, като използваме библиотека като Resilience4j. Ако външна услуга започне да се проваля, прекъсвачът на вериги се отваря и потребителят се връща към кеширана или стандартна стойност, вместо да блокира за неопределено време. Monitoring and Observability in Production Мониторинг и наблюдение в производството Основният показател за здравето на търговския тръбопровод, базиран на Kafka, е закъснението на потребителската група, което измерва колко далеч е групата на потребителите от главата на всеки раздел. Ние излагаме закъсненията на всички потребителски групи в централна система за мониторинг и предупреждаваме, когато закъснението надвишава праговете, калибрирани спрямо очакваната скорост на обработка на всяка услуга. Рисковият двигател, който обикновено поддържа под-вторично закъснение, трябва да задейства предупреждение, ако закъснението се покачи над пет секунди, защото този праг пряко засяга точността на рисковите позиции в реално време. Разпределеното проследяване с OpenTelemetry ни позволява да визуализираме пълното пътуване на една търговия през услугите, което е безценно за идентифицирането на бутилирани затруднения.На практика най-големите сътрудници на закъснението обикновено са базите данни и синхронните външни обаждания, а не самата Кафка. Looking Ahead Гледайки напред Архитектурите, базирани на събития, изградени върху Кафка, се оказаха силна основа за обработката на финансовата търговия, но описаните тук модели изискват инвестиции в оперативна дисциплина, управление на схеми и инструменти за наблюдение, за да работят добре на практика. Тъй като финансовите фирми се придвижват към модели за сетълмент в реално време и все по-сложни регулаторни изисквания за отчитане, способността за възпроизвеждане, одит и селективно преработване на потоците от събития става още по-ценна.
