Какая она, новая архитектура DirectumRX 3.2?

Архитектура До и После

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

Для начала вспомним, как выглядела архитектура в версии 3.1 и ниже. А именно ту часть, которая была изменена:

Сервисы DirectumRX представляли собой веб-приложения службы Internet Information Services (IIS) и взаимодействовали между собой посредством очереди сообщений MSMQ. Чтобы в дальнейшем поддерживать работу на свободно распространяемом ПО Linux, появился вопрос, как обеспечить работу сервисов. Кроме того, при работе через IIS пулы сервисов потребляли много памяти, что могло приводить к зависанию веб-приложений. Это послужило еще одним условием, чтобы оптимизировать схему работы DirectumRX:

В версии 3.2 сервисы системы DirectumRX переведены на микросервисы – это независимые self-hosted приложения, каждое из которых выполняет узкоспециализированную задачу. За счет использования микросервисов архитектура системы обеспечивает:

• гибкое распределение нагрузки по серверам. Для наращивания мощности системы достаточно установить несколько экземпляров сервисов на разные сервера. При этом можно масштабировать только то, что нужно, и с меньшими затратами на аппаратное обеспечение. Например, если вы заметили, что задачи сотрудников долго доставляются или зависают, вы можете ускорить обработку задач, установив несколько экземпляров сервисов Workflow.
• стабильность работы. При сбое или отключении одного из сервисов, остальные продолжают работать, и система всегда остается доступной для пользователей. Например, если останавливается сервис предпросмотра документов, то в системе можно продолжать отправлять задачи на согласование, создавать документы, папки и пр.
• возможность обновления по сервисам. За установку, обновление и корректную работу сервисов отвечает Агент управления сервисами ServiceRunner. Он представляет собой службу Windows. Агент следит за состоянием сервисов, и если некоторые сервисы выходят из строя или меняются их конфигурационные файлы, агент отслеживает изменения и обновляет только нужные сервисы.

Сервисы общаются друг с другом через брокер сообщений RabbitMQ. Таким образом, гарантируется доставка сообщений, даже если один из сервисов недоступен. Приобретать ПО не требуется, пакет для установки компонент RabbitMQ сразу входит в состав дистрибутива DirectumRX. А в инструкции по установке и в инструкции по обновлению подробно описано, как установить и настроить RabbitMQ.

Состав микросервисов

Состав сервисов, которые входят в стандартную поставку, значительно расширился. Для сравнения покажем схему:

Сервисы Workflow

Для поддержки компаний, которые используют свободно распространяемое ПО, разработан новый движок для обработки задач Workflow. Он написан на .NET Core. Как мы к этому пришли можно детальнее почитать в статье «Как мы сделали свой движок Workflow» на сайте habr.com.

Кроме того, сервис Workflow разделен на два микросервиса:

• Сервис обработки схем задач (Workflow Process Service, WPS) – определяет, по какой схеме отправлять задачу в работу, выбирает блок для выполнения и ставит его в очередь RabbitMQ на выполнение. Помимо этого, сервис хранит состояние выполнения блоков схемы на каждом этапе работ и оперативно управляет отложенными операциями, если во время выполнения блока возникает исключение.
• Сервис выполнения блоков схем задач (Workflow Block Service, WBS) – стартует работы по блоку схемы задачи, который указан в очереди на обработку, отслеживает его выполнение и передает результаты сервису Workflow Process Service.

Благодаря переходу на новый движок и микросервисы система DirectumRX:

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

Думаю, вам также интересно знать, а смогут ли задачи, созданные в прошлых версиях, корректно работать на новых сервисах? – Да, смогут. Исключением являются задачи, которые прежний сервис Workflow не смог обработать. Чтобы найти такие задачи, в состав дистрибутива добавлена утилита WorkflowConverter.exe. Нужно запустить утилиту с ключом –check и проверить записи в лог-файле. Список задач, указанных в лог-файле, необходимо пересмотреть и обработать.

Например, если задача приостановлена по ошибке, в лог-файле появляется запись вида:

2019-07-30 14:19:27.0858 Warn WorkflowInstance is Suspended. InstanceId=115697 TaskId=3626 SchemeName=ApprovalTaskRouteDocflowSungero ProcessId=100950d0-03d2-44f0-9e31-f9c8dfdf3829
2019-07-30 14:19:27.0858 Info Fix instance by aborting task. TaskId=3626; ProcessId=100950d0-03d2-44f0-9e31-f9c8dfdf3829

Или если задача стартована, но в базе данных процесс по каким-либо причинам не создался, вы увидите запись вида:

2019-07-30 14:19:06.8571 Warn Task doesn't have WorkflowInstance. TaskId=67 SchemeName= ProcessId=ae03c598-ab50-4781-b1b2-968510b338b9
2019-07-30 14:19:06.8571 Info Fix instance by aborting task. TaskId=67; ProcessId=ae03c598-ab50-4781-b1b2-968510b338b9

Как правило, это старые задачи, с которыми никто не работал, и они не имеют ценности. При обновлении они прекращаются.

А вот задачи с блокировками хорошо поддаются обработке. Например, в момент выполнения блока задачи пользователь заблокировал документ, который требовалось подписать. В этом случае в лог-файле утилиты появляется запись вида:

