Кэширование с FeignClient: ускоряем микросервисы и радуем пользователей
Статья о том, как добавить кэширование в FeignClient с помощью Caffeine Cache и сделать микросервисы молниеносными. Простая настройка, минимум кода, максимум пользы — пошагово на примере Java и Spring Boot, чтобы ваши запросы летали, а API не тормозил.
В настоящее время трудно себе представить работу сложных систем, состоящих из множества компонентов, без взаимодействия между собой при помощи различных интеграций. Ну и само собой, брокеры сообщений по популярности на сегодняшний день входят в топ самых используемых решений.
RabbitMQ и Apache Kafka — это термины, которые, возможно, на слуху у каждого, кто так или иначе работает в ИТ-сфере.
И сегодня я хотел бы познакомить вас с одним из, на мой взгляд, интереснейших инструментов для симуляции брокера RabbitMQ - сайтом RabbitMQ Simulator https://tryrabbitmq.com.
Для начала пару слов теории о брокере сообщений RabbitMQ.
RabbitMQ — это популярная система обмена сообщениями с открытым исходным кодом, которая используется для передачи данных между различными приложениями и сервисами. Она основана на протоколе AMQP (Advanced Message Queuing Protocol) и позволяет создавать надежные и масштабируемые системы обмена сообщениями.
RabbitMQ представляет собой брокер сообщений, который принимает сообщения от отправителей (publishers), хранит их в очереди и передает получателям (consumers). Он поддерживает различные модели взаимодействия, такие как точка-точка (point-to-point) и публикация-подписка (publish-subscribe).
Теперь перейдём к самому RabbitMQ Simulator-у.
Итак, RabbitMQ Simulator — это онлайн-симулятор, который предоставляет пользователям возможность познакомиться с основами работы RabbitMQ и отработать сценарии использования очередей сообщений в безопасной и понятной среде, не требующей установки самого RabbitMQ на локальной машине. И это делает его необычайно полезным инструментом для изучения принципов работы RabbitMQ, а также для тестирования различных сценариев использования.
Как избежать типичные ошибки при внедрении микрофронтов и какие инструменты упрощают жизнь разработчикам.
Рассмотрим плохие примеры разделение кода приложения, т.е. когда "архитектор" или лид проекта, не умеют микрофронты готовить. А разработчикам нужно с этим жить.
Всем привет! Меня зовут Максим, я QA в Максилекте.
Недавно коллеги попросили меня рассказать о базовых вещах в Kafka, которые могут быть полезны при тестировании общающихся между собой микросервисов или сервисов, взаимодействующих со сторонними ресурсами. В этой статье - основные идеи моего рассказа.
Бесплатное решение по налоговому учету для ИП и организаций.
Цветовые решения, рейтинги ТОП-10. Прибыльность и рентабельность с налогом и без.
Заинтересует бизнесменов и бухгалтеров как альтернативное универсальное ПО для налогового и управленческого учета и сравнения разных налоговых режимов.
Привет, Хабр! Меня зовут Алексей Топчий, я уже более 20 лет работаю в IT. Прошёл все уровни: бэкенд, фронтенд, фулстек со множеством языков и технологий. В СберТехе занимался Единой фронтальной системой, в Яндексе участвовал в стартапе, связанном с FMCG. Сейчас занимаюсь сервисом ценообразования в сети магазинов «Пятёрочка» (X5 Group).
В этой статье я приоткрываю тайну бэк-офиса современного магазина и делюсь опытом, как мы развиваем программный комплекс, что интересного при этом происходит, с какими проблемами сталкиваемся и как их решаем. Статья будет полезна архитекторам, техническим менеджерам и всем, кто интересуется преобразованием корпоративных IT-ландшафтов.
Привет! Хочу поделиться, как я с KeyCloak-ом сражался.
Испытание воли на прочность, падение до глубин отчаяния и победа, как кульминация всех потраченных недель на поиски решения.
При разработке микросервисов рано или поздно возникает вопрос о специализированном микросервисе, через который проходят запросы и маршрутизируются в нужный. Это необходимо не только с точки зрения безопасности (в одной точке аудита можно увидеть все нужные события), но так же с точки зрения производительности. Ваш микросервис выполняющий важную функцию наверняка использует массу ресурсов, например подключения к БД - даже если обработка плохого запроса не требует подключения к БД, то она гарантированно ворует ресурс ЦП. Разумеется можно покупать все более производительные сервера, но такой путь ни к чему не приведет.
Если вас интересует эта тема, то добро пожаловать под кат.
В рамках микросервисной архитектуры достаточно легко делать «реактивные» сервисы: к вам приходит событие или вызов HTTP-метода, и в ответ на это происходит какое-то действие. Однако бывают более сложные сценарии, когда надо собрать некоторое количество информации или событий прежде, чем что-то делать. В таком случае нужен пайплайн — механизм организации сложных правил обработки событий.
Недавно нам пришлось организовать пайплайн с использованием интересных С++-трюков. О них я и расскажу в статье.
— Как хранить в одном контейнере разные типы и использовать тип в качестве ключа контейнера
— Как средствами метапрограммирования удобно сериализовать и десериализовать разнотипные объекты
— Как сделать универсальный запускатель функций, который будет запускать любую функцию и сам искать, откуда «добыть» эти аргументы
— И главное, как сделать интерфейс для написания пайплайна обработки события — удобный и полностью изолированный от инфраструктуры
Меня зовут Екатерина Александрова, я интернет‑маркетолог, выпускница курса «Интернет‑маркетолог» и «SMM‑продвижение в Телеграмм», и Станислав Козырев — ведущий инженер‑программист, дата‑аналитик и саентист ЦУНБ им. Некрасова, выпускник курса «Специалист по Data Science».
Наша команда «Проактивные практики», состоящая из пяти увлеченных и энергичных участников, проходит обучение в амбассадорской программе Яндекса. Заключительным этапом программы стала выпускная работа.
Привет, Хабр!
Меня зовут Михаил, я являюсь ФинТех системным аналитиком, исполняющим роль архитектора на проектах. И сегодня я хочу поделиться материалами по Kafka, которые подготовил для обучения сотрудников из своей команды. В материале постарался отразить самые важные технические моменты по Kafka, которые будут подкреплены наглядными кейсами и примерами использования. Материал будет полезным как для начинающих, так и для продвинутых пользователей. Желаю приятного прочтения.
Архитектура микросервисов широко распространена в современном программировании. Благодаря этой архитектуре разработчики смогут самостоятельно разрабатывать сервисы и управлять ими. Однако очень важно выбрать правильный протокол для эффективного взаимодействия между микросервисами. Здесь протокол gRPC (Google Remote Treatment Call) выделяется своей высокой эффективностью и скоростью. В этой статье мы предоставим подробную информацию о RPC и gRPC, рассмотрим преимущества gRPC в архитектурах микросервисов и продемонстрируем их различия на примерах кода на языке программирования Go.
Хочу рассказать о том, какие проблемы при разработке создают рекурсивные зависимости на фронте.
С данной проблемой каждый второй проект живет и разработчики не знают, что у них есть циклические зависимости.
Рассмотрим способы разрешения циклических зависимостей и их обнаружение.
Привет, Хабр! Мы в команде Nova Container Platform продолжаем серию переводов полезных материалов о микросервисной архитектуре.
Привет! Меня зовут Дима, я архитектор в Купере. Сегодня расскажу о шаблоне проектирования Strangler, который мы использовали для поэтапного выноса бизнес-логики из монолитной системы в отдельный сервис.
Сначала обратимся к первоисточнику, а затем перейдем к практическим моментам, с которыми столкнулись в процессе работы. Поехали!
Привет, Хабр!
Сегодня поговорим о хорошей библиотеке для управления потоками данных в Python – RxPY — реализации Reactive Extensions для нашего любимого языка. В версии 4.0.4 эта библиотека получила ряд улучшений, и сегодня мы разберем её основной функционал.
Наверняка в вашем проекте используется очередь сообщений (не важно kafka, pulsar или какой-нибудь зайчик). Основной проблемой является подробное тестирование работы вашей системы. Рассмотрим варианты решения и посмотрим, что там у автора в рукаве.
Микросервисная архитектура — это концепция, которая существует уже довольно давно, но до сих пор многие не до конца понимают, в чем ее суть, какие плюсы и минусы она имеет по сравнению с монолитной архитектурой. На мой взгляд это нужно понимать, даже нетехническим специалистам. Как-то даже на одном из собеседований на "продуктовую" позицию в крупную международную компанию, рекрутер попросила меня объяснить разницу между ними и перечислить преимущества и недостатки каждого подхода.
Этот статья вряд ли откроет что-то новое для опытных специалистов, хотя они, возможно, найдут его полезным как пример для объяснения новичкам. Однако нетехническим специалистам это может помочь — на простом бытовом примере я покажу, как работают оба подхода и чем один лучше другого.
С увеличением вычислительных мощностей и пропускной способности каналов связи увеличились также и объемы обрабатываемых данных, а также требования к скорости обработки. Сейчас все больше систем требуют, чтобы работа с данными велась в режиме реального времени. Apache Kafka является распределённым программным брокером сообщений с открытым исходным кодом. Цель Kafka является создание горизонтально масштабируемой платформы для обработки потоковых данных в реальном времени с высокой пропускной способностью и низкой задержкой.
Еще одним популярным решением является использование архитектуры микросервисов для создания крупномасштабных приложений. Она позволяет разработчикам разделять сложные приложения на более мелкие, независимые и слабо связанные сервисы, которые взаимодействуют друг с другом с помощью упрощенных протоколов. В качестве инструмента взаимодействия может в том числе использоваться брокер Kafka. В этой статье мы рассмотрим методы, которые могут быть использованы для обеспечения эффективного взаимодействия между микросервисами с помощью Kafka.
Попробуем начать с цитаты:
При современных темпах развития индустрии программирования приложениям нельзя оставаться застывшими. Разработчики должны найти способ вдохнуть новую жизнь в программы, которые уже поставлены пользователям. Решение состоит в том, чтобы разбить монолитное приложение на отдельные части, или микросервисы (рис. 1).
...
Традиционно приложение состояло из отдельных файлов, модулей или классов, которые компилировались и компоновались в единое целое. Разработка приложений из микросервисов — так называемых приложений микросервисной архитектуры — происходит совершенно иначе. Микросервис подобен миниприложению; он поставляется пользователю как двоичный код, скомпилированный и готовый к использованию. Единого целого больше нет. Его место занимают специализированные микросервисы, которые подключаются во время выполнения к другим микросервисам, формируя приложение. Модификация или расширение приложения сводится просто к замене одного из составляющих его микросервисов новой версией.
Если интересно откуда эта цитата и что с ней не так прошу под кат.
