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

⌚️Пишем Realtime для Multiple-page application в микросервисной архитектуре

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

В статье описывается, как отправить пропущенные во время переподключения события WebSocket повторно в порядке очередности поступления

Рассказываем о тонкостях и сложностях интеграции поддержки видеокарт Nvidia в платформу контейнеризации.

Привет! Меня зовут Данил, я бэкенд разработчик.

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

Event Driven Architecture, или EDA — довольно популярный архитектурный подход, в буквальном переводе «архитектура на основе событий», где мы строим приложение вокруг событий, которые генерируются в системе. В самом распространённом случае, у нас есть много пользователей, которые генерируют много событий, и эти события маршрутизируются в сервисы‑потребители.

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

Салют! Меня зовут Сулейман, и я Senior Software Engineer с более чем 10 годами опыта в программировании. Я разрабатываю веб-сервисы, способные масштабироваться и выдерживать высокие нагрузки, а также активно участвую в open source проектах, публикую статьи, связанные с разработкой, и видео по решению алгоритмических задач, a еще пишу статьи в медиа вАЙТИ. Я сертифицированный Kubernetes Application Developer (CKAD), и мой опыт охватывает различные сферы разработки: от бэкенда и фронтенда до DevOps и разработки Android-приложений.

Когда вы разрабатываете приложения на базе Kubernetes, вам часто нужно управлять конфигурацией и секретами. Эти данные должны быть легко доступны для приложений, но также должны быть защищены и гибко управляемы. В Kubernetes для этого существуют два ключевых механизма — ConfigMaps и Secrets. В статье мы подробно разберем, что это за объекты, как их использовать и как эффективно ими управлять в кластере.

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

Меня зовут Сергей Громов, я работаю в IT уже 30 лет. Прошел путь от программиста на Assembler и преподавателя до ведущего системного аналитика.

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

Если бы мы организовывали предновогодний корпоратив «здорового» гофера, он выглядел бы так. 12 декабря, в четверг, собираем Go-разработчиков в Нижнем Новгороде и онлайн, чтобы обсудить практики тестирования микросервисов на Go, историю распила монолита, которая привела к… монолиту, и работу с монструозным Makefile (ждем откровений Даниила Подольского). В качестве нетайных Сант выступят эксперты из Wildberries, YADRO, Ви.Tech и Weborama — спикеры и участники GolangConf. 

Чтобы почувствовать приближение Нового Goда, регистрируйтесь на офлайн-участие — сможете поучаствовать в технических интерактивах и получить подарки. А если вы не в Нижнем, присоединяйтесь к последнему Go-митапу в 2024 году онлайн.

Привет, Хабр! Меня зовут Матвей, я staff-инженер по автоматизации тестирования в компании Купер (кто это такие — можете почитать в статье). Сегодня хочу остановиться на ключевых трудностях, которые ставит перед тестированием микросервисная архитектура, и рассказать, как мы в компании справляемся с этими вызовами с помощью экспериментальных подходов.

Введение

Обработка заказов — это один из самых сложных аспектов в e-commerce, особенно когда речь идёт о микросервисной архитектуре. Большинство существующих систем используют хореографию для управления заказами, что сложно реализовать и часто приводит к беспорядку. Бизнес-требования разбиты на множество мелких задач, и обеспечить отказоустойчивость бывает трудно. В таких системах часто возникает низкая прозрачность, поиск дефектов может занять дни, а внедрение новой функциональности — месяцы. Проблему можно решить с помощью платформы для оркестрации рабочих процессов.

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

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

Да, мы уже знаем самые популярные практики: KISS, DRY, YAGNI, SOLID, что там ещё... Мы умеем их применять. Но нас не покидает чувство, что все эти практики объединяет общая научная основа. Знаете, это как с Менделеевым, который на основе закономерностей практически по наитию составил периодическую систему, а потом открыли электроны и всё встало на свои места.

У меня для вас хорошие новости: научная основа есть. Это предметно-ориентированное проектирование.

Но есть и плохая новость: тема настолько новая и непростая в изучении, что какая-никакая популярность к ней пришла лет 5 назад, и до сих пор совсем небольшое число разработчиков достаточно хорошо в ней разбирается.

Но есть ещё одна хорошая новость: в статье ниже я постараюсь дать максимально понятный ответ, что же такое предметно-ориентированное проектирование.

Начнём.

