Быстро — не всегда хорошо: рейтлимиты в мультикластерном окружении

Всем привет! Кажется, настало время поговорить о том, как внедрялись ограничители частоты запросов на бэкенд в Wildberries. В статье — о том, с какими трудностями мы столкнулись на этом благородном пути и как прошли через четыре схемы реализации — от простейшей in-memory до собственных gRPC-сервисов. Не обойдём вниманием и парочку лайфхаков ;) Например, с помощью рейтлимитов мы неожиданно решили проблему плавного отключения старых версий API. Меня зовут Дмитрий Виноградов , и я лид команды публичного API Wildberries. До этого почти 18 лет занимался промышленной автоматизацией в Schneider Electric — от программирования контроллеров и embedded-устройств до собственных SCADA-систем. Хочешь не хочешь, а научишься делать красивые интерфейсы :)

https://habr.com/ru/companies/wildberries/articles/932050/

#redis #go #rate_limiting #api #распределенные_системы #grpc

Децентрализованные системы радиосвязи

Картинка rawpixel.com , Freepik В прошлой статье мы затронули очень интересную тему — распределённые хостинги/хранилища данных. Было бы странно, если бы идея распределённых систем ограничивалась только хранилищами ;-) Поэтому сегодня мы поговорим ещё об одном интересном направлении, о котором редко говорят — распределённых сетях радиосвязи. Возможно ли это?

https://habr.com/ru/companies/ruvds/articles/927108/

#ruvds_статьи #децентрализованные_системы #распределенные_системы #радиосвязь

Практическое использование Kafka в микросервисных приложениях на примере Open Source платформы Ensi

Микросервисная архитектура позволяет разрабатывать высоконагруженные, распределенные и гибкие приложения. Но цена разработки таких систем очень высока, и решая выше указанные проблемы, разработчики сталкиваются с другими проблемами, которых либо нет в монолитных приложениях, либо они не так сильно в них проявляются: сложный обмен данными между сервисами , денормализация и консистентность данных , инвалидация кэша и интеграция с внешними системами . Решать выше перечисленные проблемы можно разными способами. В своей работе в компании Greensight в качестве senior backend developer при разработке заказных проектов на базе Open Source платформы Ensi, я с коллегами перепробовал множество решений. Данная статья описывает практическое использование Kafka в микросервисных приложениях для решения этих проблем.

https://habr.com/ru/articles/925176/

#Kafka #микросервисы #Ensi #ecom #laravel #высоконагруженные_проекты #распределенные_системы #open_source

Сквозь тернии к апдейту: история о том, как мы обновляли стриминг ОК

Стриминговые данные — важная часть многих современных ИТ-платформ. Они активно используются в разных разделах социальной сети Одноклассники уже более 10 лет. И за это время используемый нами стриминговый фреймворк успел заметно измениться, поэтому настало время обновить его в нашем проекте. Но на пути обновления легаси-систем иногда возникают сложности. Меня зовут Алина Шестакова. Я разработчик в команде разработки DataPlatform единой облачной платформы One-сloud. В этой статье расскажу о том, как устроен стриминг данных в ОК, а также обо всех патчах и челленджах, возникших в процессе обновления стримингового фреймворка.

https://habr.com/ru/companies/vk/articles/924650/

#streaming #java #highload #legacy #инфраструктура #bigdata #распределенные_системы #обработка_данных

Мой личный Proof-of-Work. Как я майнил знания о блокчейне

Как обычный C++ разработчик решил разобраться с блокчейном — личный опыт создания простой реализации с нуля. Мини-история о том, что получилось, какие подводные камни встретились, и как эти знания можно применить в реальных проектах.

https://habr.com/ru/articles/920604/

#программирование #c++ #криптография #блокчейн #алгоритмы #распределенные_системы #разработка_под_linux #личный_опыт

Как мы накормили драконов (и заработали кучу золота)

Как мы накормили драконов (и заработали кучу золота) Старейшины говорят, что это история о масштабировании SaaS-приложения, но я таких слов не понимаю — слишком заумно. Для меня это история о золоте, драконах с всё возрастающим аппетитом и фермерах, которые кормят этих драконов. Начиналось всё просто: несколько драконов регулярно прилетали к нашему городу, мы готовили им еду из продуктов с нашей фермы, они платили золотом. Все были довольны. Но драконы росли, их аппетиты увеличивались, появлялись новые голодные гости... Что делать, когда одна ферма больше не может прокормить всех? Как не дать городу сгореть от драконьего гнева? Зачем строить заморские колонии и создавать параллельные измерения? За 10 лет наше королевство прошло путь от маленького города с одной фермой до федерации независимых государств, специализированных поселений и городов в параллельных мирах. И да, драконы всё ещё голодны. Это сказка о том, как накормить растущих драконов и не потерять при этом ни золота, ни головы. С картинками, моралью и счастливым концом. Узнать, как накормить драконов

