Комментарии 13
Хабр ещё нет-нет да и да. Отличное описание не просто принятых решений, но с пояснением почему именно они были приняты, каковы были альтернативы, и почему от них отказались.
Заголовок огонь. Rest и Kafka это вообще про разное. Все равно что написать статью про то, как "мы с супа пересели на автомобиль".
Правильно понимаю, что Мир за сутки обрабатывает сейчас 8 млн транзакции?
Мне кажется, что 8 млн сообщений != 8 млн транзакций. Для обработки одной транзакции может потребоваться сходить в несколько сторонних сервисов.
С другой стороны, 8М транзакций для всероссийской платёжной системы выглядят слегка заниженной циферой.
Не совсем так, приведенное в статье число относится только к одной из систем, с которыми взаимодействует клиринг, а не весь поток операций, обрабатываемых системой.
Данные для клиринга поступают в двух форматах: через kafka из различных систем-источников и в виде файлов в формате платежной системы «Мир» от банков. Более подробно можно прочитать в нашей другой статье на хабре https://habr.com/ru/companies/oleg-bunin/articles/695262/
А почему выбирали только между json и avro?
Почему не ужатый json, bson, kryo, protobuf?
какую стратегию доставки выбрали и почему?
Тот же вопрос. Я думаю, что json, сжатый zstd, был бы лучше со всех сторон
В наших других проектах уже использовался формат AVRO, поэтому введение нового решения выглядело не очень целесообразным. JSON мы рассмотрели из-за его простоты и гибкости, а также из-за имеющегося опыта работы с ним на предыдущем месте работы.
Что касается стратегии доставки сообщений, мы выбрали подход At Least Once. Это решение гарантирует, что каждое сообщение будет записано как минимум один раз, и разработали алгоритм для обработки дубликатов. Для нас критически важно не потерять данные, поэтому стратегия At Most Once нам не подходит. В то же время, мы достаточно легко можем обрабатывать дубли, поэтому реализация Exactly Once выглядела бы избыточной.
А почему решили использовать брокер сообщений? Если взаимодействие у вас асинхронное, то и rest может параллелится через балансировщик. Можно же точно также по rest-у вначале в базу записать транзакцию, а затем обработать в другом потоке.
А вы не пробовали сжимать json? У нас похожая проблема была, и в итоге просто добавили gzip. Определённо это не идеальное решение - размер всё равно больше чем avro/protobuf, зато со схемой проще - pojo файл конечно нужен, если мы хотим это сообщение использовать, но всегда можно на raw сообщение посмотреть, что бы понять что там вообще есть. А в хедере полное имя класса передаётся и по нему можно десериализовать.
А что бы универсально работало - gzip/string - есть magic number у gzip. Т.е. в топике просто байты, а на стороне клиента уже по первым 3 байтам понимается - это gzip или string.
Мы разные решения перепробовали и остановились на этом как наиболее универсальное - json сейчас все поддерживают - ui, backend, и человеком читается :-)
Как мы в клиринге переходили от REST к Kafka