Top.Mail.Ru
Tdg » 1.6 » 1. Руководство по разработке приложений » 1.5. Представление модели
 
1. Руководство по разработке приложений / 1.5. Представление модели
1. Руководство по разработке приложений / 1.5. Представление модели

1.5. Представление модели

1.5. Представление модели

При эксплуатации TDG объекты могут поступить в систему постфактум, а запросы к системе могут быть сделаны по функциональному срезу для определенной бизнес-даты.

Поэтому, чтобы поддерживать обратную совместимость при разработке приложения для TDG, нужно версионировать все, что непосредственно влияет на логику его работы:

  • Avro схему модели (единый формат);
  • конвейеры обработки входящих объектов;
  • код Lua-функций, составляющих конвейеры и методы объектов модели;
  • (потенциально) фабрики объектов;
  • (потенциально) триггеры;
  • (потенциально) описание сервисов.

Чтобы поддерживать историчность и эволюцию модели, TDG представляет ее в едином формате – Lua-структуре, состоящей из примитивных типов. Ее легко преобразовать в JSON и обратно для передачи по сети.

Чтобы версионировать собственную структуру, система использует следующие форматы конфигурации для разных целей:

1.5.1. Внутренний формат конфигурации

Узлы кластера передают конфигурацию по сети и хранят ее в следующем формате:

{
    "functions": {
        "function_name": "function_code"
        ...
    },
    "pipelines": {
        "pipeline_name": ["function1_name", "function2_name", ...],
        ...
    },
    "classifiers": {
        "classifier_name": "pipeline_name/function_name",
        ...
    },
    "routing": {
        "routing_key": "pipeline_name/function_name",
        ...
    },
    "storage": {
        "routing_key": "type_name"
    },
    "schema": <avro_schema>
}

где:

  • functions – набор функций, которые используются в классификаторах, маршрутизаторах и объектах модели;
  • pipelines – конвейеры, в которых функции применяются к объекту по цепочке;
  • classifiers – позволяют получить ключ маршрутизации для объекта;
  • routing – функции, позволяющие менять ключ маршрутизации объекта;
  • storage – хранилище для объектов с соответствующими ключами маршрутизации;
  • function_name – имя (идентификатор) Lua-функции;
  • function_code – код Lua-функции (исполняемый в «песочнице»);
  • pipeline_name – имя конвейера;
  • classifier_name – имя классификатора;
  • routing_key – строковый ключ маршрутизации.

Также в формате присутствует поле schema, формат которого описан в разделе о доменной модели. В этом поле хранится структурное (а не строковое) ее представление.

1.5.2. Внешний (экспортный) формат

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

Экспортный формат соответствует внутреннему, за исключением следующих полей:

  • Вместо function_codefunction_file_name, файл, в котором находится код Lua функции.
  • Вместо avro_schemaavro_file_name, файл, в котором сериализована Avro схема модели.

Корневой объект сохраняется в файле config.yml; код функций – в соответствующие файлы с расширением .lua, рядом; а схема – в файл schema.avsc.

1.5.3. Экспортный формат бандла моделей

Экспортный формат бандла (комплекта) может использоваться для удобной передачи разработчикам модели, загруженной в систему. Бандл – папка, содержащая в себе набор моделей, каждая в своей подпапке. Подпапки названы по бизнес-времени действия модели (а не по фактическому времени добавления).

Например:

bundle/
├── 2018-01-03T18:56:00Z
|   ├── config.yml
|   ├── schema.avsc
|   ├── function_1.lua
|   └── function_2.lua
└── 2018-03-05T00:41:00Z
    ├── config.yml
    ├── schema.avsc
    └── function_3.lua

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