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

В современном мире все больше IT-проектов переходят на микросервисную архитектуру. При таком подходе появляется ряд вопросов — как избитых, так и не самых очевидных. Как обеспечить корректную работу системы из большого числа микросервисов? Каким способом и с помощью каких технологий разворачивать этот зоопарк? Как отследить узкие места в производительности?

Меня зовут Максим, я Java-разработчик в SimbirSoft. Сейчас работаю на финтех-проекте, занимаюсь созданием бизнес-логики, иногда подключаюсь к различным техническим задачам. В этой статье я кратко и понятно опишу, что такое трассировки, как устроен Jaeger, а также расскажу про недавно появившийся новый стандарт распределенного трейсинга и мониторинга — OpenTelemetry.

Материал будет полезен начинающим разработчикам. Из него вы узнаете, как с небольшими усилиями подключить трассировки к своему проекту. Речь пойдет об инструменте из большого блока «‎Наблюдаемость» (Monitoring), а конкретно — о трассировках.

Не секрет, что микросервисы мало запустить. За их работой нужно следить, чтобы не было сбоев, а следовательно и недовольных пользователей. Для этого, нужны системы мониторинга и логирования. Команда платформы dBrain собрала свой универсальный стек системы мониторинга. Сегодня расскажем, какие проблемы возникают с мониторингом и как их решить.

Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.

Привет, Хабр! На связи Андрей Чернов, Java-архитектор микросервисов в СберТехе. Эта статья — продолжение материала о том, как мы развиваем Platform V SessionsData — высокопроизводительное распределённое in-memory хранилище для общего контекста сессионных запросов key-value, которое СберБанк Онлайн использует в качестве микросервиса на своём server side.

В первой части мы говорили о том, почему решили создать собственный микросервис и как он помогает справляться с нагрузкой СберБанк Онлайн. В этой разберём, как мы достигаем высокой доступности сервиса. Будет и третья часть: расскажем, какие доработки помогут нам и дальше развивать Platform V SessionsData.

Подробно и на примере рассматриваем проблему deployment bottleneck и как она появляется. Рассказываю как можно легко и быстро настроить реплицируемые stage-окружения для ее решения, дав разработчикам делать свою магию параллельно и независимо друг от друга.

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

Микросервисная архитектура - это подход к построению приложений, в котором они разбиваются на более мелкие и управляемые блоки (микросервисы), каждый из которых выполняет определенную функцию. Такой подход отличается от монолитных приложений, где все компоненты связаны тесно между собой и в одном кодовом базе.

На днях я решил сделать под все свои pet-проекты собственный SSO сервис, дабы не заморачиваться каждый раз с авторизацией и аутентификацией. Возиться с этим особо долго мне не хотелось. Все таки это для pet-проектов. Поэтому выбор пал на Spring Security. Мне давно уже было интересно посмотреть в действии как на Spring Boot 3, так и новый Spring Authorization Server версии 1.x.x. В данной статье речь пойдёт о проблемах и их решениях при построении собственного SSO. А также я поставил себе ряд интересных требований, с которыми я постараюсь справиться и рассказать о своём опыте.

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

Отдельно расскажу про особенности serverless-подхода. А если вы хотите узнать о serverless больше, погрузиться в DevOps-практику и посмотреть демо по управлению контейнерами — жду вас на вебинаре «Easy to use: управление контейнерами в облаке», который пройдет 30 мая в 11:00 мск. Приходите — пообщаемся в онлайне ?

WARNING: длинная вступительная часть. Если хотите перейти сразу к делу - листайте до Getting Started.

Можно ли построить удобный для всех pipeline, приложив усилия один раз, а не 100? Об этом расскажет Виктория Вольферц. Она работает в БКС DevOps-инженером в управлении микросервисной архитектуры. БКС предоставляет брокерские и банковские услуги для клиентов. Их основные продукты — это мобильное приложение БКС Мир Инвестиций и веб-кабинет для клиентов.

Виктория поделится опытом своей компании, как им удалось решить проблему больших временных затрат на релиз-менеджмент и Time to Market с помощью подключения проектов к CI/CD. Она расскажет о том, как они автоматизировали процессы и закрыли слабые места.

