Внутренние компоненты

Сложная обработка.Понятная архитектура.

RedMule объединяет собственные интеграционные механизмы, микросервисы и транзакционное хранилище. Архитектура разделяет задачи и сохраняет целостность управления.

Изучить возможности
МикросервисыPostgreSQLОркестрация
ОбработкаЛогика
ТранспортСообщения
УправлениеПараметры
РедМулВнутренняя оркестрация
PostgreSQLСостояние
КонфигурацииОбъекты
ИсторияОперации
Внутренние компонентыСхема принципа работы

Разделение задач

Микросервисы исполняют функциональность в общей системе.

Управляемое состояние

Конфигурации, связи и история хранятся в транзакционной модели.

Собственный движок

Обработка, коммуникации и диагностика доступны внутри РедМул.

Что получает ваша команда

Платформа для исполнения интеграций - с общей моделью состояния и сопровождения.

01 / Микросервисы

Микросервисы в единой платформе

Разделение функциональности сохраняет общую картину управления.

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

  • Разделение функциональности между сервисами.
  • Внутренние стандарты взаимодействия компонентов.
  • Оркестрация и управление исполнением.
  • Масштабирование с учётом зависимостей архитектуры.
Технические подробности
Микросервисы REDMULE / 01
Микросервисы / механизм
ОбработкаЛогика
ТранспортСообщения
УправлениеПараметры
RedMuleВнутренняя оркестрация
PostgreSQLСостояние
КонфигурацииОбъекты
ИсторияОперации
Иллюстрация принципа работы / Внутренние компоненты
02 / Хранилище

Транзакционная модель состояния

Настройки, связи и история опираются на PostgreSQL.

Внутреннее хранилище содержит сущности интеграционной модели, отношения между ними, конфигурации и историю операций. PostgreSQL используется как СУБД по умолчанию, а чувствительные учётные данные и токены защищаются механизмами платформы.

  • Сущности и связи интеграционной модели.
  • Конфигурации платформы и подключений.
  • История операций в пределах настроенного периода.
  • Защищённое хранение чувствительных учётных данных.
Технические подробности
Хранилище REDMULE / 02
Хранилище / механизм
PostgreSQLКонфигурации, сущности и связи
01
История операцийСостав и срок хранения
02
Защищённые данныеУчётные параметры и токены
03
Иллюстрация принципа работы / Внутренние компоненты

Возможности, которые дополняют решение

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

02

Собственные интеграционные механизмы

Обработка сообщений, API и диагностика доступны как функции платформы.

Подробнее
04

История под задачи эксплуатации

Состав сохраняемых данных и срок хранения определяют глубину диагностики.

Подробнее
05

Перенос конфигураций и данных

Экспорт поддерживает развитие среды и эксплуатационные процессы.

Подробнее
06

Прозрачность зависимостей

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

Подробнее
Прикладной сценарий / пример

За одним обменом работают несколько компонентов.

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

01
ИсполнитьВыполнить функциональные шаги.
02
СохранитьЗафиксировать нужное состояние и историю.
03
НаблюдатьСвязать события компонентов с операцией.
Для архитектора и технической команды

Техническая спецификация

Механизмы, варианты применения и архитектурные условия. Полное описание каждой темы - в одном месте.

01 Микросервисы в единой платформеРазделение функциональности сохраняет общую картину управления.

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

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

  • Разделение функциональности между сервисами.
  • Внутренние стандарты взаимодействия компонентов.
  • Оркестрация и управление исполнением.
  • Масштабирование с учётом зависимостей архитектуры.
Микросервисы / механизм
ОбработкаЛогика
ТранспортСообщения
УправлениеПараметры
RedMuleВнутренняя оркестрация
PostgreSQLСостояние
КонфигурацииОбъекты
ИсторияОперации
Подробнее Микросервисная архитектура платформы

Завершённая информационная система как набор взаимосвязанных микросервисов с внутренней оркестрацией и управлением нагрузкой.

РедМул построен как архитектурно завершённая информационная система, состоящая из набора взаимосвязанных микросервисов. Каждый сервис отвечает за строго определённую часть функциональности, общается с другими по внутренним коммуникационным стандартам и управляется общей оркестрацией платформы. Для базовой инфраструктуры используются проверенные продукты категории Open Source Software, на которых строится собственная функциональность РедМул.

Платформа реализована как набор взаимосвязанных микросервисов.

Каждый микросервис исполняет строго определённую логику.

Взаимодействие между сервисами осуществляется по внутренним коммуникационным стандартам.

Автоматическое управление микросервисами в рамках внутренней оркестрации.

Использование ряда готовых open source‑продуктов для обеспечения базовой функциональности архитектуры.

02 Собственные интеграционные механизмыОбработка сообщений, API и диагностика доступны как функции платформы.

Интеграционная логика реализована в РедМул: обработка и маршрутизация сообщений, взаимодействие с внешними брокерами, вызовы сервисов и наблюдение за исполнением. Команда использует эти возможности в общей модели настройки, вместо самостоятельного проектирования базового интеграционного движка.

Это не означает отсутствия открытых компонентов в технологической основе. Инфраструктурные зависимости, например OpenJDK и PostgreSQL, следует отличать от готового стороннего интеграционного продукта.

  • Собственные механизмы обработки и маршрутизации.
  • Взаимодействие с внешними брокерами через поддерживаемые протоколы.
  • Вызовы и публикация API средствами платформы.
  • Диагностика и наблюдение за исполнением.
Собственные функции / механизм
Интеграционный движокСообщенияAPIМониторинг
Подробнее Собственные компоненты платформы

