2DApp

Разработка проектов на микросервисах

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

Мои координаты:

Меня зовут Дмитрий, и это мой Pet-проект

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

CI/CD обеспечивает быструю и надежную доставку изменений в продакшн. Автоматизированные процессы тестирования и развертывания значительно сокращают время выхода новых функций, а изолированность микросервисов минимизирует риски при обновлениях, так как проблемы в одном сервисе не влияют на работу остальной системы.

  • Архитектура

    Main image

    * Некоторые области картинки, в частности контейнеры, кликабельны (в десктопной версии сайта).

    На изображении представлена архитектурная схема микросервисного приложения, развернутого с помощью Docker Compose. Разберем её компоненты:

    1. Клиентская часть:
      • Telegram клиент
      • SPA (Single Page Application)
      • Web Client (веб-клиент)
    2. Промежуточный слой:
      • Nginx Server в роли API Gateway (обратный прокси)
      • Тот же сервер для Static Content (статический контент)
    3. Микросервисы, все написаны на Node.js:
      • TGBOT Service (бот для работы с Telegram)
      • DWH Service (сервис для работы с хранилищем данных)
      • PRODUCT Service (сервис для работы с продуктами, например подписки на что-либо)
      • USER Service (сервис для работы с пользователями)
      • CRON Service (сервис для выполнения периодических задач)
    4. Серверная инфраструктура:
      • REDIS Server (для кэширования)
      • MYSQL Server (реляционная база данных)
      • MONGODB Server (нереляционная база данных)
      • RABBITMQ Server (брокер сообщений)
      • CERTBOT Server (сервис для работы с сертификатами)
    5. Взаимодействие между компонентами:
      • Клиенты общаются с системой через API Gateway
      • Микросервисы взаимодействуют между собой через брокер сообщений RabbitMQ
      • Пунктирные линии показывают связи определенных микросервисов с базами данных

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

  • CI/CD для бэкенда

    Main image

    * IDE и VPS области картинки кликабельны (в десктопной версии сайта).

    На изображении показана схема процесса CI/CD (Continuous Integration/Continuous Deployment) развертывания бэкенд приложений. Разберем каждый этап:

    1. Начало процесса:
      • Разработка в IDE (например в WebStorm)
      • Комит кода (commit) в систему контроля версий Github
    2. GitHub:
      • Код хранится в репозитории GitHub (без боевых .env файлов)
    3. VPS (Virtual Private Server):
      • Запускается Github Actions Self-Hosted Runner - система для выполнения CI/CD задач установленная на VPS (Self-Hosted Runner):
        • Этап PREPARE (Подготовка):
          • Остановка контейнеров и сетей
          • Удаление неиспользуемых данных
        • Этап DEPLOY (Развертывание) с использованием Docker Compose:
          • Получение кода из репозитория
          • Настройка продакшн окружения (.env файл)
          • Сборка продакшн версии
          • Запуск тестов
          • Проверка развертывания
          • Очистка
          • Отправка уведомления о развертывании

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

  • CI/CD для фронтенда

    Main image

    * IDE и GitHub области картинки кликабельны (в десктопной версии сайта).

    На изображении показана схема процесса автоматизированного развертывания (CI/CD pipeline) фронтенд части приложения, которая включает следующие этапы:

    1. Начинается с разработки в IDE, откуда происходит коммит кода
    2. Код отправляется в GitHub репозиторий
    3. Далее запускается GitHub Actions (на стороне самого GitHub)
    4. В процессе выполняются следующие шаги:
      • Получение кода из репозитория
      • Установка Node.js
      • Установка зависимостей
      • Сборка проекта с помощью Gulp (фронтенд включает в себя ряд отдельных приложений и сборка осуществляется каждого в свой bundle)
      • Установка SSH-ключа из secrets в GitHub Actions (если его еще нет на VPS)
      • Подключение по SSH и развертывание на VPS (rsync)
      • Отправка уведомления о развертывании

    Вся схема наглядно демонстрирует процесс автоматической доставки кода от разработки до продакшена с использованием современных инструментов CI/CD.

    • В этом Pet-проекте размещение всех микросервисов в одном репозитории (монорепозиторий) существенно ограничивает ключевые преимущества микросервисного подхода:

    1. Утрачивается независимость команд - все разработчики вынуждены координировать изменения в одном репозитории, что создает конфликты и замедляет разработку
    2. Затрудняется масштабирование - при большом количестве сервисов репозиторий становится громоздким и сложным для навигации
    3. Усложняется CI/CD - приходится настраивать сложные пайплайны, которые должны определять, какой именно сервис изменился и требует пересборки
    4. Отсутствует изоляция - проблемы с кодом одного сервиса могут повлиять на сборку других сервисов

    Рекомендуется переходить к подходу "один сервис - один репозиторий", что позволит:

    • Командам работать действительно независимо
    • Упростить процессы CI/CD
    • Уменьшить риски при внесении изменений
    • Обеспечить лучший контроль версий для каждого сервиса

    Предоставление исходников по требованию потенциального работодателя!

    © 2025 Dmitry Dementiev