Skip to main content

Структура ядра

MorphCluster - это система организации структуры и взаимодействия внутри системы из множества процессов.


Задачи системы:

  • Автоматическая организация связи внутри системы. MorphCluster находит и организует связь между различными частями системы в микросервисной архитектуре системы.

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

  • Отслеживание состояния системы - позволить следить за тем, как работает система, выявлять и локализовать ошибки и зависания в реальном времени

  • Тестирование. Система позволяет запускать определенные части системы и проверять их работу, в процессе работы всей системы.

  • Масштабирование

  • Модульность и взаимозаменяемость

  • Возможность дробления и слияния модулей

Структура ядра MorphCluster.

Хост

Корневой модуль запускаемый в процессе, который хранит остальные сущности и и управляет запуском системы.

Разделение системы на хосты

Готовые модули


Транспорт

Транспорт - абстракция для определения способа взаимодействия между хостами


Контекст

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

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

  • Журнал выполнения - позволяет отслеживать действия которые были завершены, и просматривать отладочные данные,.

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

  • Информация о вызове. Внутри контекста хранится информация о том, кто создал этот контекст

  • Данные о пользователе, если это внешний вызов. Это позволяет ограничивать доступ к системе и данным.

C

Схема сервиса

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


Сервис

Сервисы определяют неделимую единицу функционала приложения.


  • Имя сервиса идентифицирует его в системе и должно быть уникально.

  • Сервис, определенный, как локальный будет доступен только в пределах своего хоста. На разных хостах могут быть одноименные локальные сервисы.

  • Сервис имеет состояние, показывающее, когда он будет готов к работе. В случае сбоя — сервис может сообщить о невозможности продолжить работу, и о восстановлении такой возможности (например, подключение к базе).

  • Запросы позволяют выполнять специализированное действие, для управления сервисом или получения данных из него или с его помощью.

  • События вызываются изнутри сервиса и другие сервисы могут быть на него подписаны, для создания действия, во время выполнения события.

  • Управления хостом. Сервис имеет ограниченный интерфейс, для того чтобы определять, какие сервисы, которые находится на одним с ним хостом запущены, и для получения прямого доступа к этим сервисам.

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

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

  • Клиент – это способ взаимодействия между сервисами, который описывает схему сервиса, которая нужна текущему сервису, в котором он объявляен. Клиент позволяет организовывать зависимости с удаленными сервисами расположенными на другом хосте, также если клиент ссылается на сервис того же хоста, то вызов будет налажен без использования транспорта

  • Таймер позволяет удобно запускать периодические действия внутри сервиса, инициированные с определенным промежутком времени.

  • Триггер позволяет инициировать внутри сервиса действие, например, в случае получения запроса из внешней системы. Основные компоненты системы.

Основные компоненты системы

Registry

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

С помощью локального сервиса RegistryHelper можно легко получить актуальный реестр без обработки событий.



Sessions

Сессии соответственно хранят информацию о доступе, подтвержденную токеном. Токен создается при авторизации или иным способом. Пользователю или внешнему сервису нужен токен для взаимодействия с системой через шлюз. Система через него идентифицирует пользователя. Сессия может быть определена как привилегированная(isAdmin), что расширяет возможности такого пользователя.

Gateway

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

Bridge

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

Auth



Nats

NAТS реализует транспорт через брокер.

ContextMonitor

Монитор контекста позволяет увидеть все текущие контексты, а также выполнить прервание.

Logger

Логгер хранит весь процесс выполнение контекста для отслеживания уже выполненных контекстов, выполненных запросов или иных вызовов системы.

Back to top