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

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

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

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

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

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

Разберемся подробнее с первым из ключевых компонентов сквозного наблюдения - трассировкой.

Привет ? На связи команда PaaS СберМаркета. Меня зовут Роман, и уже больше 2-х лет моя группа занимается разработкой инструментов для разработчиков, в том числе утилитой sbm-cli, о которой хочу рассказать сегодня.

Вероятно вы каждый день пользуетесь консольными утилитами, такими как git, homebrew, ssh, grep, find, etc. Мы сделали command line interface приложение, запуск которого на локальной машине разработчика может превышать количество запусков команды git (спойлер: статистика в конце статьи).

О том как так получилось, почему этот инструмент так важен для разработчика и что он умеет, а что нет, расскажем в этой статье.

Привет, меня зовут Валентин, я NodeJS-разработчик в Сравни. Моя команда делает Profile Service — внутренний продукт, который отвечает за быстрое получение и запись личных данных пользователей для экосистемы Сравни. Мы взаимодействуем с 20+ продуктовыми командами, которые дают нагрузку на сервис порядка 200-300 RPS; порядок обрабатываемых записей в БД – десятки миллионов.

В какой-то момент мы решили внедрить Kafka – де-факто стандарт транспорта, работающий в миллионах проектов. Что может пойти не так? Оказалось – вообще всё что угодно. 

В этой статье я расскажу, с какими неочевидными проблемами мы столкнулись при переходе на Kafka у нас в продукте, как мы чинили баги в NestJS Microservices и какие выводы сделали (спойлер: Kafka – не всегда хорошее решение). 

Приступим!

«Мы хотим сделать систему по учету персонала. Только у наших архитекторов есть требование, что все у нас должно быть на микросервисах». Это, пожалуй, самый бесячий заход, который нам приходится слышать, как разработчику Jmix – платформы быстрой разработки корпоративных веб-приложений. Почему только микросервисы? Какие проблемы, кроме независимого развертывания они решают? Это действительно необходимо для всех типов приложений? Мы, для полного понимания, ни в коем случае не являемся противниками микросервисной архитектуры, однако неистово сопротивляемся слепому следованию «карго культа». Часто случается, что ничего, кроме удорожания разработки, поддержки и эксплуатации такие решения не приносят. Собственно, об этом и пишет Nikolas Frankel, автор статьи, перевод которой представлен ниже.

Статья была написана мной в 2020 году, после запуска в прод очередной платформы, построенной на микросервисной архитектуре с целью зафиксировать выученные уроки с точки зрения технического руководителя проекта. В проектах участвовало со стороны подрядчика более 300 человек технических специалистов - разработчиков, тестировщиков, аналитиков и др. Поэтому можно сказать, что проекты были достаточно крупными и значимыми.. Теперь уже многие компании - участники проекта либо свернули бизнес в РФ, либо поменяли бренд, а разработанные системы находятся в эксплуатации. Микросервисная архитектура давно не является новой архитектурной парадигмой. Но я думаю, что статья все еще актуальна, как и многие выученные уроки . 

Привет, Хабр! Меня зовут Денис Антонов, я работаю SRE‑инженером и менеджером системы на платформе IPS (Investment Platform Solutions) в Блоке ИТ‑развития Инвестиционного бизнеса РСХБ‑Интех (дочерняя технологическая компания Россельхозбанка). Совместно с коллегами мы выстраиваем качественные процессы сопровождения и обновляем системы сервисов, чтобы они работали стабильно, исправно, и чтобы в случае поломки на исправление проблемы уходило минимальное количество времени и трудозатрат. Сегодня расскажу о технологическом стеке нашей IPS платформы: составных модулях и ключевых технологиях, а также об архитектуре и назначении одного из базовых модулей (аудит), о схеме работы и ключевых метриках технического и бизнес‑мониторинга, процессе подключения и траблшутинга и не только.

Мы протестировали совместимость контейнеризированной платформы dBrain с операционными системами Astra Linux, ALT Linux и РЕД ОС. Что из этого получилось, читайте в нашем тексте.

Привет Хабр! Осень - традиционно богата на ИТ-события, где есть возможность познакомиться с новыми людьми, посетить актуальные доклады и узнать о компаниях на стендах.

