Привет! Меня зовут Сергей Киселёв, я Head of Development Platform в MWS Cloud Platform. В 2023 году я пришёл собирать команду Development Platform (DevP) для разработчиков нового облака. Эта статья написана по следам моего доклада «Как с нуля построить Development Platform в отдельно взятой компании» на DevOops 2024. Далее расскажу о том, почему мы заботимся об общем коде, растим культуру разработки и почему только разработчик может сделать инфраструктуру для другого разработчика.
Apache Kafka — это основа современных распределенных систем, обрабатывающий триллионы событий ежедневно. Но что происходит, если сообщение потерялось, пришло дважды или нарушилась логика бизнес‑процесса? Гарантии доставки в Kafka — это страховка от хаоса в условиях высокой нагрузки и сбоев.
В этой статье мы разберем три вида гарантий доставки сообщений на примерах.
При масштабном веб‑парсинге прокси — это не просто «много дополнительных IP адресов»: это ключевой компонент, позволяющий обходить защиты сайтов и распределять нагрузку. Без продуманной системы прокси, вы будете тратить все время на реанимацию или замену заблокированных IP адресов. Проблемы могут возникать не только из‑за количества запросов, но и из‑за их распределения и автоматизации: при переходе к большим объемам критичен переход от «одного рабочего скрипта» к распределенной архитектуре.
В этой статье мы подробно расскажем о пути перехода платформы контейнеризации dBrain.cloud с MaaS на Metal³. Основная задача, которую решают оба этих проекта, состоит в установке операционной системы на серверы платформ. Озвучим причины, по которым мы искали альтернативные решения, и объясним, чем Metal³ превосходит MaaS.
Хочу поделиться историей создания Telegram-бота, который изменил мой подход к домашнему кинотеатру. Все началось с банальной лени — мне надоело каждый раз заходить на компьютер, искать торрент, скачивать фильм, а потом думать, как его передать на телевизор.
Идея была простая: что если можно будет просто отправить ссылку в Telegram и получить готовый к просмотру фильм?
В этой статье я расскажу, как из простой идеи вырос медиа-сервер с DLNA, как я переходил с Python на Go и почему теперь этим ботом пользуется вся моя семья и гости.
Ваш проект взлетел. Первые пользователи превратились в тысячи. Тысячи стали десятками тысяч. Метрики в дашбордах рисуют красивую кривую, устремленную вверх. Но есть и другие кривые, которые ползут вверх с не меньшей скоростью. Время ответа сервера. Количество ошибок 502 и 504.
То, что летало на ста запросах в секунду, начинает задыхаться на десяти тысячах. Это не ошибка, это физика. Архитектура для этих двух миров — это как велосипед и грузовой поезд. Они оба едут, но задачи у них разные. Так что давайте забудем про теорию и посмотрим, где обычно рвется и как это чинить, чтобы не переписывать все с нуля каждый раз, когда у вас прибавляется нолик в статистике пользователей.
Иногда продуктовая фича живёт в приложении «для галочки». Пользователи вроде бы ею пользуются, команда её не развивает, а аналитики не могут толком оценить влияние на метрики. Так было с нашим старым механизмом поиска ближайших машин в каршеринге — «Радаром». Он просто пинговал координаты и сообщал, когда рядом появлялась машина. Никакой логики приоритизации, никаких фильтров, никакого резерва — сырая идея без развития.
В статье рассказываем, как мы заново осмыслили и пересобрали фичу:
• продакт Настя Голованова — о том, как мы нашли value, перезапустили механику и успели в сроки размещения наружной рекламы;
• разработчик Михаил Ефанов — про то, как превратить монолит в стабильную архитектуру.
Полезно будет всем, кто работает на стыке развитии продукта и инженерии: от старта фичи до релиза и плана развитии.
Сообщения в RabbitMQ — это основные единицы данных, которые передаются между продюсерами и потребителями. Понимание их структуры и возможностей позволяет эффективно управлять потоком данных в распределенных системах. В этой статье мы разберем анатомию сообщений, обязательные и опциональные компоненты, а также реализуем пример отправки объекта с настройкой свойств
В мире криптовалют анонимность и безопасность являются ключевыми элементами. Когда речь идет о крипто-свапалках, эффективность обработки данных в реальном времени играет решающую роль для обеспечения высокого качества сервиса. В этой статье расскажем, как мы реализовали масштабируемую архитектуру для обработки данных на платформе risetocrypto с использованием передовых технологий.
Привет, Хабр! На связи Олег Оболенский, я руководитель направления проектирования и разработки VK Tech. В компании я отвечаю за разработку корпоративного ПО, а мои команды также оказывают комплекс профессиональных услуг по адаптации наших решений к бизнес-требованиям заказчиков. Мы реализуем облачные и гибридные проекты любой сложности и масштаба, переносим данные, поддерживаем наши сервисы, помогаем оптимизировать затраты на ИТ, управлять виртуальной инфраструктурой. Из каждого сложного внедрения мы стараемся выносить пользу, чтобы обогащать продукты новыми возможностями. Кейс, про который мы сегодня расскажем, будет на стыке работ сразу нескольких подразделений.
Проектирование отказоустойчивых и масштабируемых систем — это всегда баланс между теоретическими концепциями и реальной практикой. В этой статье мы разберём, как проектировать событийно-ориентированные архитектуры, которые могут выдержать пиковые нагрузки, справляться с асинхронной обработкой и обеспечивать стабильную работу при любых условиях. Мы рассмотрим ключевые паттерны, такие как шардирование, методы мониторинга и асинхронную обработку данных, а также обсудим распространённые ошибки, которые могут привести к сбоям, и как их избежать.
На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т. д.
Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую‑то ветку с разрабатываемой фичей или исправлением бага в ветку, которая «привязана» к окружению и дальше наш код деплоится в кластер. Думаю, для многих — это уже стандартная история.
Давайте представим, что нужно сделать задачу, относящуюся к какому‑нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на «боевые». Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы «ковыряем» и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:
Как получить прозрачность в бизнес-процессах, если архитектура строится на микросервисах и событийных потоках? В своей статье Бернд Рюкер, сооснователь Camunda, делится практическими подходами к отслеживанию и управлению процессами в распределённых системах. Он объясняет, как переход от простого мониторинга событий к полноценной оркестрации помогает лучше понимать происходящее, своевременно реагировать на инциденты и сохранять контроль над сложными бизнес-операциями. В статье разбираются плюсы и минусы различных подходов — от Elastic-подобного мониторинга до использования движков рабочих процессов, а также рассматривается важность баланса между оркестрацией и хореографией.
Очень часто в проектах необходимо использовать передачу сообщений между компонентами распределенной системы по определенным правилам. И перед разработчиком встает вопрос — какой инструмент наиболее эффективно можно использовать для этого? И сегодня мы рассмотрим брокер сообщений, который позволяет это делать «прямо из коробки» и это будет RabbitMQ.
RabbitMQ — это популярный брокер сообщений, который реализует стандарт AMQP и который позволяет эффективно управлять коммуникацией между сервисами через очереди. И в этой статье мы разберем основные типы обменников (exchange): Direct, Topic, Headers и Fanout, которые напрямую участвуют в процессе маршрутизации, а также приведем примеры их настройки в Spring Boot.
Привет, Хабр!
Сегодня разберём один из самых гибких инструментов в RabbitMQ — topic exchange. Именно он позволяет не просто отправить сообщение «куда‑то», а превратить очередь в маршрутизатор уровня BGP, но только внутри твоей системы.
Что отличает архитектора от кодера? Не должность, не титул, не стаж.
Ответ - в мышлении. В том, кто видит систему целиком, предвидит цепные последствия и способен сказать "нет" быстрому решению, которое отравит код через полгода. Эта статья - честное и местами болезненное размышление о системном мышлении, архитектуре и точке невозврата, после которой разработчик уже не может смотреть на код по-старому.
Микросервисная архитектура позволяет разрабатывать высоконагруженные, распределенные и гибкие приложения. Но цена разработки таких систем очень высока, и решая выше указанные проблемы, разработчики сталкиваются с другими проблемами, которых либо нет в монолитных приложениях, либо они не так сильно в них проявляются: сложный обмен данными между сервисами, денормализация и консистентность данных, инвалидация кэша и интеграция с внешними системами.
Решать выше перечисленные проблемы можно разными способами. В своей работе в компании Greensight в качестве senior backend developer при разработке заказных проектов на базе Open Source платформы Ensi, я с коллегами перепробовал множество решений.
Данная статья описывает практическое использование Kafka в микросервисных приложениях для решения этих проблем.
За 10 лет, что существует Serverless‑подход, бессерверные функции стали для многих разработчиков чем‑то привычным и удобным. С их помощью можно быстро написать несколько строк кода для реализации конкретной бизнес‑логики и задеплоить, не думая о развёртывании, настройке и обслуживании инфраструктуры. Нужный код запустится автоматически при срабатывании триггера, как это принято в событийно‑ориентированной архитектуре. Но если таких функций в приложении потребуется очень много — что поможет сохранить нужную скорость работы и другие преимущества Serverless?
Меня зовут Сергей Ненашев, последний год я разрабатываю в Yandex Cloud сервис бессерверных функций Cloud Functions. В нашем облаке с ним можно запускать код в виде функции без создания и обслуживания виртуальных машин.
Пожалуй, важнейший процесс в этом сервисе — это обработка внешнего входящего запроса. Чтобы эта конструкция работала с минимальными задержками, нам понадобилось хорошенько продумать архитектуру обработки запросов и применить пару трюков. Я расскажу, как команда пришла к тем решениям, что работают сейчас, а также покажу, на что обратить внимание самим пользователям, чтобы запрос пробегал по всей инфраструктуре не более 10 мс.
Привет, Хабр! С вами команда разработки платформы Russ Online Группы компаний Russ (входит в объединенную компанию Wildberries & Russ). Мы хотим поделиться историей о том, как от монолитной системы мы перешли к микросервисной архитектуре и облачным решениям на базе Kubernetes и S3. Эта трансформация создала фундамент для дальнейшего развития платформы и внедрения новых сервисов.
Нагрузка на базы данных растет с каждым днем. Как быстро масштабировать ресурсы, расширять базы данных и следить за их состоянием в UI, не вникая в подкапотные движения Kubernetes? Приводим кейсы.
