Полное описание пакета topic в ydb-go-sdk, написанное для инженера, впервые знакомящегося с YDB Topics. Руководство ведёт от базовых понятий («что такое топик?») через каждый публичный тип, опцию и метод, и заканчивается сквозными рабочими примерами.
Когда приложению нужен service discovery, первое привычное решение — взять отдельный инструмент: Consul, ZooKeeper или аналогичный сервис. Но иногда координационный механизм уже есть в стеке, и тогда отдельный сервис оказывается лишней инфраструктурной сущностью.
Ниже разберём такой сценарий на примере YDB Coordination Node. Задача не в том, чтобы заменить любой service discovery на YDB, а в том, чтобы показать конкретный класс задач, где координационная нода может работать как простой реестр живых инстансов и их конфигурации.
Представим мультитенантное приложение, в котором пользователи могут регистрировать адреса вебхуков. Основная бизнес-логика живёт в группе машин App: она принимает события, определяет нужного пользователя, выбирает зарегистрированный webhook endpoint и отправляет туда HTTP-запрос.
Для большинства пользователей исходящий трафик может идти через общий пул инфраструктуры. Но премиальные пользователи попросили отдельную возможность: чтобы все запросы к их webhook-адресам уходили только с заранее известных выделенных IP-адресов. Тогда они смогут добавить эти IP в свои firewall allowlists и не открывать доступ для всего интернета.
Наивное решение — поднимать отдельную виртуальную машину под каждый выделенный IP или под каждого премиального клиента. На небольших объёмах это работает, но быстро становится экономически невыгодным: ресурсы простаивают, количество машин растёт вместе с числом клиентов, а операционная сложность начинает жить своей жизнью.
Поэтому вводится отдельный тип машин, который будем называть Border. Это пограничные ВМ, через которые уходит внешний трафик к webhook-получателям. На одной такой машине может быть настроено несколько выделенных IP-адресов, а разные пользователи могут быть привязаны к разным адресам или наборам адресов. Таким образом, Border выступает как общий, но управляемый слой egress-инфраструктуры: он позволяет переиспользовать вычислительные ресурсы, сохраняя для клиентов предсказуемые исходящие IP.
Остаётся ключевая проблема: App не может просто один раз получить список Border-машин и считать его постоянным. Количество Border может динамически меняться: группа может масштабироваться, отдельные машины могут перезапускаться во время релиза, временно выпадать из работы или заменяться новыми инстансами.
Итого слой App должен в каждый момент времени знать не просто список Border, а актуальную карту: какой выделенный IP жив, на каком Border он доступен и можно ли через него сейчас отправлять трафик. В дальнейшем мы будем рассматривать именно этот сценарий: как организовать взаимодействие между App и Border так, чтобы маршрутизация webhook-запросов оставалась корректной, устойчивой к изменениям инфраструктуры и при этом не требовала неэффективной схемы «одна ВМ — один IP».
Почти любой бэкенд рано или поздно сталкивается с необходимостью отложенной обработки задач: отправить email после регистрации, пересчитать агрегаты, выполнить задачу по расписанию. Часто для этого подключают отдельную систему — RabbitMQ, Kafka, Redis-очереди. Но если ваши данные уже живут в YDB, нужные примитивы уже рядом: таблицы, changefeed, топики и координационные ноды.
В этой статье разберём четыре подхода к асинхронной обработке задач — от простой таблицы до архитектуры, пригодной для production-сценариев. Каждый следующий подход решает проблемы предыдущего, но добавляет сложности. Вместо абстрактных описаний — рабочий код на Go с использованием ydb-go-sdk.
Я уже полтора года пишу в этот standalone блог. До этого я писал на Medium. И вот там была классная фича, сделать
которую тут у меня все не доходили руки. Это форма подписки на email. Я хотел сделать так, чтобы читатели могли
подписаться
на новые статьи и получать на почту уведомления. Но я не хотел использовать Mailchimp или подобные сервисы. Я хотел
сделать все, используя Yandex Cloud. И вот наконец-то я это сделал. В этой статье я расскажу, как я это сделал.
Кстати, справа вы видите именно эту форму подписки. Если вы хотите подписаться на новые статьи, введите свой email и нажмите кнопку "Подписаться". А теперь давайте разберемся, как это работает.
В прошлом посте говорил, что в задачах для которых создавалась YDB использование автоинкремента нецелесообразно. Так как он может стать бутылочным горлышком при вставке большого количества данных.
Однако, с развитием YDB, разработчикам стало понятно, что serial типы данных востребованы пользователями. И в версии 24.3 они были добавлены.
Паттерн Outbox решает проблему двойной записи, которая возникает в распределенных системах, когда одна операция включает в себя как операцию записи в базу данных, так и отправку сообщения или уведомления.
Двойная запись происходит, когда приложение пишет в две разные системы, например, когда микросервису нужно сохранить данные в базе данных и отправить сообщение для уведомления других систем.
Ошибка в одной из этих операций может привести к не консистентным данным.
Его нет. И вообще это плохая идея и вот почему.
В первой части мы закончили на том, что запустили Apollo в облаке. Но это слишком простое API. Поэтому сейчас добавим интеграцию с Severless YDB.