1. В монолите концентрировалось большое количество бизнес-процессов, которые охватывали сразу несколько потребителей: пользователей облачной платформы, сейлз-менеджеров (через CRM-систему), администраторов, обработчиков метрик. Получилась такая одна большая точка отказа сразу для 4 групп бизнес-процессов.
2. Каждый бизнес-процесс потребляет свой объем ресурсов. Например, для обработки метрик нужно 5 подов (чтобы запараллелить и ускорить обработку), для администрирования хватит и одного. Так как у нас все в одном сервисе, при масштабировании монолита мы будем ориентироваться на самый «прожорливый» бизнес-процесс. Часть ресурсов будет просто простаивать.
3. Хотелось добиться гранулярности, чтобы независимо писать и деплоить код для каждого бизнес-процесса. И не переживать, что какие-то изменения в одном бизнес-процессе неожиданно отрикошетят в соседний.

Всем привет! Меня зовут Женя, я разработчик из QIWI, занимаюсь созданием внутренних сервисов. Совсем недавно мы провели эксперимент по использованию микрофронтендов, и я хочу поделиться с вами опытом использования. Это вторая часть серии статей про наш опыт микрофронтов.

Всем привет! Меня зовут Женя, я разработчик из QIWI, занимаюсь созданием внутренних сервисов. Совсем недавно мы провели эксперимент по использованию микрофронтендов, и я хочу поделиться с вами опытом использования. В качестве основы для построения системы мы выбрали фичу Webpack - Module Federation.

В последнее время я вижу много хайпа вокруг Kubernetes. Кажется, что он везде и всюду, а если кто-то его еще не использует, то он безнадежно отстал. Но странно принимать решение о внедрении технологии только на основе ее популярности в СМИ. Давайте разберемся: а вот лично вам правда нужен K8S?

Для чего используют Kubernetes? 

Как правило, внедрение Kubernetes означает использование микросервисной архитектуры. Конечно, чтобы реализовать микросервисы, не обязательно внедрять Кубернетес. Но очень часто обращаются именно к нему.

Тогда сформулируем вопрос иначе: а вам правда нужны микросервисы? И потом вернемся к предыдущему вопросу.

Достоинств у микросервисной архитектуры много. Например: 

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

Где-то раз в год возникает желание посмотреть: если сейчас начинать приложение с нуля, то что бы обязательно в него включил? Кроме очевидной практической ценности (обычно начинается новый проект) это так же позволяет осознать какой архитектурный опыт получен за последнее время.

Необходимость шаблона сверх https://start.spring.io вызвана следующими типами доработок:

Сегодня Kubernetes — одно из наиболее оптимальных решений для работы с микросервисной архитектурой. Но это не традиционная комплексная система PaaS. В ванильный K8s входит несколько стандартных компонентов, которые отвечают только за минимальный набор необходимых функций. Но для эффективной работы приложений и деплоя продуктовой среды необходимо множество дополнений — CNI, СSI, DNS, Ingress контроллер, внешние LB и т. д. Цель нашей команды — готовая для комфортной работы с кластером PaaS‑платформа. В этой статье мы расскажем, как готовим Kubernetes в dBrain.cloud, чтобы ее достичь.

Этой весной в чатах и сообществах dotnet (не забываем #DropTheDot) обострились анти-медиаторные настроения. Поначалу меня это забавляло, потом удивляло: люди подхватывают лозунги, не пытаясь разобраться в вопросе. Квинтэссенцией обострения стал доклад Андрея Парамонова "MediatR не нужен”, шокирующий своей категоричностью аргументов. В докладе были зерна истины, но они к концу так и не проросли.

Желание прорастить эти зерна и мой крайне положительный опыт использования медиатора в проектах разного размера смотивировали меня написать данную статью. Статья основана на личном опыте и наполнена эмоциями, за это заранее извиняюсь ? Она будет интересна скорее людям, которые уже знакомы с медиатором, встречались с ним в теории или на практике.

В своём прошлом посте я рассказал теорию своего подхода к декомпозиции систем на модули. Теперь пришло время проверить её на практике.

Кэмп - реальный проект, который стоил семизначную сумму для заказчика, выполнялся командой из 12 человек (включая двух бакэндеров) и сейчас запущен в промышленную эксплуатацию. Суммарно на выполнение проекта было затрачено 5500 человеко/часов, из которых 950 - на бакенд.