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

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

После анализа различных вариантов, мы остановились на WebSocket в связке с RSocket.

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

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

Поэтому, когда мы закончили проект, то решили восполнить (или попытаться) этот пробел в русскоязычной среде на реальном примере. Надеемся, что эта статья поможет вам разобраться в применении RSocket over WebSocket и сократит время на погружение :) 

Если у вас есть большая система, состоящая из множества микросервисов, то вы наверняка задавались вопросом: «Что сделать, чтобы архитектурная схема всей системы была всегда на 100% актуальной?».

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

Чтобы решить проблему мы автоматизировали отрисовку схем опираясь на метаданные IT-систем. Мы создали отдельный микросервис, который этим занимается и назвали его «Architect». О том как это происходит и как работает Architect я расскажу в этой статье, а также дам несколько советов, которые помогут внедрить то же самое у вас в компании.

Привет, Хабр! Меня зовут Иван Вербов, я UI/UX дизайнер команды разработки платформы контейнеризации dBrain.cloud. В разработке дизайна интерфейсов я стремлюсь к балансу между двумя противоположными подходами: строгость и стабильность - легкость и игра.

Хочу поделиться топ-5 фишек, созданных для консоли dBrain, чтобы превратить рутинную работу инженера по обслуживанию кластера в творческую.

На современных проектах объектно-ориентированные подходы могут стать универсальным средством построения API, а файлы  YAML — понятной всем нотацией при интеграции. В новой статье рассмотрены оригинальные объектно-ориентированные подходы для проектирования архитектуры цифрового офиса сотрудника РСХБ.

Например, DDD может быть реализовано аналитиком через онтологическую разметку предметной области. При разработке приложения специалисты РСХБ-Интеха опирались на методику экспрессной визуализации объектов предметного поля через анализ чата в мессенджере с помощью методов математической лингвистики, также применяли адаптированную матрицу Эйзенхауэра для определения важности элементов интерфейса, методику определения границ микросервиса и концептуальную схему построения микросервисного конвейера.

О важности разметки предметного поля при анализе

Как сделать мобильное приложение для сотрудников банка? Не для клиентов, а для сотрудников. Клиенты у всех банков более-менее однородны, их интересует стандартный набор функция: оплата, кредиты, ипотека. А как быть с нуждами сотрудников? И что нужно в приложении сотрудникам именно нашего банка? Да и для чего вообще им нужно приложение?

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

Всем привет! Недавно мне выпала возможность разработать шаблон сервиса, который можно было бы использовать как для монолитной, так и для микро‑сервисной архитектуры. Шаблон должен был придерживаться принципов 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 работать внутри сервиса. Это не так тривиально, как может показаться на первый взгляд.

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

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

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