https://habr.com/ru/articles/918696/

#масштабирование #распределенные_системы #монолит #saas

Как мы заменили сотни Join’ов на один РТ-процессинг с 1kk RPS

Как связаны скидки, пользовательские пути и огромные массивы данных в Яндекс Рекламе? Привет, Хабр! Меня зовут Максим Стаценко, я работаю с базами данных и яростно в них копаюсь с 2010 года, а в Big Data — с 2016. Сейчас работаю в Яндексе в DWH поиска и рекламы. Мы работаем с ОЧЕНЬ большими данными. Каждый день миллионы пользователей видят рекламу Яндекса, а наши системы обрабатывают огромные объёмы данных. Чтобы реклама работала эффективно, нам нужно в каждый момент времени иметь максимально полную информацию об истории жизни рекламного объявления, а значит нужно каким-то образом передавать данные от одного события к другому внутри рекламной воронки. Расскажу, как мы решали эту проблему.

https://habr.com/ru/companies/oleg-bunin/articles/884560/

#ytsaurus #mapreduce #olap #oltp #антифрод #распределенные_системы #оптимизация #обработка_данных #хранилища_данных

Как консолидировать данные из разрозненных хранилищ с помощью Tarantool CDC

Компании часто сталкиваются с необходимостью переливать данные между системами. Но нередко это превращается в настоящий квест: форматы данных могут различаться, для интеграции инструментов может не быть готовых коннекторов, самостоятельно гарантировать консистентность данных в целевой системе может быть сложно или невозможно. Поэтому подобные задачи редко обходятся без применения CDC (Change Data Capture). Меня зовут Андрей Капустин. Я менеджер продукта Tarantool CDC в компании VK Tech. В этой статье я расскажу о Tarantool CDC и о том, как инструмент помогает консолидировать данные из разрозненных хранилищ, в том числе проприетарных СУБД, обеспечивая прозрачность, высокую консистентность и скорость. Как разрабатывался Tarantool CDC

https://habr.com/ru/companies/vktech/articles/913352/

#Tarantool #архитектура #отказоустойчивость #postgresql #высокопроизводительные_вычисления #распределенные_системы #субд #Tarantool_Queue_Enterprise #Tarantool_CDC #change_data_capture

Распределённые транзакции в микросервисах: от SAGA до Two‑Phase Commit

Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем – согласованность данных и транзакции . В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных. Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC) . Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel) , паттерн Outbox , а также кратко упомянем eventual consistency , транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

https://habr.com/ru/articles/906484/

#sql #nosql #базы_данных #микросервисы #распределенные_системы #распределенные_транзакции #программирование #программное_обеспечение #rest #http

Основные паттерны микросервисной архитектуры: Strangler Fig, API Gateway, Service Mesh и другие

Микросервисная архитектура стала де-факто стандартом для построения современных масштабируемых приложений. Вместо единого монолитного приложения система разбивается на набор мелких независимых сервисов, каждый из которых отвечает за свою четко обозначенную функцию. Такой подход позволяет упрощать разработку и развертывание отдельных компонентов, повышать отказоустойчивость и масштабируемость системы. Однако переход к микросервисам и их эффективное использование сопряжены с рядом сложных задач. Для их решения в практике выработаны архитектурные паттерны – типовые подходы и шаблоны проектирования. В данной статье мы разберем несколько ключевых паттернов, связанных с микросервисами. Речь пойдет о паттернах миграции и интеграции (таких как Strangler Fig – «удушающее дерево» и API Gateway ), о сетевых и структурных паттернах ( Service Mesh , Sidecar ), о шаблонах работы с данными ( Database per Service , CQRS ) и об особом подходе к хранению состояния ( Event Sourcing ). Для каждого паттерна мы рассмотрим его суть, назначение, примеры использования, а также плюсы и возможные сложности. К некоторым паттернам приведены упрощенные диаграммы и фрагменты кода, чтобы иллюстративно показать, как они работают на практике.

https://habr.com/ru/articles/904954/

#java #net #python #микросервисы #распределенные_системы #паттерны_проектирования #антипаттерны #распределение_трафика #распределенные_транзакции #высокая_производительность