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

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

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

Микросервисная архитектура в последние годы приобрела большую популярность. Но, несмотря на все ее преимущества, у нее есть и некоторые проблемы. Одна из них — сбор необходимых данных для передачи во фронтэнд. Здесь напрашивается простое и интуитивное решение — паттерн API composition (композиция API). Это решение данной проблемы, но не идеальное. Например, в случае высоконагруженных и высокодоступных систем, вызов нескольких сервисов для создания только одного представления может быть неприемлемым. Нужно придумать что‑то другое. Давайте попробуем CQRS.

Привет! Меня зовут Дима Вагин, я бэкенд-инженер в Авито. Сегодня расскажу, как мы работаем с БД PostgreSQL из Go. Покажу, какие библиотеки и пулеры соединений мы используем для доставки в код параметров подключения и как мы их настраиваем. А ещё расскажу про проблемы, к которым приводит отмена контекста, и о том, как мы с ними справляемся.

Привет! Меня зовут Даниил Гранкин, я разработчик внутреннего бэкенд-юнита в Wrike. В этой статье я поделюсь техническими подробностями разработки Wrike Lock — основного механизма шифрования данных в нашем продукте. А также расскажу, для чего мы используем Encryption as a Service (EaaS) и какие проблемы решаем с его помощью. Эта статья будет полезна, если вы ищете способы дистрибуции ключей шифрования, но готовые решения вам не подходят.

Если вам доводилось быть в славном городе Мадриде, что на Испанщине, наверняка в галерее Прада вы видели картину Босха «Сад земных наслаждений», которая демонстрирует типичный рабочий день системного архитектора. Но на самом деле на первый день после продакшена больше похоже...

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

Но для начала поговорим о том, как было плохо раньше.

Привет, Хабр! Меня зовут Владимир Калугин, я руковожу бэкенд-разработкой в МТС Travel. Сегодня расскажу про KrakenD, готовое решение, которое мы используем для реализации API-шлюза, важной штуки для продуктов с микросервисной архитектурой. Уверен, наш опыт может пригодиться разработчикам из других сервисов.

Привет! На связи Олег Казаков из Spectr.  Мы занимаемся разработкой цифровых сервисов, в том числе высоконагруженных систем с микросервисной архитектурой и большим количеством различных интеграций.

В статье расскажу об одном из кейсов при работе над проектом с микросервисной архитектурой — реализации единой системы авторизации и аутентификации.  Поговорим про теорию, рассмотрим различные стратегии реализации и особое внимание уделим паттерну API Gateway.

❯ Введение

Если вы когда-нибудь сталкивались с продажами, то наверняка знаете про такое понятие как "боль клиента". Означает оно, что у каждого клиента есть потребности, определив которые, ему можно продать товар либо услугу для решения его задач.

Данная статья и родилась вследствие того, что на текущем проекте в нашей команде разработки есть боль: когда на беке вливают МР в ветку develop, то стенд падает на время деплоя. Основные участники, испытывающие эту боль — фронтенд разработчики и аналитики, которым чаще всего приходится взаимодействовать с бекендом. И во время недоступности стенда непонятно, деплой идёт или стенд упал из-за ошибки.

Нет, конечно, можно зайти в Gitlab, проверить, идёт ли сейчас деплой или посмотреть логи контейнера. Но для этого нужно быть в курсе, из-за деплоя каких конкретно микросервисов (естественно мы говорим о микросервисной архитектуре) стенд может быть временно недоступен. Ну и плох тот программист, который не хотел бы упростить жизнь себе и коллегам, автоматизировав при этом чаво-нибудь! :)

Привет, Хабр! Меня зовут Евгений Лабутин, я разработчик в МТС Digital. Расскажу вам о том, как мы на нашем проекте МТС Твой бизнес собираем логи с клиентских веб‑приложений. А еще обсудим вспомогательный микросервис логирования, который мы вывели в Open source, и поговорим о том, как устроено логирование в принципе.

Однажды один тимлид поставил передо мной задачу реализовать механизм взаимодействия пользователя через веб-интерфейс с микросервисами через единую точку входа с использованием FastAPI и RabbitMQ. Спешу поделиться с тобой, мой читатель, тем, что у меня получилось.