Собственные компоненты для мониторинга, обработки сообщений, работы с брокерами и вызова API вместо предустановленных OSS‑решений.

Основные интеграционные функции мониторинга, транспорта сообщений и вызова API реализованы средствами RedMule. При этом технологическая основа использует открытые инфраструктурные компоненты; их состав определяется поставкой. ключевые интеграционные функции реализованы собственными средствами платформы, а необходимые интеграции и взаимодействия настраиваются через её механизмы.

Встроенные функции мониторинга и диагностики реализованы средствами платформы; внешние системы мониторинга и анализа могут подключаться через интеграции.

Транспортная функциональность предоставляется средствами РедМул; внешние брокеры могут использоваться как интегрируемые системы. Состав инфраструктурных зависимостей указывается для поставки.

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

Вызовы веб-сервисов и API доступны как функции РедМул. Использование открытых инфраструктурных библиотек следует отличать от зависимости от отдельного интеграционного продукта.

03 Транзакционная модель состоянияНастройки, связи и история опираются на PostgreSQL.

Внутреннее хранилище содержит сущности интеграционной модели, отношения между ними, конфигурации и историю операций. PostgreSQL используется как СУБД по умолчанию, а чувствительные учётные данные и токены защищаются механизмами платформы.

Нагрузка на СУБД зависит от количества операций, объёма сохраняемых данных и глубины истории. Поэтому дисковая подсистема и режим хранения проектируются вместе с исполнительными компонентами.

  • Сущности и связи интеграционной модели.
  • Конфигурации платформы и подключений.
  • История операций в пределах настроенного периода.
  • Защищённое хранение чувствительных учётных данных.
Хранилище / механизм
PostgreSQLКонфигурации, сущности и связи
01
История операцийСостав и срок хранения
02
Защищённые данныеУчётные параметры и токены
03
Подробнее Транзакционное хранилище и экспорт данных

PostgreSQL по умолчанию, хранение сущностей и истории операций, конфигураций и учётных данных с возможностью экспорта.

В качестве СУБД по умолчанию в РедМул используется PostgreSQL - за счёт стабильности и высокой производительности при работе с большими объёмами данных. Транзакционная база данных хранит все сущности, необходимые для интеграций, связи между ними и историю операций за выбранный период. В ней же находятся зашифрованные данные аутентификации и токены, а также конфигурационные настройки системы. Компоненты потоков данных и конфигурация могут экспортироваться в виде дампов или CSV‑таблиц, а если хранение полной истории не требуется, его можно отключить либо сократить период хранения.

СУБД по умолчанию - PostgreSQL, выбранная за стабильность и производительность на больших объёмах данных.

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

Хранение связей между сущностями и истории операций за выбранный период.

Зашифрованное хранение данных аутентификации и токенов.

Сохранение конфигурационных настроек системы РедМул в транзакционной БД.

Экспорт компонентов потоков данных (конфигурации, конечные точки) и конфигурационных настроек в виде дампов или CSV‑таблиц.

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

04 История под задачи эксплуатацииСостав сохраняемых данных и срок хранения определяют глубину диагностики.

RedMule позволяет управлять периодом хранения операций и объёмом сохраняемых данных. Команда выбирает баланс между подробностью расследования, чувствительностью информации и ресурсами хранилища. История события и копия сообщения могут решать разные задачи сопровождения.

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

  • Настройка периода хранения операций.
  • Выбор необходимой глубины истории.
  • Контроль доступа к содержимому сообщений.
  • Оценка роста хранилища при изменении нагрузки.
История / механизм
СобытияЧто произошло
01
ДанныеЧто обрабатывалось
02
ПериодСколько хранить
03
05 Перенос конфигураций и данныхЭкспорт поддерживает развитие среды и эксплуатационные процессы.

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

Выгрузка конфигурации не заменяет полноценную резервную копию всей системы. Для восстановления дополнительно учитывают состояние БД, версии компонентов, секреты и инфраструктурные параметры.

  • Экспорт конфигурационных настроек и объектов.
  • Выгрузки в поддерживаемых форматах.
  • Контроль состава переносимых учётных данных.
  • Проверка совместимости при переносе между средами.
Перенос / механизм
ЭкспортВыбор объектов
01
ПереносЦелевая среда
02
ПроверкаСвязи и параметры
03
06 Прозрачность зависимостейСервисы, хранилище и внешние системы рассматриваются как части одного обмена.

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

Для сопровождения фиксируют связи и контрольные точки между частями решения. Это позволяет отличать внутренний сбой платформы от ошибки окружения или недоступности внешней системы.

  • Контроль исполнительных компонентов.
  • Наблюдение за транзакционным хранилищем.
  • Проверка внешних подключений и доступов.
  • Единая картина зависимостей при диагностике.
Зависимости / механизм
КомпонентыИсполнение
ХранилищеСостояние
Внешние системыРезультат
Настраиваемая логика обработки

Следующие возможности

Все возможности
Технологии Назначение каждого слоя понятно архитектору, разработчику и эксплуатации. Масштабируемость Мощность и доступность развиваются вместе с интеграционным ландшафтом. Расширение Специальные требования получают своё место в управляемой архитектуре.

СЛЕДУЮЩИЙ ШАГ

Обсудим вашу интеграционную задачу

Покажем платформу на ваших сценариях и поможем оценить архитектуру решения

0/500 символов
Не удалось отправить заявку. Попробуйте позже.

Заявка отправлена

Ваш контакт
Сообщение

Спасибо! Мы свяжемся с вами в ближайшее время.