Нюансы проектирования распределенных систем
Продолжаем наращивать базу знаний по System Design. В этот раз освятим использование BLOB Storage, CDN, Message Broker. Посмотрим на основные концепции и области применения этих важных компонентов при проектирование высокодоступных отказоустойчивых систем.
Воркшоп для тех, кто впервые сталкивается с распределёнными системами.
В этой статье на примере решения несложного архитектурного кейса я покажу, что ответов только на 3 вопроса при проектировании систем распределённой параллельной обработки данных будет достаточно для обеспечения жёстких нефункциональных требований.
Kafka-консьюмеры не всегда работают так стабильно, как хотелось бы. Иногда они просто зависают — без ошибок, без падений, но и без обработки сообщений. LivenessProbe в Kubernetes помогает автоматически перезапускать зависшие сервисы, но с Kafka-консьюмерами всё не так просто: стандартного решения для них нет. В этой статье разберём, как правильно реализовать livenessProbe для консьюмеров с помощью паттерна Heartbeat, чтобы не перезапускать их вручную.
Redis — это высокопроизводительное хранилище «ключ-значение» в оперативной памяти, известное своей невероятной скоростью. Фактически, один сервер Redis может обрабатывать до 100 000 запросов в секунду (QPS). Такая скорость часто удивляет, особенно если учесть, что Redis в основном работает по однопоточной модели обработки запросов. Так почему же Redis работает так быстро, несмотря на однопоточный подход? Давайте рассмотрим ключевые факторы, влияющие на производительность Redis.
Это компиляция основных знаний по проектированию архитектуры ПО, которые мне удалось собрать. Конспект доступен по ссылке на Miro-доску.
Можно сказать, что это взгляд на System Design с точки зрения фронтенд-разработчика, который пытается разобраться в теме.
Привет, Хабр! Меня зовут Михаил Федяев, я работаю архитектором в департаменте управления технологиями МТС Диджитал. В нашей экосистеме порядка 500 разных продуктов — для их развития у всех команд должны быть общие правила принятия решений. Они сформулированы в виде 15 технологических принципов. Сегодня я хочу рассказать про один из них — «Микросервисы». Он определяет, как в нашей компании подходят к внедрению микросервисной архитектуры.
В этой статье я не буду говорить про NFT, про Ethereum и т.п. Я сосредоточусь на возможности и смысле перенести все доступное нам сейчас с Web 2 на Web 3.
В общем случае конфигуриоование распределенных и кластерных систем - задача непростая. Для кого может быть полезным инструмент Sparky? Если у вас не используется кубернетес и вам приходится конфигурить / обновлять распределенную инфраструктуры со сложными взаимосвязями. Здесь я покажу несколько примеров не претендующих на исчерпывающее покрытие данной темы
Базовая конфигурация
Для того что бы все работало необходимо установить Sparky агенты на все настаиваемые ноды вашего кластера и обеспечить сетевую связанность на уровне http/https.
Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.
Изучая System Design, вы часто видите только теоретические материалы. В этой статье я постарался показать в том числе практическую реализацию многих вещей, чтобы вы не просто готовились к собеседованиям, но и знали, как эти вещи используются в реальном мире.
Рассказать надёжный способ заработать на криптовалютах? Устраиваетесь в блокчейн-проект разработчиком, пишете код, получаете зарплату. Готово, вы стали богаче, пока другие прогорали на бирже!
Шутки шутками, но мир web3 разросся в индустрию со своими вакансиями. И в ней востребован JavaScript, причём не только на фронтенде. Так что у JS-разработчиков появился смысл обращать внимание на этот сегмент, а на нашей конференции HolyJS появились доклады об этом.
И для Хабра мы решили перевести в текстовый вид выступление Александра Казакова @AlexandrKazakov, помогающее влиться в тему. В этом докладе рассматривается блокчейн Solana, но после него проще будет разбираться и с другими вроде Ethereum или TON. Если вам удобнее видео, прилагаем ссылки: YouTube, VK Видео. Далее — текст от лица спикера.
Здравствуйте, меня зовут Дмитрий Карловский и я.. стараюсь сложные вещи рассказывать простым языком, а простые вещи — эзоповым. И часто оказывается так, что в процессе упрощения и структурирования, на самом видном месте обнаруживаются скелеты древних динозавров, присыпанные мутными формулировками так, что долгие годы их никто не замечает. Что ж, если вы хотите окончательно разобраться в уровнях изоляции транзакций и гарантиях порядка операций, до давайте копать вместе.
Привет, Хабр! На связи Александр Бобряков, техлид команды МТС Аналитики. Это мой финальный пост про Apache Flink. В предыдущих частях мы рассматривали процессы сериализации данных, написали кастомный сериализатор, а также покрыли его тестами. В них проверялась поддержка эволюции схемы состояния. Для этого мы реализовали много удобных абстракций, связанных с перезагрузкой Flink MiniCluster, компиляцией тестовых java-классов, использованием их в classpath кластера и так далее.
В этом материале мы применим разработанный сериализатор JacksonStateSerializer в бою, а также автоматизируем проверку эволюции схемы для всех наших классов, участвующих в сериализации.
Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии. Данная статья соответствует релизной ветке с названием release/11_JacksonEvolvingState. По мере выхода новых материалов на Хабре ссылки на них будут появляться ниже.
Список моих постов про Flink:
Привет, Хабр! Меня зовут Глеб Типсин, я являюсь ведущим разработчиком продукта «Системы персонализации и геймификации» в SM Lab.
В этой статье мы разберём, как устроены метрики в Prometheus, как происходит их сбор, а также что с ними можно делать. Кроме того, обсудим подходы в мониторинге, архитектуру Prometheus и её ограничения.
Материал подойдёт тем, кто только знакомится с мониторингом и хочет освоить «базу», а также тем, кто уже работает с Prometheus, но хочет "освежить" свои знания и узнать что-то новое.
Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.
Изучая System Design, вы часто видите только теоретические материалы. В этой статье я постарался показать в том числе практическую реализацию многих вещей, чтобы вы не просто готовились к собеседованиям, но и знали, как эти вещи используются в реальном мире.
В мире микросервисов часто возникает необходимость сделать согласованные изменения в сервисах. Один из надёжных способов добиться этого — использовать паттерн «Сага», который помогает выполнять распределённые транзакции и при сбоях корректно откатывать изменения. Но, как всегда, есть нюансы, начиная от нереалистичных материалов на эту тему и заканчивая реальным опытом использования.
Алексей Бакин занимается разработкой внутренних продуктов. Один из них — это API-прокси, предоставляющее внешние API для внутренних сервисов. Для реализации этого решения использовали паттерн «Сага».
На один из процессов я разработала почти 150 тестов. В статье показываю и рассказываю, как тестировать в Camunda.
Статические таблицы нужны, чтобы хранить в них неизменяемые данные. Это означает, что данные, записанные в статическую таблицу, нельзя модифицировать в произвольном месте — их можно либо перезаписать полностью, либо дополнить, сделав запись в конец таблицы.
Основная боль при работе с такой таблицей возникает при росте количества хранимых в ней данных. Время чтения или записи возрастает пропорционально её объёму. Из‑за этого может настать момент, когда взаимодействовать с таблицей становится просто невозможно, и пользователям приходится придумывать ухищрения, чтобы справиться с этим.
В этой статье мы разберём механизм мёрджа чанков с помощью мастер‑серверов, который мы реализовали для статических таблиц YTsaurus — нашей платформы распределённого хранения и обработки больших данных с открытым исходным кодом.
Данная статья является попыткой моего личного обобщения и выделения различий над зоопарком современных технологий, в которых в том или ином виде используются термины: мульти-агенты ИИ (ollama, meta, camel), мульти-агенты неИИ (MAS, эмержность, интеллект роя) и актеры (Akka, асинхронность, сообщения). А также интерес применимости к домену планирования - логистики, производства. Составления расписаний. С упором на футуристичность =)
При переходе от монолитной к микросервисной архитектуре разработчики часто сталкиваются с несколькими проблемами.
Во-первых, это необходимость переработки существующего кода и его разбиения на независимые сервисы, что может быть трудоемким и сложным процессом.
Во-вторых, возникают сложности с обеспечением взаимодействия между микросервисами, включая управление сетевыми запросами и обработку ошибок. Кроме того, важно наладить мониторинг и логирование каждого микросервиса для своевременного выявления и устранения проблем в распределенной системе.
Использование в практике таких паттернов как Strangler Fig Pattern, Parallel Run Pattern, Decorating Collaborator Pattern и Change Data Capture позволяет разработчикам значительно снизить риски и проблемы, возникающие при таком сложном переходе.
Давайте рассмотрим основные концепции этих паттернов.