Микросервисы *

Привет, Хабр! На связи Олег Оболенский, я руководитель направления проектирования и разработки 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? Приводим кейсы.

Привет, хабр!

Меня зовут Кирилл, и на протяжении последних двух лет я мечтал научиться проходить System Design интервью. Но только недавно взялся за дело всерьёз.

Изучив различные хранилища данных, я наконец-то смог систематизировать свои знания. И хочу поделиться этой структурой с вами, чтобы рассказать, какие бывают хранилища данных и в каких случаях их лучше всего использовать.

Мне кажется, что уже есть сотни разных статей на эту тему, но каждый раз мне чего-то не хватало. Поэтому я решил написать свою статью, в которой покажу, как я реализую авторизацию и аутентификацию в своих проектах. Это именно гайд: вы можете взять готовый код и адаптировать его под свои нужды. В рамках статьи будут использоваться Ory Hydra и Ory Kratos, Apache APISIX в качестве API Gateway и несколько микросервисов на Golang. Всё это будет работать в Docker, чтобы вы могли легко запустить и поиграться.

Kubernetes давно стал стандартом для масштабируемого управления микросервисами, но использование его возможностей не всегда так очевидно, как кажется.

В этой статье мы рассмотрим, как расширение функционала K8s с помощью пользовательских ресурсов помогает решать инфраструктурные задачи, позволяя разработчикам быстро запускать и масштабировать сервисы без лишних хлопот. Однако с этим подходом приходят и свои проблемы, такие как ограничения в хранении больших объёмов данных. Разберемся, что стоит за этими вызовами, и почему HariKube — перспективное решение для эффективного распределения данных в Kubernetes.

Проектирование и поддержка высоконагруженной платформы для букмекерской конторы almsports.net потребовало особого подхода к обеспечению стабильности, отказоустойчивости и производительности. Мы, как команда разработчиков, ставили перед собой цель обеспечить не только стабильную работу, но и гибкость для масштабирования, отвечая на растущий трафик. В этом посте я поделюсь опытом того, как с использованием DevOps практик и CI/CD процессов мы смогли достичь 99.99% аптайма и эффективно обслуживать миллионы запросов в день на платформе almsports.

Привет, хабровчане! Я Алиса, тимлид в e-commerce агентстве KISLOROD.

Сегодня расскажу, как мы вырвались из цепких лап монолита с помощью Headless и API-First архитектуры, ускорили разработку и дали бизнесу крылья. Это не просто про технологии, а про то, как не сойти с ума от бесконечных правок и при этом ускорить запуск фич. Мы все еще на PHP, под капотом Bitrix, но перестали латать шаблоны и начали строить настоящую платформу. Погнали разбираться: что это, зачем и как не облажаться.

Расскажу про Python-библиотеку для гибкого чтения конфигураций с возможность переиспользования и переопределения элементов

Я ненавижу руками создавать бойлерплейты. Любые. Нет, LLM-ки тут тоже не помогут: им надо писать промпты (а потом ещё проверять, что оно там нагенерировало). Мне всегда хотелось, чтобы остов приложения задавался конфигурацией, а я бы только добавлял бизнес-логику. Буквально, в уже сгенерированные для неё места.

Именно в такой парадигме написана моя библиотека finitomata, в которой конфигурация конечных автоматов задаётся текстовым представлением (PlantUML/Mermaid), а бизнес-логика просто распихивается по колбэкам переходов. Но мне этого оказалось мало, и я решил обернуть в такие же абстракции хранение и подписку на изменения.

Так родилась библиотека (пока не опубликована, доступна только в исходниках) persistomata.

Привет! Меня зовут Влад и занимаюсь Python backend-разработкой. Довольно долго я работал над большим продуктом, который объединял несколько команд разработки. В нем было много микросервисов, базовые фичи кочевали из одного в другой, и часто разработчики делали одни и те же инфраструктурные компоненты по-разному. А когда переходили с одного микросервиса на другой, им приходилось долго осмыслять кодовую базу нового решения.

Код полнился ошибками, а разработчики тратили время на их отладку и исправление. Так мы вживую воплотили печальную статистику: разработчики ПО в среднем тратят на написание кода лишь [52 минуты в день](https://www.software.com/reports/code-time-report), остальное — исправление ошибок и другие сопутствующие задачи.

Поэтому мы собрали небольшую команду разработчиков и вместе сделали шаблонизатор. Если проблема знакома, читайте дальше — расскажу, как он работает, поделюсь кодом и советами о том, как его эффективно применять.

Микросервисы перевернули игру в разработке приложений. Они сулят гибкость, отличную масштабируемость, командам — больше независимости. Но вот переход на них принес с собой и новые головные боли. Особенно когда дело доходит до развертывания. Управлять кучей мелких, отдельно выкатываемых кусочков — задачка та еще. Старые приемы тут часто пасуют. Нужны свежие идеи, другие инструменты, а главное — по‑другому смотреть на вещи.