Меня по-прежнему зовут Антон и мы подготовили митап по разработке!

Когда?

Начало митапа: 19 октября в 19.00 

Встречаемся: 19 октября в 18:00 на площадке LOFT IDEALISTA (г. Москва, Нижняя Сыромятническая ул., 11, корп. 1, этаж 3)

Так же будет доступна онлайн‑трансляция митапа.

В билете после регистрации будет указана ссылка.

О чем расскажем?

Будем разбираться в вопросе, как писать код так, чтобы при этом создавать меньше багов? Какие "оверхеды" с точки зрения производительности и трудозатрат приносит микросервисная архитектура и нужно ли нам обратно в монолит? А так же постараемся разобраться насколько хорош паттерн Transactional Outbox и есть ли ему альтернатива?

Привет, Habr! Возможно, кто-то меня даже помнит: совсем недавно я создал Python Framework для асинхронных приложений - Propan.

Два месяц назад я делился с вами прогрессом и говорил, что работа над PropanV2 активно ведется. И вот, она завершена. Вот только вместо PropanV2 свет увидел немного другой фреймворк - FastStream, разработкой которого занимался уже не только я, а целая команда AirtAI.

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

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

Java долгое время была и остается фаворитом в enterprise решениях, но все чаще в высоконагруженных проектах предпочтение отдается более "производительным" языкам, таким как Go, а порой даже C++. Но вдруг Java тоже может быть быстрой?

❓Как проектировать системы, которые будут толерантными для различного вида отказов и ошибок?

Что такое отказоустойчивость и стабильность?

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

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

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

В данной статье представлен простой способ реализации микросервисной архитектуры с использованием Kafka, Golang и Docker.

Еще одна статья о том, как можно применять Spring Cloud Config Server при выборе Git репозитория как хранилища конфигураций приложений в облаке и не только в облаке.

Друзья, привет! Если у вас так же много разработчиков как у нас, то и им, возможно,  стало тесно стоять в очереди на deploy в монолите. А значит, вы можете решить перейти на микросервисную архитектуру и дать каждому игроку свой мяч каждой команде свой микросервис. 

Меня зовут Дмитрий Лукиянчук, и я руковожу отделом в IT-платформе СберМаркета. В этой статье я сделаю обзор инструментов, которые у нас есть сейчас, спустя 2,5 года, и какие задачи эти инструменты решают. Вы узнаете, что вам нужно будет сделать, если вы сами решите взяться за построение платформы, а если у вас уже есть своя платформа, то вам будет интересно найти 10 отличий в своей и нашей реализации.

Порой простое и очевидное решение может потянуть за собой хвост проблем в будущем. Например, добавление ретраев.

Меня зовут Денис Исаев, и я работаю в Яндекс Go. Сегодня я поделюсь опытом решения проблем с отказоустойчивостью из-за ретраев. Основано на реальных инцидентах в системе из 800 микросервисов.

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

Привет, Habr! С вами Антон, руководитель Архитектурного комитета компании SimbirSoft. Мы продолжаем цикл статей, посвященных практическому внедрению подхода Design API First в разработку наших проектов. Настало время поделиться практическим опытом использования спецификаций OpenAPI для кодогенерации контрактов backend.

Дисклеймер: Материал публикации в первую очередь передает практический опыт работы системных аналитиков и практикующих архитекторов при интеграции Design API First с непосредственным процессом разработки. Некоторые технические детали реализации будут описаны не полностью.

В книге Криса Ричардсона «Микросервисы: паттерны разработки и рефакторинга», описывается что-то около 20 паттернов, использующихся в микросервисной архитектуре. Все они делятся на 5 больших групп: decomposition patterns, integration patterns, database patterns, observability patterns и cross-cutting concern patterns. Я, узнав про паттерны, которые могут быть применимы в микросервисной архитектуре, немного изучила их и попробовала реализовать один из них. Всем привет, меня зовут Екатерина Попкова, я Java/Kotlin-разработчик в Альфа-Банке, и хочу рассказать, как можно обеспечить консистентность данных в микросервисной архитектуре с помощью применения паттерна «Сага».