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

В продолжении к предыдущей статьи, погружение в nx.

Практический урок по написанию собственного плагина, на примере react приложения.

Вторая часть статьи "Наблюдаемость сетевой инфраструктуры Kubernetes" про рассмотрение Observability инструментов.

В этой части мы сравним разворачиваемые решения в выбранном сетевом сценарии на основе собранных метрик приложения и кластера Kubernetes. Сделаем выводы о дальнейшем использовании инструментов в DevOps/K8S окружении.

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

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

Почему асинхронность так важна для наших микросервисов? Представьте себе множество людей, ожидающих в лифте – каждый из них хочет двигаться своим темпом, и никто не хочет ждать, когда лифт подойдет к нужному этажу. Так и в мире микросервисов – каждый сервис может заниматься своей задачей, не блокируя другие. Асинхронность позволяет нам этим заниматься: вместо того чтобы ждать ответа от одного сервиса, мы можем отправить запрос другому и эффективно использовать время, пока ждем ответа.

Пару месяцев назад я рассказал вам о своем фреймворке для работы с различными брокерами сообщений - Propan.

Тезисно повторю: это идейный наследник FastAPI, но для написания асинхронных микросервисов (привет, Kombu). Он настолько облегчает взаимодействие с брокерами сообщений, что данный архитектурный паттерн переходит из разряда

слишком сложно, это для хайлоад, некогда разбираться

в разряд

а давай отдадим нашему стажеру сервис, он по документации разберется

(Причем это реальный кейс)

Иногда полезно оглянуться назад, подвести черту и сложить в одну кучу все, что накопилось за время работы. И вот этот момент настал и для Propan. Я просто хочу вам рассказать о тех важных изменениях, которые я внедрил за прошедшие два месяца и планах на будущее.

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

Статья описывает кейс разработки микросервисной системы. При работе над системой была использована теория, описанная в статье "Математические аспекты хорошего кода".

В рамках этого кейса описаны:

• Снижение когнитивной нагрузки на программиста

• "Квантовая" архитектура

• Автоматическая обработка данных

• Аспектно-ориентированное программирование

• Генерация кода (T4)

• Метапрограммирование

• Межсервисное взаимодействие

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

Q: Почему "квантовые"?
A: Потому что являются одновременно микросервисами и монолитом.

Всем привет! Я Антон Телицын, продакт-менеджер в Тинькофф. Расскажу про наш опыт управления качеством продукта. Для меня качество продукта отражается через его соответствие ожиданиям пользователя, но глобально качество продукта во многом зависит от надежности, скорости и доступности сервисов, которые его составляют.

Всем привет, меня зовут Абай. Я являюсь Back-End разработчиком в 13LAB.

После прочтения интересной статьи со сравнением NodeJS и FastAPI, у меня появилось желание высказать свое личное мнение об удобстве разработки бэкенда на Python и фреймворке FastAPI.

FastAPI - является легковесным асинхронным фреймворком для Python, который используют преимущественно для разработки API-сервисов. Фреймворк довольно молодой и существует всего лишь 5 лет. До 2021 года не имел большой популярности по сравнению с Flask и Django, но на данный момент уже стал намного востребованнее, что его стали использовать в МAANG компаниях, к примеру...

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

Реализацией RPC запросов поверх брокеров сообщений никого не удивишь: очередь для запроса, очередь для ответа — ничего сложного.

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

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

На самом деле, в RabbitMQ есть механизм и для такого сценария. Но он спрятан в недрах документации и о нем почти нет информации в интернете (особенно рабочих примеров кода).

Вот это недоразумение мы сейчас и исправим.

Обычно мы подключаем сбор метрик в prometheus к нашим web‑приложениям с помощью каких‑то клиентских библиотек, которые отдают метрики на /metrics. В этой статье я хочу рассказать как визуализировать Latency с помощью Histogram метрики.

Будет полезно тем, кто еще не строил метрики из Prometheus, а так же тем, кто хочет понять как их интерпретировать.

Хорошо быть умелым разработчиком и самому закрывать все задачи по запуску микросервисных приложений. Но как быть, если команда разработчиков тратит все время на управление микросервисными приложениями, настройку систем безопасности, аутентификации, мониторинга, логирования? Можно писать код и самостоятельно запускать каждый компонент, а можно нажать несколько кнопок и развернуть микросервис. Именно для этого мы создали консоль в платформе контейнеризации dBrain.cloud. В этой статье хотим подробнее рассказать, зачем и кому она будет полезна.

Около десяти лет назад мы в CUSTIS реализовали систему распределения товара для «Спортмастера». Со времени ее запуска изменилось многое: корректировались цели заказчика, менялись возможности и потребности рынка, появились новые способы автоматизации. Но на протяжении всех этих лет система дорабатывалась, поддерживалась и настраивалась нами, чтобы оставаться максимально удобной и эффективной для заказчика.

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

Привет, Хабр! С вами Андрей Чернов — Java-архитектор микросервисов в СберТехе.

Это третья часть материала про то, как мы развиваем Platform V SessionsData — высокопроизводительное распределённое in-memory хранилище для общего контекста сессионных запросов key-value. В первой части я рассказал, почему мы решили создать собственный микросервис, а во второй — как нам удаётся достигать высокой доступности сервиса. Сегодня поговорим о том, какие наработки помогут нам и дальше развивать Platform V SessionsData.

В этой статье будут рассмотрены инструменты наблюдения за сетевой инфраструктурой Kubernetes и основные составляющие Observability/Наблюдаемости – мониторинг, журналы событий, метрики, распределенная трассировка и оповещения. Обсудим, как эти инструменты могут помочь обеспечить надежную и эффективную работу кластеров Kubernetes и запущенных на них микросервисах, а также какие преимущества и недостатки существуют при использовании этих решений.

Эта статья для DevOps, Kubernetes administrators и SRE инженеров, которым важно и интересно разобраться в том, как устроена сетевая инфраструктура Kubernetes, какое взаимодействие происходит на уровне ядра Linux и различных приложений (Go, Java, Python и т.п.); изучить две обширные технологии eBPF и OpenTelemetry, активно продвигаемые CNCF сообществом. А главное при помощи каких инструментов можно упростить принятие решений инженерам при использовании Kubernetes в своих проектах и продуктах.

Всем привет! Продолжаем наш цикл статей о внедрении подхода Design API First на проектах нашей компании. Ранее мы рассмотрели использование этого подхода, описали плюсы и минусы, узнали, как на практике выглядит проектирование API на примере сервиса аутентификации. Сегодня расскажем о том, как мы встраиваем Design API First в наш конвейер разработки, подробно остановимся на инструментах, помогающих с технической точки зрения организовать этот процесс. Объясним, как реагировать на изменения требований и обеспечивать версионность, а также что использовать для мокирования данных. Рассмотрим различные варианты применения: для нового проекта, для существующего проекта (где изначально был Code First).

4 часть: Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений

5 часть: Design API First. Кодогенерация Roslyn