В этой статье я хотел бы рассказать об архитектурных шаблонах Transactional Outbox и Idempotent Consumer. Кроме того, я хотел бы показать собственную реализацию, содержащую интересное сочетание технологий, выходящее за рамки этих шаблонов, значительно упрощающее реализацию и эксплуатацию.
Распределённые системы *
Нюансы проектирования распределенных систем
Что нового в Greenplum 7
- Что вы ожидаете от Greenplum 7?
- Postgres 12!
Если бы мы проводили опрос наших заказчиков, ответ на данный вопрос прозвучал бы именно так.
Как известно, Greenplum является одним из многочисленных форков Postgres, кодовая база которого наконец-то догнала ещё пока поддерживаемую версию Postgres (отмечу, что последний релиз Postgres 12 состоится в ноябре текущего года).
Однако наличие какого-либо функционала в Postgres не гарантирует его работу в рамках распределённой системы. В этой статье я начну рассказывать о функциях, которые стали доступны в новой версии, и о том, какой путь пришлось пройти, чтобы обеспечить их работоспособность, а также о возможных ограничениях и причинах их возникновения.
Пример своего транспорта для Symfony Messenger
В процессе изучения Symfony Messenger мной было создано два самодостаточных примера, демонстрирующих его работу (описаны в отдельных статьях).
В каждом из этих учебных примеров в качестве транспорта сообщений для простоты была выбрана БД SQLite.
Готовой реализации транспорта именно для SQLite я не нашёл и пришлось её использовать через DBAL Doctrine.
И всё бы ничего, но внутренний перфекционист :-) нашёптывал, что использование целой Доктрины лишь для того, чтобы работать с одной-единственной таблицей с очередями сообщений — это явный перебор…
Бороться с затерроризировавшим меня внутренним перфекционистом ;-) я не стал и, решив поглубже разобраться с устройством транспорта сообщений в Symfony Messenger, создал такой транспорт для SQLite сам, с использованием PDO.
А заодно потестировал производительность самопального решения и решения на Doctrine (на HDD и на RAM drive).
Основания рекурсивных компьютерных сетей связи
В этой статье я расскажу о том, что такое рекурсивные сети передачи данных. Во введении представлена историческая справка, далее формулируются основания - буквально в трех предложениях, затем они обсуждаются немного подробнее. В заключение приводятся иллюстрации на простых примерах - Wifi в рекурсивном представлении.
Истории
E2E-тестирование Flink Job с Kafka
Привет, Хабр! С вами Александр Бобряков, техлид в команде МТС Аналитики. Я к вам с новой статьёй из цикла про фреймворк Apache Flink.
В предыдущей части я рассказал, как создать Unit-тест на полноценную джобу Flink и отдельные stateful-операторы с использованием Flink MiniCluster. Ещё мы научились запускать мини-кластер один раз перед всеми тестовыми классами, которые нуждаются в нём. В дополнение создали вспомогательные абстракции и аннотации, значительно разделяя ответственность в тестах и упрощая логику написания новых тестов.
В предыдущих тестах на джобу мы не затрагивали интеграцию с Kafka, ведь нам были не важны реальные source и sink. В этой статье продолжим разбираться в тестировании и напишем полноценный E2E-тест, который охватит Kafka и Flink вместе с использованием Testcontainers. Также рассмотрим неочевидные проблемы в тестировании и новые универсальные абстракции.
Коннектор ADB-TO-ADB
По опыту нашей продуктовой команды разработки и поддержки, пользователи, оперирующие большими объемами данных компании часто используют несколько разрозненных кластеров Greenplum.
Мотивация такого решения может быть разной: организационная - разные команды-владельцы бизнес-данных выстраивают свои модели данных, обрабатывают их нужным для них образом; техническая - распределенные по различным датацентрам кластеры и т.п. Однако, рано или поздно возникает задача использовать данные из "соседних" хранилищ. Это могут быть как разовые сценарии единичных запросов, так и организация более сложных ETL-процессов. Реализация подобных механизмов опять-таки может быть разной со своими достоинствами и недостатками, исходя из возможностей и ограничений.
В этой статье рассматривается детали предлагаемой нами реализации коннектора для выполнения, так называемых, гетерогенных запросов в рамках разных кластеров ArenadataDB и/или Greenplum - задача, которой наша команда разработки занималась в 2023 году. Этот коннектор позволяет объединять в запросах разные кластеры ADB, но при этом пользоваться возможностями установления соединений между сегментами.
Но обо всем по порядку.
Пример использования Workerman и Symfony Messenger
Недавно мной был создан самодостаточный пример совместной работы компонентов Symfony Messenger и Symfony Console, подробно описанный в статье https://habr.com/ru/articles/817425/.
Для демонстрации работы этого примера нужно вручную запустить несколько консолей (терминалов), а потом в каждой вручную запустить Worker.
Мой внутренний перфекционист :-) сильно против этого возражал и говорил «а вот бы все эти консоли-терминалы запускались одной командой, в нужном количестве, сразу с Worker’ами, а если какой Worker упадёт, то заново запускались в нужном количестве».
Возражать своему внутреннему перфекционисту я не стал и создал ещё один пример работы Symfony Messenger, который запускается Worker’ами из PHP фреймворка Workerman. При этом Symfony Console вообще не используется.
Реализация глобальных индексов в распределённой системе
В этой статье я опишу наш путь реализации глобальных индексов в шардированной базе данных. Расскажу обо всех проблемах, с которыми столкнулись, и решениях, которые приняли, чтобы их обойти. Мы поговорим про реализацию на основе базы данных Tarantool, но общий подход применим и к другим шардированным базам данных без встроенной поддержки таких индексов, да и встроенная реализация часто строится по похожим принципам. Эта статья поможет разобраться в деталях, компромиссах и ограничениях работы глобальных индексов.
Простой пример использования Symfony Messenger
Пришёл и мой черёд асинхронно и многопоточно средствами PHP кое-что пообрабатывать… И я, естественно, вспомнил про компонент Messenger фреймворка Symfony.
Ранее я никогда Symfony Messenger не использовал.
Чтобы понять, как с ним работать, я пытался найти какой-то простой, законченный и самодостаточный пример, понятный даже чайнику, но мне это не удалось...
Всё, что находилось, было либо слишком сложным, либо это были какие-то отдельные куски кода, понятные только тем, кто уже работал с Symfony Messenger. К тому же всё, что находилось, в основном было "заточено" либо под Redis, либо под RabbitMQ. установка которых как-то немного перебор для учебного примера…
В-общем, я создал и выложил на GitHub такой простой, законченный и самодостаточный пример работы Symfony Messenger совместно с Symfony Console.
Рецепт приготовления непрерывного профайлера в 2к24
Всем привет! Меня зовут Газимагомед, я занимаюсь разработкой внутреннего распределённого профайлера Vision в Ozon. В этой статье я раскрою понятие профиля, расскажу о том, что такое распределённый профайлинг, чем отличается автоматический сбор профилей от ручного. А также рассмотрим проблемы, возникающие при построении профайлера. Что ж, усаживайтесь поудобнее, мы начинаем.
Разделяемость данных между микросервисами
Когда я только начинал работать с микросервисами, я чрезмерно буквально следовал общему правилу «не допускайте, чтобы два сервиса совместно использовали один источник данных».
Этот тезис фигурирует повсюду в Интернете как заповедь: «да не раздели ты базу данных между двумя сервисами» и, определённо, в нём есть смысл. Сервис должен владеть собственными данными и иметь возможность свободно менять их схему так, как будет сочтено нужным, не меняя при этом API, направленный вовне.
Но здесь есть важная тонкость, которую я осознал далеко не сразу. Чтобы как следует применять это правило, необходимо различать совместное использование источника данных и совместное использование данных как таковых.
Современный клиент к NoSQL-базе данных
Интеграция через базу данных (БД) — один из распространенных видов интеграции. Но БД — тоже сервис, к которому также требуется подключение. Для пользователей эта процедура сводится к подключению коннекторов и изучению их API, но «под капотом» подобных клиентов может скрываться большая архитектура со сложной логикой взаимодействия.
Как мы боролись за доступность сайта по всему миру, настраивали GeoDNS и при чём здесь Суринам
Что делать, если ваш сайт блокируют то из одних, то из других точек, чем может помочь GeoDNS и почему лучше не использовать экзотические доменные зоны, хотя они очень красивые
Ближайшие события
Проблема «Грохочущего стада»
Давайте перенесёмся в апрель 2018 года. Тогда я работал на стартапе, который собирался выпустить очень востребованную новую функцию. Мы уже сформировали лист ожидания, но о дате запуска не распространялись (в основном потому, что не знали, когда закончится разработка).
После доставки последних функций, чтобы считать, что минимально жизнеспособная версия продукта (MVP) готова, мы провели небольшое тестирование, чтобы убедиться, что все пользовательские пути работают так, как мы рассчитывали. Все выглядело хорошо, и, поговорив с продукт-менеджером мы решили включить эту функцию для всех клиентов. Конечно, вся компания с волнением ожидала этого события — первое большое обновление за долгое время — и не успели мы оглянуться, как всем клиентам были отправлены push-уведомления, а лист ожидания был закрыт.
Мы не ожидали такого наплыва входящего трафика, и вскоре стали поступать предупреждения о падении сервисов из-за неконтролируемой паники, которую мы не учли. После исправления мы повторно развернули систему, на мгновение поток предупреждений прекратился, и мы могли расслабиться. Однако это было недолго, так как через 5 минут начал появляться совершенно другой набор предупреждений (высокая задержка, высокое использование ЦП). Пришло время снова поработать в аврале.
Распределенная трассировка с Jaeger и Clickhouse
Привет! Меня зовут Филипп Бочаров, я руководитель центра мониторинга и наблюдаемости в МТС Digital. Мы делаем распределённую трассировку, чтобы контролировать качество наших сервисов и предотвращать аварии. В этой статье разберём, как добиться понятной и прозрачной работы от сложных распределённых систем.
За время, прошедшее с прошлого доклада, количество обрабатываемых в единицу времени спанов выросло в несколько раз. Рассмотрим, какие архитектурные решения начали «поджимать», и как команда МТС их исправляла.
Postgres Pro Shardman: горизонтальное масштабирование реляционных СУБД
Последние несколько лет мы в Postgres Professional активно занимаемся разработкой своего решения для горизонтального масштабирования PostgreSQL. Пользователям нужен был простой способ увеличить производительность путем добавления узлов. Традиционно для веба в таких случаях просто брали NoSQL базы или шардировали вручную, позже появились распределенные SQL-решения с поддержкой ACID-транзакций. Тем не менее терялась часть возможностей и достоинств PostgreSQL. Корпоративный рынок тяжелых вертикальных решений также сильно ограничен как ценой, так и доступностью. Поэтому исследованиями в области распределенных СУБД в компании занимались еще с 2017 года, а в 2020 началась работа над коммерческим продуктом.
В этой статье я расскажу про технические детали реализации и почему был сделан такой выбор технологий. Опишу, какие направления нам показались преждевременными и их пришлось отложить, а также что мы ожидаем в будущем.
Разбор вердикта суда в отношении разработчика Tornado Cash
В результате беспрецедентного судебного разбирательства Алекс Перцев, ключевой разработчик инструмента для обеспечения приватности на базе Ethereum под названием Tornado Cash, был приговорен сегодня к более чем пяти годам тюремного заключения за свою работу над проектом. Вынесенный приговор был максимальным, запрошенным прокуратурой, и стал первым приговором разработчику, создавшему децентрализованный инструмент достижения приватности с использованием криптовалют.
Шардирование баз данных и проектирование систем
Шардирование базы данных — это процесс её разделения на несколько машин, что способствует масштабируемости приложения. Механизм шардирования предполагает разбиение данных на два или более мелких фрагмента, называемых логическими шардами. Затем логические блоки распределяются по отдельным узлам базы данных, называемым физическими блоками, каждый из которых может содержать несколько логических блоков.
Такой подход позволяет избежать проблем с производительностью, возникающих, когда одна из машин работает в условиях перегрузки, и обеспечивает более экономичное и грамотное масштабирование. По мере увеличения объема данных и трафика все чаще возникает необходимость горизонтального масштабирования путем добавления новых машин, а не вертикального путем модернизации одного большого сервера.
Unit-тестирование Flink-операторов, Job: Flink MiniCluster
Привет, Хабр! С вами вновь Александр Бобряков, техлид в команде МТС Аналитики. И я с очередной статьёй из цикла про фреймворк Apache Flink.
В предыдущей части я рассказал, как тестировать stateless- и stateful-операторы Flink с использованием вспомогательных TestHarness-абстракций, предоставляемых Flink.
В этой статье напишем тесты на всю джобу с использованием мини-кластера Flink и при помощи JUnit Extension. Ещё мы начнём выделять удобные вспомогательные абстракции для тестов, которые понадобятся позже.
Остаться в живых (keepalive) feat. HTTP/2, Go & gRPC-Go
Привет, Хабр!) Меня зовут Ильяс. В этой статье мы разберём известную идею — keepalive в межсервисном взаимодействии, которая спасла уже не одну компанию в трудное время :). Но чтобы добавить интереса, мы разберём, какие проблемы в keepalive принесли современные технологии (ведь что может пойти не так с этой простой идеей?). Поэтому в статье мы рассмотрим механизмы, которые позволяют проверять стабильность соединения между клиентом и сервером в случае, когда обычные TCP keepalive из-за сложности архитектуры не могут определить состояние сервера.
Вклад авторов
olegchir 356.4Captain_Jack 260.0Bright_Translate 192.4ph_piter 169.6andreyka26 159.0clubadm 159.0jirfag 152.0sergepetrenko 141.0bitec 129.0nezhibitskiy 128.0