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

Всем привет! Недавно мне выпала возможность разработать шаблон сервиса, который можно было бы использовать как для монолитной, так и для микро‑сервисной архитектуры. Шаблон должен был придерживаться принципов Domain‑Driven Design (DDD). В этом процессе, я столкнулся с двумя интересными проблемами:

Проблема 1: Сложности обеспечения транзакционности базы данных

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

Проблема 2: Нарушение изолированности слоя

В попытке решить первую проблему, некоторые разработчики переносят работу с транзакциями на уровень слоя приложения, чтобы избежать прямой зависимости от базы данных. Однако, такой подход, несмотря на его обоснование, может нарушить изолированность слоев и противоречить принципам DDD и чистой архитектуры. Это, в конечном итоге, затрудняет поддержку приложения и усложняет его масштабирование.
Эти две проблемы стали отправной точкой для исследования применения паттерна Unit of Work и его роли в обеспечении надежности и консистентности данных в контексте Golang и DDD.

В статье я расскажу о своем подходе к решению этих задач.

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

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

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

На просторах интернета заметил, что довольно мало статьей про ASP.NET под Linux. К сожалению, новички вроде меня копаются часами в поисках нужной информации, поэтому в этой статье мы вместе развернём минимальное приложение ASP.NET core под Linux в среде Ubuntu и в связке с PostgreSQL и с котиками на сервере nginx, а также упакуем всё в docker контейнеры. В ходе этой статьи мы разберём некоторые консольные команды для ежедневного пользования.

Привет, Хаброжители! Я Саша, Go-разработчик в компании Сбермаркет. Я со своей командой работаю над созданием инструментов PaaS.

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

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

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

Привет, Хабр! Меня зовут Данила Трушин, я руководитель направления в СберТехе. Мы с командой развиваем Platform V Synapse Service Mesh — продукт, который обеспечивает надёжную безопасную интеграцию и оркестрацию микросервисов в облаке.

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

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

Меня зовут Владислав Гончаров, я разработчик в команде Platform V DataSpace СберТеха. Расскажу, как мы решаем вопрос с объединением сервисов в GraphQL и микросервисной архитектуре, которая позволяет разбить любое большое приложение на маленькие сервисы. С одной стороны, их проще написать и поддерживать небольшой командой. А с другой — некоторые задачи теперь требуют выполнения сразу нескольких запросов вместо одного.

Привет, Хабр! Меня зовут Никита Летов, я техлид бэкенд-разработки сервисов дистанционного банковского обслуживания Росбанка для физических лиц, или как модно сейчас говорить, ретейла. В этом посте я расскажу, что такое входная точка в приложение, когда в ней появляется необходимость и какие вообще задачи решает паттерн API Gateway. Мы рассмотрим классический блокирующий подход на примере гейтвея Netflix Zuul 1.x, проблемы, связанные с его эксплуатацией, а также реактивный Spring Cloud Gateway и сложности перехода на него. В заключение сравним два подхода.

Поделимся личным опытом, как у нас получилось организовать взаимодействие микросервисов на Ruby и Go на основе gRPC. Мы расскажем:

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

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

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

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

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

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

Пользователю нужно возвращать информацию "что не так с файлом": какую проверку не прошел файл и где конкретно в файле проблемные данные.

Эта задача - про качество данных и очень напоминает тестирование. Так почему не использовать фреймворк тестирования pytest, и не написать тесты на каждый проверяемый аспект и для каждого типа файлов? Однако, есть небольшое "но". проверка должна быть реализована в качестве сервиса, чтобы встраиваться в более широкий процесс обработки пользовательских документов.

Давайте посмотрим, как заставить pytest работать внутри сервиса. Это не так тривиально, как может показаться на первый взгляд.

Такие схемы на проектах готовят наши архитекторы. Достаточно ли их чтобы оценить состав и сложность каждого модуля, объем и трудоемкость работ в целом. Поможет ли такая схема при планировании работ?

В статье рассуждение о том что могло бы помочь.

Старые программы покрываются коркой сомнительных фич.

Познакомим вас с надстройками Kubernetes в платформе dBrain, большая часть которых - наши собственные разработки для отслеживания пограничных состояний кластеров K8s.

Хабр, привет! На связи Дмитрий Бадулин, я занимаюсь разработкой ПО в компании К2Тех. Корпоративная сервисная шина, или как это по-другому называется, интеграционная платформа — это отдельная боль для множества компаний. И сегодня в условиях, когда некоторые middleware-решения класса ESB перестали нормально работать в России, возникает новая волна спроса на проектирование системы обмена данными между множеством ИС. В их числе, разумеется, есть как красивые и удобные, которые легко интегрировать, так и кошмар интегратора, которые никак не хотят нормально работать.

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

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

В этой статье на примерах разберу, что мешает строить разработчикам надежные интеграции, попутно заглядывая в детали реализации нашей утилиты sbm-cli, шаблона микросервиса и CI/CD.

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

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