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

❯ Введение

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

Данная статья и родилась вследствие того, что на текущем проекте в нашей команде разработки есть боль: когда на беке вливают МР в ветку 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-разработки. Да и вообще работа с «железом» – это иногда сложно и больно, но всегда интересно.

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

Вообще-то мы хотели назвать статью «Неудачный опыт…», потому что, как будет рассказано ниже, с использованием Tyk всё оказалось не так просто. Но, во-первых, даже неудачный опыт — это тоже опыт. Во-вторых, нам не хотелось бы превращать заголовок в спойлер, чтобы заинтересованные специалисты всё же имели стимул прочитать статью, а не делать споропалительных выводов из одного лишь названия. Тем более с развитием Tyk многие выявленные проблемы могут стать неактуальными.

Привет, Хабр! Меня зовут Никита Летов, я тимлид бэкенд-разработки мобильного приложения Росбанка для физических лиц. Этот пост входит в серию постов по разработке бэкенд-микросервисов на Java и Spring и является адаптацией моего доклада с JPoint 2022. 

Также хочу предупредить, что данный пост не cookbook и не предоставляет идеально приготовленное решение какой-либо бизнес-проблемы. Это разбор одной технологии, которая при правильном использовании может помочь вам в решении реальной проблемы. А может и не помочь — всё зависит от ее природы.

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

Привет, Хабр.  

Меня зовут Саша, я занимаюсь разработкой инструментов мониторинга тестирования, но по факту ещё и исполняю роль руководителя направления QA в домене Маркетплейса, ответственном за создание всех карточек товаров на Ozon.  

Если вкратце, наша задача заключается в сопровождении селлера от этапа загрузки файла Excel, в котором есть сто тысяч пар носков, до момента, когда все эти носки окажутся на витрине Ozon. Очевидно, что мы занимаемся не только парсингом экселек — у нас есть и highload-сервисы раздачи контента, несколько стейт-машин, системы с мастер-данными всего Озона, и немалый отдел ML, так что мы регулярно сталкиваемся со сложными и нестандартными задачами, подход к решению которых, впрочем, мы всё-таки пытаемся стандартизировать. 

За последние полтора года, как наше направление отделилось от основной разработки Маркетплейса, QA-отдел вырос в пять раз, с 5 до 25 QA-инженеров. О том, как мы решали вопросы масштабирования команды и плакали пытались справиться с legacy-наследием в доставшихся нам процессах, подробнее расскажу под катом. 

Привет, я Михаил Ковалев, Python-разработчик в Точке.

Именно в Точке я впервые столкнулся с микросервисами и конкурентной средой. Разумеется, у меня не получилось сразу усвоить все боевые нюансы работы в новых условиях. С тех пор я прошёл непростой путь.

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

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

Здравствуйте! Меня зовут Дмитрий Моряков, и я ведущий системный аналитик в компании МаксимаТелеком. Теме миграции с монолита на микросервисную архитектуру (здесь и далее — МСА) за последние годы на страницах Хабра было посвящено немало материалов, поэтому я хотел бы сосредоточиться на узких аспектах этого процесса: выделении критической части при реализации пилотного проекта миграции на МСА и реализацию изоляции полученных микросервисов по данным.

Привет Хабр! Меня зовут Евгений Лабутин, я фронтенд-разработчик в МТС Digital. Расскажу вам о том, как мы приручили микросервисы на нашем проекте МТС Твой бизнес, зачем они нам вообще понадобились и какую выгоду мы от этого получили. Интересно? Добро пожаловать под кат!

"Отдайте этот функционал в другую системы - он относится к ним" - ворчал мой собеседник. Ему с пылом отвечали: "Так быть не должно. Мы сами должны его сделать!" Спор грозил затянуться до вечера. Ни одна из сторон не могла привести ни одного настоящего аргумента, почему новый функционал нужно поместить в ту или иную автоматизированную систему.

Проблема была в том, что никто не понимал как правильно делить системы на части и по каким признакам включать в них новые модули. У собеседников не было никакой единой простой методики.

Но методика на самом деле есть, и весьма неплохая. Называется она Предметно Ориентированным Дизайном (Domain Driven Design, DDD). С помощью DDD деление большой системы на (микро)сервисы становится простым и понятным.

Системы оркестрации контейнеров существенно упростили управление многокомпонентными системами, в том числе основанными на микросервисной архитектуре. Но остался открытым вопрос организации надежного обмена сообщениями между микросервисами, координации последовательности операций при распределенной архитектуре. В этой статье мы рассмотрим подход Incubating (CNCF)-проекта Dapr (Distributed Application Runtime) по использованию Sidecar-контейнеров в Kubernetes для реализации микросервисной архитектуры, основанной на событиях.