Базовая архитектура ==================== .. contents:: :depth: 3 Система Citeck ECOS построена на основе микросервисной событийно-ориентированной архитектуры. В качестве основного способа взаимодействия микросервисов используется обмен сообщениями через очередь сообщений (MQ). Платформа поддерживает работу с различными источниками данных без необходимости копирования данных во внутренний репозиторий. Для работы с данными используется собственный язык запросов Records API. Перечень источников данных может быть легко расширен. Компоненты системы: * **DAO services** – сервисы работы с контентом и метаданными. В качестве источников данных могут использоваться Alfresco Content Service, Базы данных, 1С, SAP и другие; * **Process services** – сервисы управления бизнес-процессами, поддерживаются нотации моделирования бизнес-процессов BPMN и CMMN; * **Application services** – сервисы управления приложениями ECOS, их версионностью и деплойментом; * **Data services** – сервисы работы с данными, в том числе валидации данных и их индексации; * **Integration services** – интеграционные сервисы, включая ЮЗДО; * **API gateway** – API шлюз, используется в том числе для запросов от пользовательского интерфейса (WEB и мобильного); * **Business logic services** – сервисы бизнес-логики и конфигурации. Интерфейс системы разработан на базе фреймворка **ReactJS **в виде статичных **JS библиотек**, которые раздаются через NGINX и работают под управлением веб-браузеров на пользовательских устройствах. Мобильный интерфейс разработан на базе фреймворка **React Native**, также поддерживается адаптивная верстка для мобильных браузеров. Запросы от пользовательских интерфейсов маршрутизируются через **NGINX** и **API шлюз**. ПО Citeck ECOS развертывается с использование сервисов контейнеризации Docker / Kubernetes. .. image:: _static/base/Arch_1.png :width: 600 :align: center Микросервисы -------------- .. image:: _static/base/Arch_2.png :width: 600 :align: center .. list-table:: :widths: 10 30 :header-rows: 1 :class: tight-table * - Компонент - Описание * - **ecos-ui** - Контейнер с nginx (openresty) и UI статикой (js + css). * - **ecos-registry** - Реестр приложений и сервер Spring Cloud конфигурации. * - **ecos-gateway** - Микросервис реализует API шлюза взаимодействия с остальными микросервисами. * - **ecos-apps** - Микросервис, управляющий деплоем приложений и артефактов ECOS. * - **ecos-notifications** - Микросервис рассылки нотификаций (email, push-нотификации и др.). * - **ecos-model** - Микросервис моделей. Отвечает за информацию о типах, шаблонах нумерации и о матрицах прав. * - **ecos-history** - Микросервис для хранения истории. Подписан на события в системе и сохраняет информацию о них в БД. * - **ecos-process** - Микросервис для управления BPMN процессами. * - **ecos-eis** - Приложение Keycloak для аутентификации в системе. * - **alfresco** - Open-source ECM система, которая может использоваться для хранения контента и метаданных документов в системе (один из вариантов реализации). * - **solr** - Система индексации метаданных и контента документов. * - **ecos-uiserv** - Микросервис, предоставляющий элементы UI и хранящий их настройки (меню, журналы, UI конфиги, формы, настройки журналов, дашборды). * - **ecos-integrations** - Микросервис позволяет организовывать интеграции с внешними системами. * - **ecos-transformations** - Микросервис для преобразования (трансформации) контента. На данный момент обеспечивает: * Конвертацию из doc/docx в pdf * Накладывание баркода на pdf файлы * - **zookeeper** - Приложение для хранения конфигураций в системе. Изменения конфигурации подхватываются приложениями «на лету». * - **Rabbit MQ** - Приложение для обмена сообщениями между микросервисами. Хранение данных ----------------- 1. Основная используемая реляционная база данных – **PostgreSQL**. 2. Основная NoSQL база данных – **Mongo DB**. 3. Опционально для высоконагруженных систем возможно использование **Cassandra DB**. 4. Хранение метаданных поддерживается в любой системе через адаптер (record source). Существующие адаптеры: **PostgreSQL, Oracle DB, MS SQL, Mongo DB, Alfresco ECM, SAP HANA**. 5. Для хранения документов может быть использована **БД PostgreSQL, Alfresco ECM или внешняя ECM система через адаптер** (например, разработан адаптер к системе OpenText). 6. Помимо баз данных используется также прямая запись в файловую систему для приложений **Alfresco (Content Store), Zookeeper, Rabbit MQ и Solr**. Зависимости компонентов ------------------------ .. image:: _static/base/Arch_3.png :width: 600 :align: center 1. Центральной частью системы ECOS является абстракция ****, в качестве которого может выступать любой источник данных в любом из микросервисов ECOS. Для добавления новых источников достаточно реализовать определенный интерфейс и данные из этого источника могут быть свободно интегрированы со всей экосистемой ECOS (их можно отображать в журнале, редактировать и просматривать через формы, отправлять по ним уведомления, запускать по ним процессы и т. д.). Общение с источниками данных построено на базе универсального :ref:`Records API`. Зависимости от **** по микросервисам: - **ecos-uiserv** загружает атрибуты для фильтрации UI действий по заданным в конфигурации условиям; - **ecos-notifications** загружает атрибуты для заполнения шаблона уведомления; - **ecos-history** загружает атрибуты для сохранения записи в истории; - **ecos-process** загружает и меняет атрибуты в ходе выполнения BPMN процессов; - **alfresco** загружает и меняет атрибуты в ходе выполнения CMMN процессов. 2. Почти все микросервисы работают с **Rabbit MQ** (события и команды) и с **Zookeeper** (события, конфигурация ECOS и конфигурация типов); 3. **UI** (мобильный и браузерный) зависят от **ecos-gateway** (шлюз для доступа в систему) и от **ecos-uiserv** (микросервис с UI конфигурациями); 4. **ecos-gateway** зависит от **ecos-model** для получения информации по пользователям и группах, в которых они состоят. Эта информация используется для формирования JWT-токена с последующей отправкой его в остальные микросервисы для аутентификации и авторизации; 5. **ecos-integrations** зависит от внешних систем, с которыми настроена интеграция; 6. **Alfresco** зависит от **Solr** (поиск по индексам) и от микросервиса **ecos-process** (хранение состояния процессов в системе); 7. **Solr** зависит от **alfresco** для индексации данных. Взаимодействие клиента с сервером ----------------------------------- .. image:: _static/base/Arch_4.png :width: 600 :align: center При первом поступлении запроса от клиента **nginx** видит, что пользователь не имеет токена и отправляет его на **Keycloak** для аутентификации через протокол OpenID Connect. **Keycloak** может предложить окно ввода логина/пароля или сразу выдать пользователю токен, с помощью которого он сможет зайти в систему (SSO). После успешной аутентификации пользователь перенаправляется на страницу, с которой его отправили в keycloak. После того, как запрос прошел дальше, **ecos-gateway** смотрит на URL запроса и по нему решает, какой именно микросервис должен его обработать (например, запрос **/emodel/api/records/query** должен уйти в **ecos-model**). Для получения IP адреса и порта целевого микросервиса **ecos-gateway** обращается в **ecos-registry** за нужной информацией и, получив её, отправляет запрос дальше. События ---------- .. image:: _static/base/events_1.png :width: 600 :align: center **События** в ECOS позволяют менять атрибутивный состав, который нужен подписчику на событие, без модификации источника событий. При старте системы все подписчики регистрируют в Zookeeper список необходимых им событий по типам и атрибуты события, в которых они заинтересованы. Приложение, которое может отправлять события подобного типа, видит, что в системе есть подписчики на эти события, и, при их возникновении, подготовив необходимый список атрибутов, отправляет их в Rabbit MQ. Атрибуты описываются в формате :ref:`Records API` и могут пользоваться всеми преимуществами данного API. .. image:: _static/base/events_2.png :width: 600 :align: center Приложения ------------ :ref:`Приложения ECOS` позволяют выгружать из системы нужные артефакты в формате **zip** и деплоить их «на горячую» в другую систему. :ref:`Артефакт` – единица расширения в Citeck ECOS. Артефактами являются формы, журналы, типы, матрицы прав, действия, описания процессов и многие другие сущности в системе. Микросервис **ecos-apps** управляет артефактами, ведя их версионность и доставляя их до целевого микросервиса. Контент артефактов в системе неизменяемый и при любом изменении артефакта всегда создается новая версия, а старая сохраняется в списке версий. .. image:: _static/base/Apps_1.png :width: 600 :align: center Доставка артефактов при старте системы происходит в 3 этапа: 1. Микросервис **ecos-apps**, увидив новый микросервис в сети, загружает из него список типов, в которых он заинтересован. 2. Получив типы, **ecos-apps** рассылает на все остальные микросервисы запрос на получение артефактов с данными типами. 3. Получив нужные артефакты со всех микросервисов, **ecos-apps** проверяет, изменился ли их контент с прошлого деплоя. Если изменений нет, то алгоритм заканчивает свою работу. Если изменения есть, то происходит деплой новых данных в целевой микросервис. Кластеризация -------------- **Кластеризация** — разворачивание нескольких инстансов приложения для обработки большой нагрузки и повышения отказоустойчивости системы. Особенности: 1. Логически система работает одинаково вне зависимости от количества инстансов приложения; 2. Инстансы приложения в кластере как правило работают с одними и теми же хранилищами данных (БД, файловая система); 3. Кластеризация нужна для отказоустойчивости и распределения нагрузки по CPU, RAM и сети. Кластеризация микросервисов в системе Citeck ECOS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. image:: _static/base/cluster_1.png :width: 400 :align: center 1. Для разворачивания кластера микросервисов мы просто поднимаем несколько инстансов приложения; 2. При старте все приложения регистрируются в **ecos-registry**, указывая при этом свой IP, HOST и PORT; 3. Балансировкой нагрузки занимается **ecos-gateway**. Когда приходит запрос от пользователя за некоторым ресурсом, **ecos-gateway** по информации в **ecos-registry** определяет список инстансов нужного приложения. После этого запрос уходит на один из инстансов по алгоритму round-robin; 4. **ecos-registry** регулярно проверяет приложения (health-check). Если приложение перестало отвечать, то запросы на него отправляться не будут.