Привет, Хабр! Я Маша Башан, Python разработчик в команде dBrain. Сегодня расскажу, как в dBrain мы внедрили собственную стратегию тестирования, которая в разы сокращает количество действий работающих с платформой инженеров. Мы применили альтернативный вариант тестирования — с помощью сервиса Apache Airflow.

Здравствуйте, друзья! Меня зовут Константин, я python backend developer из компании «Окенит». Сегодня я хочу рассказать свое видение проблемы новичка при ознакомлении с принципами SOLID, описанными в книге «Стерильная Архитектура» Робина Мартерта.

За свой десятилетний опыт я часто был свидетелем ситуации, когда молодые разработчики, желая сделать свой проект как можно более открытым для расширения и редактирования, превращали его в груду нечитаемого и неподдерживаемого кода при попытке использовать у себя все рекомендации Матушки Роба. Отсюда вопрос: «Почему, при следовании советам более опытного разработчика, код стал только хуже?».

Ответ на этот вопрос пришел ко мне очень быстро. Из‑за описания и без того абстрактных вещей чересчур абстрактными словами и примерами, Робин Мартерта вместо упорядочивания знаний, наводит хаос в умы читателей. Во избежание этой ситуации я решил написать данную статью, где коротко расскажу о наборе принципов SOLID, для чего они нужны и, главное, как применять эти принципы в жизни. Начнем по порядку, с буквы «S». И так, что же она значит?

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

Но если для REST API уже всемирную славу приобрел Open API со своей Swagger-документацией, которая внедряется практически повсеместно и является по праву, так сказать, золотым стандартом, то для брокеров сообщений и, в целом для асинхронного взаимодействия, в большинстве случаев дела обстоят далеко не так однозначно.

В данной статье я хотел бы подробнее остановиться на довольно молодом типе спецификации для асинхронного взаимодействия - AsyncAPI, который, на мой взгляд, имеет огромный потенциал и все шансы на массовое применение в будущем.

На некоторых порталах, в том числе и здесь, уже косвенно поднималась тема AsyncAPI и вызывала у авторов, как правило, смешанные чувства. Описывали преимущества и недостатки, приводили некоторые примеры. Справедливо отметить, что AsyncAPI, конечно же, не идеален.

Но если посмотреть на это с другой стороны: удобно ли будет разработчику читать ТЗ и другую документацию касаемо разработки интеграции по асинхрону, слепленную из кусков текста, таблиц, рисунков, непонятных ссылок и т.д.? Одно дело, если разработчик находится на проекте с самого начала и знает все тонкости и может сам что-то додумать. Но если человек придет на проект уже через один, два или более лет после начала проекта и увидит тонны макулатуры, которую как-то нужно читать и анализировать, то вот тут начинаются трудные времена.

Привет! Меня зовут Максим Соколов, я — аналитик в команде “Управление доступностью товаров и категорий”. В нашей команде была выделена отдельная подгруппа, которая создавалась специально под новый продукт-фичу для селлеров. Сразу стало понятно, что для реализации нового функционала требуется разработка нового микросервиса. Командой разработки было принято решение интегрироваться по gRPC, но мне до конца не было понятно, почему выбор именно такой. И тут я решил разобраться подробнее!

До этого я занимался анализом доработок по уже существующему функционалу, поэтому не задавался вопросом, почему выбран тот или иной путь реализации API. Но здесь-то всё с нуля, а специалисту, который дебютирует в этом выборе, становится ещё трудней.

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

На свете много статей про проектирование API, в которых описаны архитектурные стили, протоколы, технологии. Информации — огромное количество, иногда она даже противоречивая, поэтому новичку тяжело подступиться к теме.

В этой статье я хочу дать точку входа для джун/мидл системных аналитиков, которые хотят разобраться в межсервисной интеграции. Мы пройдёмся по HTTP, REST, RPC и gRPC, разберёмся в их значениях. Выясним, почему эти аббревиатуры появляются, когда происходит проектирование API, и попробуем понять, когда и что следует применять.

Также по ходу статьи буду оставлять ссылки на хорошие (по моему мнению) статьи для более глубокого погружения в поднимаемые темы.

Кэширование с 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. Прибыльность и рентабельность с налогом и без.

Заинтересует бизнесменов и бухгалтеров как альтернативное универсальное ПО для налогового и управленческого учета и сравнения разных налоговых режимов.