Сам образ просто содержит признак, что он собран под другую архитектуру.
Важно не это, а то, что исполняемый файл запускается внутри. В Linux ядре есть специальный механизм - binfmt, который при запуске исполняемого файла умеет проверять его сигнатуру (первые несколько байт) и по ним определять, под какую архитектуру скомпилирован файл и запускать нужный для нее враппер. А если бы точным, то определяет не архитектуру, а просто в какой враппер нужно обернуть запуск файла с такой сигнатурой.
И дальше запускается qemu нужного вида и транслирует инструкции amd64 под arm
Ну кстати это хороший вопрос, я не имею отношения к статье и ее кейсу, но со своей стороны я бы сказал, что джетстрим по моему опыту показал себя гораздо медленнее и менее надёжным, чем кафка
Под капотом на данный момент у нас Kafka, а для внутрисервисных очередей - Apache Pulsar. Вокруг них своя обёртка на go для сокрытия топологии кластеров и валидации контрактов
Спасибо за комментарий. Да, все верно, чаще всего порядок событий реализуется на стороне клиентов, но есть варианты когда брокер предоставляет механики для соблюдения порядка, такие как шардирование по ключу для помещения событий одной сущности в одну партицию, эксклюзивный консьюминг, когда только один консьюмер читает соответствующий топик и т.п.
Статья дает общий обзор существующих гарантий и какие причины могут приводить к их нарушениям или сложности в поддержании.
Нет, пока не думаем менять, потому что основное время тратится на взаимодействие с самой кафкой, а в ней в свою очередь - на дисковые и процессорные операции.
Использование grpc даст (но не для всех клиентов) экономию процессорного времени и немного сети, что однако не является для нас узким местом.
Основной профит в том, что скрыта технология под капотом. Сегодня кафка, завтра может быть редпанда, послезавтра - федерация кластеров. А для клиентов точки входа и апи не меняются
Дело в том, что проблема не в ресурсах, Кафка нормально масштабируется горизонтально. Дело в надёжности и времени восстановления.
Схема с несколькими кафками на запись (под каждый из дц) выбрана исходя из требования гарантировать доступность записи. У такого решения минус тоже есть, в виде сложности системы, например. Поэтому сейчас мы движемся к другой схеме, где будут отдельные независимые кластера меньшего размера
От части вы правы: мы получили дополнительный сервис в поддержку, протокол у нас собственный.
Тут правда надо заметить, что мы скрываем, что у нас вообще используется Кафка от пользователей, для них сервис скорее похож на amazon sqs, Yandex queues и так далее.
Пункт 3 не совсем понятен: почему становится труднее, такого в статье не утверждается.
Редпанда нам нравится и у нас есть планы на переход на нее, о чем однажды, думаю, будет следующая статья
Дисбаланс подключений действительно возможен. Но нагрузка от таких подключений на databus не очень большая, а подключений много, поэтому в среднем распределение достаточно равномерное. Поэтому в этом плане у нас есть упрощение: сложной балансировки нет.
События действительно могут перепутаться, также, да, в текущей схеме может быть ситуация, когда часть событий останется в умершем ДЦ. Но мы намеренно не предоставляем гарантий порядка событий на данном этапе эволюции нашей системы и требуем от клиентов устойчивости к нарушениям порядка и дублям.
Camel для нашего случая не рассматривали. Наша шина представляет собой просто механизм обмена событий и не предполагает наличие логики по их обработке или трансформации. В будущем - возможно вокруг нее добавится какой-то механизм для обработки, тогда мы посмотрим на доступные варианты, может быть и camel, хотя он не очень ложится в стек нашей компании (из-за java/kotlin)
Да, формат конечно же похож на описание protobuf, спасибо за замечание
Единый реестр есть, в статье есть кратко про это. Все схемы событий при деплое попадают в этот реестр и потом мы валидируем изменения на допустимость и публикуемые события на корректность
Бесплатность, возможность запуска виртуалки для общих целей и задач
Ещё рекомендую рассмотреть OrbStack: быстрее Docker Desktop на порядок
Сам образ просто содержит признак, что он собран под другую архитектуру.
Важно не это, а то, что исполняемый файл запускается внутри. В Linux ядре есть специальный механизм - binfmt, который при запуске исполняемого файла умеет проверять его сигнатуру (первые несколько байт) и по ним определять, под какую архитектуру скомпилирован файл и запускать нужный для нее враппер. А если бы точным, то определяет не архитектуру, а просто в какой враппер нужно обернуть запуск файла с такой сигнатурой.
И дальше запускается qemu нужного вида и транслирует инструкции amd64 под arm
Все верно :) Но часто это лучше, чем торможение образов ненативных
Ну кстати это хороший вопрос, я не имею отношения к статье и ее кейсу, но со своей стороны я бы сказал, что джетстрим по моему опыту показал себя гораздо медленнее и менее надёжным, чем кафка
Nats из коробки как минимум не персистентный (не берём в рассмотрение Jetstream)
Да, но это выполняется только при условиях одной очереди, одного эксчейнджа, одного консьюмера и так далее.
Ничего особого, собственно
Под капотом на данный момент у нас Kafka, а для внутрисервисных очередей - Apache Pulsar. Вокруг них своя обёртка на go для сокрытия топологии кластеров и валидации контрактов
Спасибо за комментарий. Да, все верно, чаще всего порядок событий реализуется на стороне клиентов, но есть варианты когда брокер предоставляет механики для соблюдения порядка, такие как шардирование по ключу для помещения событий одной сущности в одну партицию, эксклюзивный консьюминг, когда только один консьюмер читает соответствующий топик и т.п.
Статья дает общий обзор существующих гарантий и какие причины могут приводить к их нарушениям или сложности в поддержании.
Да, похожая, хотя нагрузка меньше.
Нет, пока не думаем менять, потому что основное время тратится на взаимодействие с самой кафкой, а в ней в свою очередь - на дисковые и процессорные операции.
Использование grpc даст (но не для всех клиентов) экономию процессорного времени и немного сети, что однако не является для нас узким местом.
Нагрузка немаленькая.
А сколько реплик топиков используется и в каком режиме происходит продьюсинг (acks=0, acks=1, acks=all)?
Основной профит в том, что скрыта технология под капотом. Сегодня кафка, завтра может быть редпанда, послезавтра - федерация кластеров. А для клиентов точки входа и апи не меняются
Весьма интересная статья, спасибо!
Через OpenPolicy, все верно
Спасибо за вопрос. Мы в настоящий момент используем uReplicator, но в планах отказаться от него в пользу меньших кластеров
Спасибо!
Мы даём пользователям at least once, достигаем за счет механики ack на продьюсере и на консьюмере
Дело в том, что проблема не в ресурсах, Кафка нормально масштабируется горизонтально. Дело в надёжности и времени восстановления.
Схема с несколькими кафками на запись (под каждый из дц) выбрана исходя из требования гарантировать доступность записи. У такого решения минус тоже есть, в виде сложности системы, например. Поэтому сейчас мы движемся к другой схеме, где будут отдельные независимые кластера меньшего размера
Спасибо за комментарий.
От части вы правы: мы получили дополнительный сервис в поддержку, протокол у нас собственный.
Тут правда надо заметить, что мы скрываем, что у нас вообще используется Кафка от пользователей, для них сервис скорее похож на amazon sqs, Yandex queues и так далее.
Пункт 3 не совсем понятен: почему становится труднее, такого в статье не утверждается.
Редпанда нам нравится и у нас есть планы на переход на нее, о чем однажды, думаю, будет следующая статья
Спасибо, на RSocket посмотрим обязательно.
Дисбаланс подключений действительно возможен. Но нагрузка от таких подключений на databus не очень большая, а подключений много, поэтому в среднем распределение достаточно равномерное. Поэтому в этом плане у нас есть упрощение: сложной балансировки нет.
События действительно могут перепутаться, также, да, в текущей схеме может быть ситуация, когда часть событий останется в умершем ДЦ. Но мы намеренно не предоставляем гарантий порядка событий на данном этапе эволюции нашей системы и требуем от клиентов устойчивости к нарушениям порядка и дублям.
Camel для нашего случая не рассматривали. Наша шина представляет собой просто механизм обмена событий и не предполагает наличие логики по их обработке или трансформации. В будущем - возможно вокруг нее добавится какой-то механизм для обработки, тогда мы посмотрим на доступные варианты, может быть и camel, хотя он не очень ложится в стек нашей компании (из-за java/kotlin)
Да, формат конечно же похож на описание protobuf, спасибо за замечание
Единый реестр есть, в статье есть кратко про это. Все схемы событий при деплое попадают в этот реестр и потом мы валидируем изменения на допустимость и публикуемые события на корректность
Выше уже ответили на многие вопросы.
У нас есть таймауты на подключения, keep-alive сообщения, чтобы убедиться, что клиент жив.
Также у нас есть реестр схем событий, благодаря которому мы можем валидировать контракты как в момент попытки деплоя сервиса, так и при публикации