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

Задумывались ли вы, почему мы используем отдельную базу данных для каждого сервиса, но при этом один общий брокер для нескольких сервисов? Ведь вполне возможно использовать базу данных в роли брокера сообщений. Однако, если мы попробуем заменить RabbitMQ на Redis, то натолкнемся на проблему общего использования базы данных. Это станет проблемой, потому что общее использование базы данных является антипаттерном.

Привет, Хабр! Меня зовут Игорь Гербылев, я технический директор в компании Just AI. В этой статье я расскажу о методологии структурирования ansible-плейбуков, которую мы называем «Компонентный ансибл». Этот подход позволил нам упростить разработку и поддержку большого объёма ансибл-кода, который мы используем для настройки инфраструктуры и развёртывания наших SaaS продуктов.

Те, кто использует Helidon в проде, наверняка точно знают, зачем им это нужно. Что делать остальным? Основная задача хомячка — объяснить детям концепцию смерти. Кажется, точно так же основная задача Helidon для широких народных масс — посмотреть на самые новые фишки Java и понять, нужно вам это или нет. Посмотрим, что же произошло в версии 4.0.0...

Привет, Хабр! С вами Валентин, архитектор направления Backend компании SimbirSoft. В данной статье мы с коллегами поделимся опытом реализации большого и сложного проекта с микросервисной архитектурой, а также поговорим о роли архитектора в таких проектах. 

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

Всем привет!
В прошлой статье была поставлена задача о надёжных мутациях и транзакциях в архитектуре Профи, в этой статье разберём один из вариантов решения — применить workflow-engine Temporal.

Почему микросервисы помогут вам ускорить поставку бизнес-ценности.

История появления микросервисов

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

Привет, меня зовут Максим Качинский, я ведущий DevOps-инженер в компании RocketData. Более 6 лет мы развиваем одноимённую платформу для управления репутацией — за это время она выросла с монолитного MVP на единственном сервере до 15+ микросервисов с пятью разными видами баз данных. И всё это в гибридной инфраструктуре. 

Чем больше рос проект, тем сложнее нам было его поддерживать. Чтобы облегчить жизнь DevOps-инженерам, мы начали постепенно переходить на managed-решения. Но этот путь не был идеально прямым, и нам пришлось пересмотреть многие привычные рабочие инструменты. 

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

Эта статья предназначена для новичков и рассматривает микросервис отправки писем через smtp Yandex с использованием .Net Web Api и MailKit. В ней будет рассмотрено, как настроить и использовать данный микросервис для отправки писем с помощью почтового сервиса через существующий почтовый ящик Яндекса.

Ссылки для понимания и работы

GitHub Документация Яндекс

Дерево проекта:

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

Разделяй и влавствуй, или как провести клининг легаси-кода GoLang.

Этот пост является частью большого цикла статей, в которых мы демонстрируем, как создавать приложения на Go, которые легко разрабатывать, поддерживать и с которыми приятно работать в долгосрочной перспективе. Мы делаем это, делясь проверенными методами, основанными на множестве экспериментов с командами, которыми мы руководили, и научных исследованиях («при съёмках фильма ни одно животное не пострадало»).

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

Что касается подхода к «чистой» архитектуре, описываемого далее, то это симбиоз двух идей: разделение Ports и Adapters, а также контроль за тем, как пакеты ссылаются друг на друга...

Собрались как-то вместе: продакты, HR, лиды и архитекторы ИТ, и начали думать, как же им перестроить HR-процессы в Банке так, чтобы улучшить клиентский опыт сотрудников и им стало удобно работать с HR-услугами..

У нас была идея продуктового подхода, десяток backend систем, 23 приложения, 109 процессов и продуктов, 683 различных заявок. Но раз уж мы начали собирать все это под единый интерфейс, то надо идти в этом до конца.

Меня зовут Михаил Михеев. Я руководитель направления интеграций в одной из команд клиентского пути в Альфа Банке. В этой статье я поделюсь нашим опытом создания единого канала контакта с сотрудником, в условиях, когда «под «капотом» множество монолитных систем.

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

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

Главная метрика, на которую работает моя команда, — Тime-Тo-Мarket, совокупное время, затраченное на разработку фичи от самого начала разработки и до релиза на пользователей.

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

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

Привет, уважаемые читатели Хабра!

Когда у нас есть десятки, сотни или даже тысячи микросервисов, становится важным уметь управлять трафиком между ними. Это может включать в себя маршрутизацию запросов, балансировку нагрузки, версионирование сервисов и даже внедрение A/B-тестирования. Контроль над трафиком необходим для обеспечения стабильности и производительности системы.

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

И вот здесь на помощь приходит Istio, предоставляя мощные инструменты для управления трафиком и мониторинга в микросервисной архитектуре.

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

Справедливости ради подчеркну, что не во всех компаниях, где разрабатывают софт, ему дают весёлые имена. Но во многих.

Насколько хороши весёлые имена? Какие есть альтернативы? Как лучше всего называть софт? Какие имена используют в зрелых софтверных компаниях?

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

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

Статья составлена на основе сразу двух англоязычных материалов. В первом (его мы поместили в самое начало) авторы на примере профессий объясняют роль различных компонентов облачных приложений, а во втором — проводят глубокий анализ все возрастающей значимости API-шлюзов для экосистемы облачных приложений, их места в рамках концепции «Kubernetes — облачная операционная система» и того, как повлияет на дальнейшее развитие API-шлюзов появление Kubernetes API Gateway. 

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

На собеседованиях на позицию middle/senior разработчика часто задают вопросы по распределенным транзакциям в микросервисной архитектуре.

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

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

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

Необходимо реализовать возможность приёма транзакций от разных клиентов для процессинга и дальнейшей отправки в разные банки. Клиенты могут присылать как равномерно (например, по 1шт в секунду), так и большими пачками (1000шт каждый час или 10000 раз в день), банки обрабатывают транзакции последовательно.

Для простоты интеграции необходимо использовать REST API для приёма транзакций

Необходимо исключить ситуации, когда:

Тысячи клиентов по несколько транзакции ожидают двух, у которых по 10000 транзакций

Несколько клиентов по 10000 ждут тысячи клиентов по несколько транзакций.