Давным-давно я работал в одной компании, где всё хостилось на одном-единственном сервере. Как это обычно бывает, в субботу вечером сгорел блок питания, и я, отдыхая в это время на природе, сидя в лодке, через телефон, при помощи консоли, пытался перенести сервер на другой хост.
Как вы уже поняли, мы поговорим об отказоустойчивости.
Привет, Хабр! Сегодня поговорим о нюансах разработки событийно-ориентированных микросервисов на Python. Я расскажу, почему считаю Python подходящим для разработки микросервисов, и покажу нюансы работы с ним. Меня зовут Алексей Некрасов, я лидер направления Python в МТС и программный директор курсов по Python в Skillbox. А материал — под катом.
Привет, Хабр! MTC Live — сервис по продаже билетов на развлекательные мероприятия с обязательным начислением кешбэка на все покупки. Сервис существует в двух ипостасях: в виде сайта и в качестве приложения, где можно купить билеты в театры, музеи, на концерты, стендапы, шоу и выставки. Сначала сервис был очень простым, а архитектура — базовой. В итоге её пришлось переделывать, поскольку нагрузки на систему возросли, а архитектура осталась прежней, ещё со времён пандемии, когда спрос на билеты был невысоким.
В статье речь пойдёт об этапах развития IT-продукта — от бизнес-идеи до промышленного Cloud-Native-решения, о проблемах и возможных способах их решения. Статья написана на основе интервью с участниками команды проекта MTC Live, а именно Александром Богдановым, руководителем проекта, CTO, и Сергеем Праводеловым, руководителем группы разработки, архитектором решения.
За последние несколько лет микрофронтенд, архитектурный подход, где независимые приложения собраны в одно комплексное приложение, набрал заметную популярность. Его достоинство в том, что он даёт возможность объединить в едином приложении разные виджеты, страницы, которые написаны разными разработчиками и/или командами с использованием разных фреймворков. Подробности, включая подходы к организации, — под катом.
Без хранилища данных не заработает ни одно stateful-приложение, это известно всем. А вот как и какое хранилище развернуть - это вопрос к специалистам. Сегодня расскажем, как мы “готовим” Ceph и в каких случаях используем TopоLVM и Minio.
В продолжении к предыдущей статьи, погружение в 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 реализовали систему распределения товара для «Спортмастера». Со времени ее запуска изменилось многое: корректировались цели заказчика, менялись возможности и потребности рынка, появились новые способы автоматизации. Но на протяжении всех этих лет система дорабатывалась, поддерживалась и настраивалась нами, чтобы оставаться максимально удобной и эффективной для заказчика.
В этой статье мы расскажем о себе, заказчике, системе и требуемых доработках. И о том, почему мы выбрали именно тот подход к проектированию архитектуры, который применили. И почему наше решение было оптимальным.
