В статье рассматриваем, как RabbitMQ интегрирован в dBrain, какие операторы использовались для управления кластерами, а также с какими проблемами разработчики столкнулись в процессе внедрения.
Статья посвящена Istio — платформе для создания service mesh. Она объясняет ключевые функции инструмента: управление трафиком, защита коммуникаций через mTLS и сбор метрик для мониторинга. Также рассматриваются примеры конфигурации: как Istio помогает в управлении сетевыми взаимодействиями и повышает устойчивость систем. Узнайте, помогает ли Istio в работе с распределёнными системами.
В данной публикации я хочу рассказать про относительно новый брокер сообщений NATS (Neural Autonomic Transport System). А также сравнить его с более популярными и известными брокерами RabbitMQ и Apache Kafka.
Привет, Хабр!
В прошлой статье мы начали разговор о паттернах микросервисов (Часть 1). Ну что ж, давайте продолжим!
Паттерн «API-шлюз» (API Gateway)
Итак, следующим популярным шаблоном является паттерн API Gateway, который часто упоминается в контексте микросервисной архитектуры. Этот шаблон основывается на использовании шлюза, находящегося между клиентскими приложениями и микросервисами, предоставляя единую точку входа для всех клиентских запросов.
Привет, Хабр!
Сегодня я покажу, как создавать кастомные Starter'ы, которые помогут сэкономить время и стандартизировать конфигурации во всех микросервисах.
При переходе от монолитной к микросервисной архитектуре разработчики часто сталкиваются с несколькими проблемами.
Во-первых, это необходимость переработки существующего кода и его разбиения на независимые сервисы, что может быть трудоемким и сложным процессом.
Во-вторых, возникают сложности с обеспечением взаимодействия между микросервисами, включая управление сетевыми запросами и обработку ошибок. Кроме того, важно наладить мониторинг и логирование каждого микросервиса для своевременного выявления и устранения проблем в распределенной системе.
Использование в практике таких паттернов как Strangler Fig Pattern, Parallel Run Pattern, Decorating Collaborator Pattern и Change Data Capture позволяет разработчикам значительно снизить риски и проблемы, возникающие при таком сложном переходе.
Давайте рассмотрим основные концепции этих паттернов.
Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.
Изучая System Design, вы часто видите только теоретические материалы. В этой статье я постарался показать в том числе практическую реализацию многих вещей, чтобы вы не просто готовились к собеседованиям, но и знали, как эти вещи используются в реальном мире.
Эта статья предназначена для разработчиков, архитекторов и технических лидеров, которые ищут способы оптимизации производительности и масштабируемости своих систем.
Продолжение статьи об архитектурных паттернах для масштабируемости приложений.
Эта статья предназначена для разработчиков, архитекторов и технических лидеров, которые ищут способы оптимизации производительности и масштабируемости своих систем. Она поможет понять:
Когда стоит использовать более простые подходы (например, шардирование, репликацию, CQRS) вместо того, чтобы сразу переходить к микросервисам.
Какие trade-offs возникают при выборе каждого из паттернов или архитектурных решений.
Как избежать излишней сложности, которая может быть вызвана преждевременным внедрением сложных архитектур.
Цель статьи — помочь вам найти баланс между производительностью, масштабируемостью и сложностью системы. Вместо того чтобы сразу применять микросервисы, мы предлагаем сначала рассмотреть более легкие инструменты, делая выбор осознанно и обоснованно.
У нас был spring и hibernate
Мы твёрдо знали, что OAuth2.0 это хорошо, а принцип "Api first" ещё лучше.
И нам дали ровно 48-ь часов чтобы создать работающую инфраструктуру с возможностями авторизации, отслеживания метрик, динамической маршрутизацией запросов и раздачей конфигураций сервисам "на лету". Кроме того от нас хотели получить "best practics" по работе с БД в коде и лёгкой поддержке ролевой модели.
С переходом на кластерные решения платформа dBrain.cloud столкнулась с новыми задачами, требующими пересмотра подхода к выбору операционной системы. Как и что выбирали?
Рив Гош – это одна из крупнейших розничных сетей косметики и парфюмерии. Мы представлены в нескольких каналах продаж: офлайн-магазины, собственный интернет-магазин и все ведущие маркетплейсы.
Каждый канал продаж индивидуален, но все они требуют онлайн информацию об остатках: В офлайн-магазине на кассе мы предлагаем клиенту товар по акции. Причем предлагаем только товар, аналогичный выбранному клиентом, который есть в остатках этой локации. В собственном интернет-магазине есть опция получения товара в магазине сети Ривгош или заказать экспресс-доставку из магазина. Маркетплейсам вообще нужна максимально актуальная информация об остатках – любой отказ от заказа клиента влечет штрафы и снижение рейтинга.
Откуда же эту информацию мы можем выдать? Достоверная оперативная информация о товарных остатках в Рив Гош распределена по разным OLTP системам: часть магазинов в современной централизованной 1С ERP управление холдингом, остальные магазины – в специализированных базах Oracle, распределительные центры – в 1С УПП. Единого оперативного хранилища нет.
Чтобы централизованно выдать остатки, шине данных приходилось последовательно пробегаться по базам данных всех магазинов, агрегировать их и консолидировано выдавать их внешним потребителям этих данных. Магазинов много, и на их последовательно-параллельную обработку уходило порядка 3х часов. Такая задержка с обновлением остатков вызывала много ложных заказов: клиент заказывает товар, товаровед идет его собирать с полок магазина и не находит. Клиент получает отказ, а значит мы теряем рейтинг на маркетплейсах и клиентскую удовлетворенность. Надо было что-то делать.
MassTransit одна из самых популярных библиотек для построения асинхронного взаимодействия между сервисами в среде dotnet. Она активно развивается уже долгие годы, до сих пор остается под открытой лицензией и каждую версию добавляет новые фичи. Я построил уже не одно решение на ней и могу сказать, что по поддержке, качеству кодовой базы и “взрослости”, это один из лучших примеров в нашем dotnet сообществе.
Недавно в новой версии MassTransit вышла относительно свежая фича, SQL Transport, которая позволяет использовать базу данных вместо традиционных брокеров сообщений, при этом оставляя доступными тонну фичей работающих на традиционных брокерах. Ретраи, ределивери, роутинг, все продолжает работать. Такая обратная совместимость в теории позволяет легко заменять несложные конфигурации RabbitMQ на SQL Transport и обратно.
Я попробовал эту фичу, посмотрел на нее с разных сторон и сегодня хочу поделиться своими впечатлениями.
В этой статье вы узнаете, как спроектировать и реализовать REST API для микросервиса на Java с использованием Spring Framework.
Рассмотрим лучшие практики, принципы архитектуры, реализацию CRUD-операций и удобные инструменты, такие как Lombok, ControllerAdvice, MapStruct. Эта статья будет полезна как начинающим разработчикам, так и тем, кто хочет улучшить свои навыки в проектировании REST API.
Ох уж эти микросервисы. Все на них уже давным-давно перешли, либо в активном процессе перехода. Индустрия уже подошла к тому, что “микросервис” вот-вот станет ругательным словом.
В свое время подобный путь проходила электроника, но со своими особенностями. В статье я попробую рассмотреть развитие электроники к идеальным размерам функционального блока.
Полагаю, каждый разработчик рано или поздно приходит к мысли о том, что ему есть, что рассказать и чем поделиться. Кто-то даже начинает это делать в том или ином формате. И, конечно, хочется сказать спасибо всем тем, кто отвечает на вопросы на stackoverflow, пишет статьи или делает еще какой-либо контент. Однако быть автором труд весьма специфичный, всегда есть риск, что твой контент не будет полезен или даже интересен. За несколько лет мною было написано около пары десятков статей, а также было начато несколько своих проектов, но все это выглядит на первый взгляд как «работа в стол».
Однако, порефлексировав, я понял, что вся работа, которая не дает ожидаемого результата не напрасна. Как минимум - это опыт, а опыт штука полезная. Никогда не угадаешь, что тебе может пригодится в будущем. К тому же не стоит сбрасывать со счетов накопительный эффект общей массы знаний. Звучит довольно туманно, поэтому приведу пример. Разработка показала мне, как можно копить фрагментированные кусочки знаний долгое время, которые в определенный момент могут сложится в полную картину, а ты будешь удивляться, как не понимал чего-то раньше.
Так о чем это я? Я буду делать личный блог или сайт, на самом деле еще не знаю во что это выльется. Но как показал опрос в моем TG канале, у ребят, как и у меня, есть интерес к тому, как можно сделать и использовать блог, чтобы он приносил тебе пользу в каком-либо виде. Если дело пойдет, то здесь будет целая арка статей. Приступим!
Предновогодний кодфриз — это время для полезных открытий: есть возможность поковыряться в имеющихся системах и что-нибудь исправить.
В Сравни у нас много продуктов, включая сервисы подбора и покупки полиса ОСАГО, подбора кредита, образовательных курсов, онлайн-оформления ипотеки. Информация о пользователях хранится и обрабатывается в специальном центральном сервисе (Profile Service). На текущий момент сервис содержит миллионы объектов пользователей, а нагрузка в пиковые моменты там до 180 запросов в секунду.
Исходная реализация Profile Service была построена на микросервисах и, как казалось нам ранее, полностью покрывала наши потребности: в плане гибкости взаимодействия с продуктами и работы с существующей нагрузкой. Изменения назрели под конец прошлого года, когда продуктовые команды стали настойчиво обращаться в команду сервиса для решения срочных задач. Здесь им регулярно требовалась помощь разработчиков — и команда Profile Service около месяца занималась только обработкой продуктовых запросов.
В попытках исправить ситуацию мы пришли к идее задействовать GraphQL. Под катом рассказываем, как провели год с GraphQL, и как за это время нам удалось облегчить жизнь и технологическим, и продуктовым командам.
Всем привет, меня зовут Вадим Макеров, я работаю в iSpring бэкенд-разработчиком.
Однажды у нас в продукте был инцидент, который привел к даунтайму LMS и происходил несколько раз, в течении нескольких дней. Причина оказалась нетривиальной и находилась на уровне сетевых настроек подключений между сервисами.
Популярность Kubernetes в России продолжает расти. О трендах в развитии облачных платформ на 2025 год рассказывает глава разработки платформы контейнеризации dBrain.cloud Дмитрий Головнич.
Вы не стали чаще слышать о таком трендовом явлении, как Server Driven UI? Если вы ещё с ним не сталкивались, то в будущем обязательно столкнётесь. Я, как инженер, познакомилась с таким подходом чуть больше года назад, перейдя в другой проект в Альфа-Банке.
И если вы, как и я тогда, задаёте себе вопрос: «Что же это такое творится-то?», то рекомендую прочитать эту статью, где я на примере нашего нового функционала в приложении для физических лиц расскажу, что это есть на самом деле и как лёгким взмахом волшебной палочки backend-разработчик становится отчасти frontend’ером, реализуя на стороне серверной части не только логику, но и вёрстку всех экранов приложения.
