Пятничное чтиво
Эту неделю провел в обнимку с Kafka, поэтому ссылки будут тоже тематические. На стримах покажу на практике как все сегодняшние ссылки работают в руби и расскажу почему это круто. Так же, открыт CFP на RubyRussia. Можно заполнить форму, а можно написать лично, попробую помочь с темами.
Стримы отпуске, темы пишутся. Вспомнить что было можно тут. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
Kafka in a Nutshell - Kevin Sookocheff
Thorough Introduction to Apache Kafka
Две статьи, описывающие базовые концепции кафки. Старт для тех, кто хочет разобраться как база работает. Если хотите быстро разобраться что такое кафка - забейте на zookeeper, streaming API. Прочитайте что такое producers, consumers, consumers group, а лучше поставьте кафку локально и напишите hello world продюсер и консьюмер (можно взять karafka). Для локальной работы Confluent Platform сделали docker-compose.yaml который ставит последнюю версию кафки и все необходимое . Так же стоит понять что такое message в контексте кафки и как partitions помогают паралелизовать консьюмеры. После этого уже можно смотреть на репликацию, зукипер и другие страшные вещи.
—————————————
Schema Management
В distributed systems много проблем. Первая проблема, которая появляется, когда сервисов становиться больше 2 - как гарантировать работу сервисов с одинаковыми данными. А так же, как обновлять схему запроса/ответа, чтобы не сломать систему. Такие проблемы относятся к эволюции данных и схемы данных и подробно описываются в Designing Data-Intensive Applications. Умные ребята подумали и сделали schema registry, которая позволяет хранить описание схем в отдельном топике кафке. Это означает, что каждая схема данных находиться в едином месте и каждый продюсер и консьюмер будет использовать одну и ту же схему данных. К сожалению, schema registry работает только с avro и за счет имутабельности сообщений кафки решает проблему совместимости схем о которой писал в прошлую пятницу.
—————————————
Stream-based Architecture
Build Services on a Backbone of Events
Важно понимать, что кафка является distributed streaming platform. Это значит, что привычные паттерны, которые используются в pub/sub не подходят. Поэтому стоит использовать другие подходы к построению архитектуры. В статьях выше описывается понятие Stream-based Architecture, в чем отличие такой архитектуры. Описывается процесс Event Driven Flow и затрагивается почему топики должны быть domain specific. Основные проблемы работы с кафкой - обучение инженеров и затраты на operations. Поэтому, если думаете, что кафка решит проблемы приложения - прочтите эти две статьи и попробуйте представить как может выглядеть data flow в приложении.
——— одной строкой ———
- HAProxy EBtree: Design for a Scheduler, and Use (Almost) Everywhere;
Эту неделю провел в обнимку с Kafka, поэтому ссылки будут тоже тематические. На стримах покажу на практике как все сегодняшние ссылки работают в руби и расскажу почему это круто. Так же, открыт CFP на RubyRussia. Можно заполнить форму, а можно написать лично, попробую помочь с темами.
Стримы отпуске, темы пишутся. Вспомнить что было можно тут. Так же буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму.
—————————————
Kafka in a Nutshell - Kevin Sookocheff
Thorough Introduction to Apache Kafka
Две статьи, описывающие базовые концепции кафки. Старт для тех, кто хочет разобраться как база работает. Если хотите быстро разобраться что такое кафка - забейте на zookeeper, streaming API. Прочитайте что такое producers, consumers, consumers group, а лучше поставьте кафку локально и напишите hello world продюсер и консьюмер (можно взять karafka). Для локальной работы Confluent Platform сделали docker-compose.yaml который ставит последнюю версию кафки и все необходимое . Так же стоит понять что такое message в контексте кафки и как partitions помогают паралелизовать консьюмеры. После этого уже можно смотреть на репликацию, зукипер и другие страшные вещи.
—————————————
Schema Management
В distributed systems много проблем. Первая проблема, которая появляется, когда сервисов становиться больше 2 - как гарантировать работу сервисов с одинаковыми данными. А так же, как обновлять схему запроса/ответа, чтобы не сломать систему. Такие проблемы относятся к эволюции данных и схемы данных и подробно описываются в Designing Data-Intensive Applications. Умные ребята подумали и сделали schema registry, которая позволяет хранить описание схем в отдельном топике кафке. Это означает, что каждая схема данных находиться в едином месте и каждый продюсер и консьюмер будет использовать одну и ту же схему данных. К сожалению, schema registry работает только с avro и за счет имутабельности сообщений кафки решает проблему совместимости схем о которой писал в прошлую пятницу.
—————————————
Stream-based Architecture
Build Services on a Backbone of Events
Важно понимать, что кафка является distributed streaming platform. Это значит, что привычные паттерны, которые используются в pub/sub не подходят. Поэтому стоит использовать другие подходы к построению архитектуры. В статьях выше описывается понятие Stream-based Architecture, в чем отличие такой архитектуры. Описывается процесс Event Driven Flow и затрагивается почему топики должны быть domain specific. Основные проблемы работы с кафкой - обучение инженеров и затраты на operations. Поэтому, если думаете, что кафка решит проблемы приложения - прочтите эти две статьи и попробуйте представить как может выглядеть data flow в приложении.
——— одной строкой ———
- HAProxy EBtree: Design for a Scheduler, and Use (Almost) Everywhere;