Эта статья подготовлена на основе доклада «Микросервис головного мозга» Михаила Трифонова, Lead frontend Cloud и основателя frontend-сообщества TeamSnack. Мы разберём когда необходимы микрофронты, каким должен быть технологический стек, как нарезать мироксервисы и какие существуют стандарты при построении микросервисной архитектуры.

Эта статья, по сути, продолжение первой части «Микросервис головного мозга. Пилим всё, что движется». В ней Михаил рассказывал, как ему с командой удалось ускорить разработку с помощью микросервисного подхода. Они поэтапно строили микросервисную архитектуру, распилили монолит, UIKIT и создали архитектуру.

Привет, Хабр! Этот пост подготовили два разработчика Росбанка — Максим из команды развития фронт-офисных систем и Никита из команды интернет-банка. Речь пойдет о том, как мы делаем микрофронтенды. Сначала расскажем про опыт интеграции в существующий проект, а потом про внедрение с нуля.

Когда нужно делить фронтенд-часть приложения на микросервисы? Какой стек использовать? И какие стандарты использовать, чтобы не выстрелить себе же в ногу при переходе на микрофронты? Михаил Трифонов (Lead Frontend в компании Cloud) ранее уже выступал с докладами о микросервисах, получил фидбек от сообщества и с его учётом сделал новый доклад на HolyJS. А теперь мы (организаторы HolyJS) сделали для Хабра текстовую версию этого выступления.

Странно было бы делать доклад про микросервисы монолитным. Поэтому каждая глава этого поста является изолированным, слабо связанным кусочком. Так что можете читать по отдельности, а можете — целиком.

Всем привет. Меня зовут Женя, я работаю, как это сейчас модно говорить, DevOps-инженером в компании Garage Eight. 

В этой статье я бы хотел поделится опытом внедрения и эксплуатации брокера сообщений NATS в нашей инфраструктуре — настолько понравилась эта технология. 

Однажды перед нами встала задача максимально быстрой доставки сообщений из пункта A в пункт B. Условия были таковы:

* Перед тем как сообщение достигнет пункта назначения, оно проходит ряд сервисов;

* Каждый сервис выполняет определенный набор действий над этим сообщением;

* Скорость прохождения сообщений через весь путь должна быть минимальной;

* Брокер сообщений должен работать стабильно 24\7.

В статье я расскажу, как мы это делали

В этой статье я расскажу о собственном проекте ориентированном на микросервисную архитектуру. Этот проект вырос из идей и подходов, которые я применял на протяжении нескольких лет работы связанных с переводом крупного монолитного проекта на микросервисную архитектуру. Я не буду заострять внимание на паттерны, концепции и базовые принципы МСА, поскольку информации подобного рода достаточно в сети. Моя цель - предоставить читателю конкретный вариант реализации микросервисного бэкенда на основе фреймворка busrpc.

Привет! Меня зовут Миша, я работаю в Ozon Tech — руковожу направлением базовых сервисов в платформе. Ozon сегодня — это порядка 4000 разработчиков и более 3500 сервисов. Разработка постоянно развивается, количество сервисов увеличивается, и одна из сложных задач — это найти удобный для всех способ управлять тем, что происходит под капотом. 

Для этого мы сделали платформу: это внутренние стандарты, сервисы, процессы, инфраструктура для разработки. Можно сказать, что это такой «сервис для продуктовых разработчиков», который предоставляет удобные инструменты во все команды, обеспечивает единообразие подходов в разных командах, помогает внедрять изменения и новые технологии. Для нас платформа теперь — основа для разработки, на ней строятся все информационные системы, и сложно представить Ozon без неё.

В этой статье я расскажу, как и на каких принципах мы построили нашу платформу, зачем она нужна и куда движется. Будет полезно и интересно всем, кто связан с разработкой больших приложений с множеством микросервисов. 

Всем привет!
Меня зовут Андрей Калинин, я директор по IT сервиса кикшеринга «Юрент» – вы наверняка видели наши фиолетовые самокаты во многих городах. У нас есть интересная особенность по сравнению с другими сервисами: в нашем парке не 1-2 модели самокатов, а с десяток разных моделей и поколений. Внутри мы называем это многообразие «наш зоопарк». Масштабировать «зоопарк» (сейчас это уже больше 80 тыс. самокатов) было нетривиальной задачей с точки зрения IT-разработки. Да и вообще работа с «железом» – это иногда сложно и больно, но всегда интересно.

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