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

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

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

«Скажите, какие основные преимущества микросервисов и почему?». Вероятно, это самых популярный вопрос последних 6–10 лет на любом собеседовании для бэкенд разработчика. Каким-то чудом он даже обогнал: «Назовите три принципа ООП» и «Чем отличается класс от объекта».

На связи Игорь Латкин, управляющий партнер и системный архитектор в KTS. 

Мы на своём опыте разобрались в развертывании stateless- и stateful-сервисов, и теперь хотим поделиться с вами. Мы в KTS не раз создавали подобные инфраструктуры, перепробовали разные решения и выясняли, как построить эффективные процессы.

Сегодня мы поговорим о динамических окружениях (фича-стендах) для stateless- и stateful-сервисов, обсудим особенности и проблемы, которые могут возникнуть и возникали у нас.

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

Начиная с версии Kubernetes v1.7, проект Kubernetes преследовал амбициозную цель удаления встроенных интеграций облачных провайдеров. Хотя эти интеграции сыграли важную роль в раннем развитии и росте Kubernetes, их удаление было обусловлено двумя ключевыми факторами: растущей сложностью поддержания собственной поддержки для каждого облачного провайдера в миллионах строк кода Go и желанием сделать Kubernetes по-настоящему независимой от поставщика платформой.

После многих релизов, все интеграции облачных провайдеров были успешно перенесены из основного репозитория Kubernetes во внешние плагины. В дополнение к достижению первоначальных целей, удалось значительно оптимизировать Kubernetes, удалив около 1,5 миллионов строк кода и уменьшив двоичные размеры основных компонентов примерно на 40%.

Эта миграция была сложной и длительной из-за многочисленных затронутых компонентов и критических путей кода, которые полагались на встроенные интеграции для пяти первоначальных поставщиков облачных услуг: Google Cloud, AWS, Azure, OpenStack и vSphere. Для успешного завершения этой миграции пришлось построить четыре новые подсистемы с нуля:

Рассмотрим очередной популярный подход к проектированию систем для управления и координации выполнения бизнес-задач или процессов на основе событий. В общем случае это микс Хореографии и Оркестрации. Рассмотрим их подробнее.

Привет, Хабр. На связи Михаил, я бэкенд-разработчик в Clevertec. Моя работа связана с проектом, который начинался с создания личного кабинета клиента и развился в экосистему, растущую вместе с бизнесом. На его примере я расскажу, как можно изменять подход к CI/CD, чтобы не тормозить рост проекта и оптимизировать работу команды.

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

Начну с «исправления имен» как базы для совершенствования (меткое наблюдение конфуцианства) на примере того, как у нас переводится базовый принцип построения микросервисной архитектуры: «low coupling and high cohession». И как понимание терминологии помогает отличить профанов, изображающих с помощью птичьего языка некое знание, от действительно понимающих суть людей.

Прежде чем переходить к качественному переводу нужно понять контекст и суть термина в исходном языке. Если кратко low coupling это про то, что изменения 1 микросервисе по возможности не должны приводить к масштабным изменениям смежных и далее по цепочке микросервисов. А high cohesion говорит нам о том, что микросервис должен целостно закрывать явно выделенный кусок бизнес контекста. т. е. чтобы изменение бизнес контекста, требующее ИТ доработок в идеале (недостижимом как горизонт), приводило к доработке одного микросервиса. т. е. микросервис не настолько мал, чтобы бизнес задача была сильно больше его, и не настолько зависим от смежников, чтобы любая задача требовала перелопачивания всего ИТ ландшафта.

Собственно в этом суть микросервисной архитектуры, когда в микросервис упаковывается самодостаточный функционал, который можно относительно независимо развивать отдельной командой, с отдельным артефактом поставки и т. д. Где то здесь должны звучать буквы DDD. Но не будем — DDD слишком обширная тема, для небольшой заметки.

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

В моем опыте был случай, когда интеграция представляла собой связку около 15 систем, каждая из которых имела свою базу данных. Все сервисы разворачивались в k8s вручную, тестовые данные были неконсистентны, интеграции между сервисами приходилось настраивать вручную самостоятельно. Ни один сервис нельзя было замокать: каждый элемент влиял на тестируемую бизнес-логику. Я просто познавала дзен, разбираясь во внутреннем устройстве систем и следуя заранее составленному тест-плану. 

Меня зовут Катя Назмеева, сейчас я тестирую бэк в Lamoda Tech. В статье я предложу стратегии для успешного проведения интеграционного тестирования микросервисов и расскажу про инструменты, которые могут облегчить этот процесс. Обсудим, как организовать все таким образом, чтобы интеграционное тестирование не создавало задержек в новых релизах — и не заставляло QA страдать.

Один из наших длительных проектов — это крупное многопользовательское SaaS-решение (CRM-система) основанное на микросервисной архитектуре и развернутое в облаке Azure. Изначально это был MVP, где все части (сервисы, базы данных и т. д.) располагались на одной виртуальной машине. Со временем проект вырос в облачное распределенное решение с множеством веб- и мобильных клиентов. 

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

Привет! Меня зовут Денис, я — разработчик ПО SEDMAX. Это промышленное ПО для сбора и визуализации данных в энергетике. Как и у всех, у нас бывают баги. Мне бы хотелось поделиться опытом в поиске таких багов, а также порассуждать на тему того, что необходимо было сделать, чтобы баг не появился. У нас серверная часть написана на go в виде некоторого множества сервисов, поэтому специфика большинства багов будет асинхронное взаимодействие, а код примеров представлен на go.

В прошлой статье были сделаны следующие выводы:

Micronaut — фреймворк для ЯП Groovy. Он предназначен для создания микросервисов и серверных приложений на JVM. Он был разработан с учетом всех недостатков и ограничений предыдущих фреймворков, таких как Spring и Grails.

В статье рассмотрим, как работать в Groovy с Micronaut на практическом примере.

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

В новом переводе от команды Spring АйО вы узнаете, как аннотация @Transactional помогла решить проблему с утечкой соединений и обеспечила стабильность системы.

О проектировании микросервисной архитектуры с использованием фреймворка Single SPA и технологиях, связанных с его использованием.

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

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

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

"Работает? Не трогай!" Но только не в HighLoad! Расти нужно постоянно. Всё менять и переделывать. Но как? И с помощью каких практик? А может и так сойдёт? Поехал искать ответ на Saint HighLoad++.

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

Привет, Хабр! Я Александр Непомнящих, QA в СберМаркете. Мы с командой кодим программу лояльности, которая позволяет списывать в заказах бонусы «Спасибо», а также запускать различные акции с повышенным начислением бонусов. 

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

Если вы занимаетесь тестированием, заходите под кат — расскажу, как мы в итоге автоматизировали процесс до 1 команды в Rails-консоли.

Всем привет! Мы продолжаем нашу серию статей по созданию собственного SSO. В этой статье мы увидим итоговый проект и разберём самые интересные решения из него. Подумаем над безопасностью приложения и настроим защиту от XSS и CSRF атак, а также изучим разные Security Headers. В заключение статьи мы создадим собственый Grant Type.