2019-10-15 12:37:37.0930 Warn Found locked blocks. TaskId=85. Problems:
2019-10-15 12:37:37.0930 Warn Cannot lock. The item "Incoming Letter" with ID 47 is already locked.
2019-10-15 12:37:37.0930 Warn LockedEntityType=8dd00491-8fd0-4a7a-9cf3-8b6dc2e6455d; LockedEntityId=47
2019-10-15 12:37:37.1086 Warn Found non-convertible block states. TaskId=85 BlocksIds = [4]

Чтобы подготовить задачу к обновлению, достаточно доработать скрипт DeleteEntityLocks.sql, который входит в состав утилиты, и выполнить его. В скрипте нужно лишь указать параметры LockedEntityId (ИД заблокированного типа сущности) и LockedEntityType (Заблокированный тип сущности) из лог-файла утилиты. Еще больше подробностей о порядке обновления читайте в инструкции по обновлению DirectumRX.

Обратите внимание, что структура инструкции обновлена. Теперь в ней проще ориентироваться, не нужно высчитывать промежуточные версии, искать, программу какой версии использовать для обновления. Выбирайте нужный раздел, например, «Обновление с версии 3.0, 3.1 до 3.2» и выполняйте указанный порядок действий. Все просто!

Сервисы для запуска фоновых процессов

С целью масштабирования сервис агентов также переведен на несколько микросервисов:

• Сервис планировщика (Scheduler) – вычисляет, когда необходимо запускать фоновые процессы согласно расписанию, и посредством сообщений передает информацию сервису асинхронных событий.
• Сервис асинхронных событий (Worker) – служит для асинхронного выполнения фоновых процессов по запросу сервиса планировщика. Также сервис можно использовать для выполнения других вычислений. Например, которые оказывают нагрузку на сервер приложений, веб-сервер или требуют специально настроенного окружения: ОС, программное обеспечение и пр.

Сервисы для предпросмотра документов

Для удобства работы с офисными документами в версии 3.2 появилась возможность открывать их в браузере для просмотра, не запуская приложения-редакторы. Чтобы эта возможность работала, в архитектуру встроено еще несколько микросервисов:

• Сервис предпросмотра (PreviewService) – обслуживает запросы веб-сервера на предпросмотр выбранной версии документа в веб-клиенте и формирует содержимое для предпросмотра.
• Сервис хранения файлов предпросмотра (PreviewStorage) – хранит данные, подготовленные сервисом предпросмотра, и по запросу клиентского приложения предоставляет их. А благодаря тому, что сервис сохраняет данные в кэше, при очередном открытии документа пользователем содержимое документа отображается быстрее. Это хорошо сэкономит время ваших сотрудников.

Особенности установки

Как уже говорили ранее, брокер сообщений RabbitMQ устанавливается вручную по инструкции. В программе установки задаются только параметры подключения системы DirectumRX к брокеру сообщений. Параметры задаются такие же, как на сервере RabbitMQ, и все действия выполняются в один шаг:

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

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

Также, чтобы упростить развертывание системы DirectumRX и сервера БД в распределенной среде, для администратора написаны соответствующие инструкции. Они доступны на сайте поддержки DIRECTUM в формате PDF:

• «DirectumRX 3.2. Настройка фермы серверов и NLB-кластера» – описывает, как обеспечить отказоустойчивость серверов DirectumRX с помощью создания фермы серверов и NLB-кластера (Network Load Balancing). Инструкция подходит для СУБД Microsoft SQL Server и PostgreSQL.
• «DirectumRX 3.2. Настройка отказоустойчивой архитектуры для PostgreSQL» – описывает, как обеспечить отказоустойчивость сервера БД по Linux-подобных операционных системах. Инструкция подходит для СУБД PostgreSQL.

Скачивайте, пользуйтесь, с нетерпением ждем обратной связи!

Оптимизация веб-клиента

Вдобавок, чтобы архитектура DirectumRX справлялась с большими нагрузками, оптимизированы ключевые узкие места системы. Например, получение списков, которые содержат более 1 млн. записей, механизм проверки прав. Для проверки внесенных изменений в разработку проведены массовые нагрузочные тесты на базе данных Microsoft SQL Server с 5000 пользователей и 100 миллионами документов. Тесты показали, что многие действия пользователей в системе, кроме формирования сложных отчетов, выполняются за 2 секунды.

Теперь значительно быстрее выполняется:

• поиск документов, задач и заданий в проводнике DirectumRX;
• поиск в выпадающих списках, например, в карточках объектов, диалоговых окнах, на панели фильтрации;
• открытие, сортировка и фильтрация списков, папок и результатов поиска. Например, при открытии большого списка теперь отображаются только 1 000 последних созданных записей, которые удовлетворяют настройкам фильтрации и сортировки;
• открытие карточек задач и заданий;
• создание и сохранение изменений в карточках групп регистраций и сотрудников;
• вход в систему DirectumRX при одновременном подключении тысяч пользователей, например, в начале рабочего дня или после обеденного перерыва.

И это не все. В статье перечислены только примеры оптимизированных мест системы. Подробнее список доработок представлен в документе «Изменения DirectumRX 3.2».

* * *

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

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