Перейти к основному содержанию
`Ctrl`+`K`

# Схема развертки системы «МедЭксперт»

## Общая архитектура

Ниже представлена и описана схема основных компонентов и особенностей работы системы «МедЭксперт»: сервера приложений, базы данных, функциональность репликации базы данных (разделение базы данных), взаимодействие веб-клиента и др.

Схема развётки

Система развернута на нескольких серверах, взаимодействующих между собой для распределения нагрузки и повышения надёжности:

Компоненты системы

- Основной сервер (ies.service)
- Сервер Расчётника (ies.service)
- Сервер Отчетов (ies.service)
- Настройка Компонентов
- Настройка Маршрутизации Процессов
- Сервер Экспертизы и REST API (ies.service)
- Сервер логирования (OpenSearch)
- Web-клиент

Все серверы приложений (а также Web-клиент) работают под управлением ОС семейства RedOS/Astra/Alt Linux и используют единый стек технологий (.NET 8.0, RSysLog).

### Shared Folders

`Shared Folders` представляет собой сетевое файловое хранилище, физически расположенное на основном сервере.

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

### RabbitMQ

Брокер сообщений, развёрнутый на основном сервере. Используется для интеграции со сторонними системами (к примеру получение счетов на загрузку и расчёт стоимости услуг).

### Microsoft SQL Server

В системе используется Microsoft SQL Server для реляционного хранения данных.

- На основном сервере работает первичный (главный) экземпляр БД, в который вносятся все изменения.

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

- Сервер отчётов и сервер экспертизы и REST API работают с подчинёнными экземплярами (репликами) основной базы данных. Службы МЭ на этих серверах сконфигурированы для выполнения операций чтения (SELECT).

Служба МЭ на основном сервере выполняет синхронизированные операции `INSERT`, `UPDATE`, `DELETE`. Служба на сервере отчетов/экспертизы сконфигурирована для выполнения только операций чтения (`SELECT`), работая с локальной репликой. Для поддержания актуальности данных между экземплярами настроена репликация.

### Служба МЭ

Основная служба системы, реализованная на платформе `.NET 8.0`. Экземпляры службы развёрнуты на нескольких специализированных серверах для распределения нагрузки:

- На основном сервере: обрабатывает все транзакции, изменяющие состояние данных (запись), и управляет ядром бизнес-логики.

- На сервере отчётов: специализируется на формировании отчётов и сложных выборках данных, работая в режиме чтения.

- На сервере расчётника: выполняет фоновые и ресурсоёмкие вычислительные задачи (расчёты), синхронизируя настройки с основным сервером.

- На сервере экспертизы и REST API: является основной точкой входа для веб-клиента. Принимает клиентские запросы, обслуживает операции чтения, проводит экспертизы и предоставляет внешний программный интерфейс (API). Запросы на изменение данных маршрутизирует на основной сервер.

Внутреннее взаимодействие между серверами осуществляется по протоколу HTTP. Все экземпляры службы взаимодействуют с `RSysLog` для централизованной отправки логов и данных аудита на сервер логирования (OpenSearch и т.п.).

### RSysLog

Система централизованного сбора и обработки логов, а также данных аудита. Службы МЭ и другие компоненты отправляют структурированные логи на локальный агент RSysLog.

Агент, в свою очередь, перенаправляет, парсит и индексирует эти логи в целевое хранилище (например, `OpenSearch`) для мониторинга, поиска, анализа событий и других операций.

## Репликация базы данных

Для синхронизации данных между серверами используется механизм репликации Microsoft SQL Server для распределения работы служб и оптимизированной работы с данными. Функциональность применима для выполнения запросов на выборку данных (SELECT). Здесь:

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

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

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

### Общая информация

- Репликация используется для передачи изменений таблиц (таких как счетов-реестров, актов от СМО и т.п.) с сервера отчетов на основной сервер.

- Массовая синхронизация проводится раз в сутки в 20:00.

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

Список таблиц для репликации

       T_FILE
       T_FILE_CONTENT
       T_FILE_LOAD_HISTORY
       T_FILE_REQUEST
       T_FILE_RESPONSE
       T_KPG
       T_KSG
       T_KSG_CALC
       T_KSG_CRIT
       T_KSLP
       T_LOAD_HISTORY
       T_MTR_SCHET_OUT_LINK
       T_MTR_SCHET_PROTOCOL
       T_MTR_SCHET_ZAP_ERROR
       T_SCHET
       T_SCHET_ACT
       T_SCHET_ACT_FILE
       T_SCHET_ACT_ITEM
       T_SCHET_FILE
       T_SCHET_LOAD_HISTORY
       T_SCHET_OPLATA
       T_SCHET_PAYMENT
       T_SCHET_PERIOD
       T_SCHET_PERIOD_HISTORY
       T_SCHET_RESULTS
       T_SCHET_SLUCH
       T_SCHET_SLUCH_ACCOMPLISHED
       T_SCHET_SLUCH_CONS
       T_SCHET_SLUCH_DEST
       T_SCHET_SLUCH_DEST_PK
       T_SCHET_SLUCH_DEST_PROFILE
       T_SCHET_SLUCH_DEST_SP
       T_SCHET_SLUCH_DEST_SUR
       T_SCHET_SLUCH_DS
       T_SCHET_SLUCH_LEK_PR
       T_SCHET_SLUCH_LS
       T_SCHET_SLUCH_NAZ
       T_SCHET_SLUCH_ONK
       T_SCHET_SLUCH_ONK_DIAG
       T_SCHET_SLUCH_ONK_PROT
       T_SCHET_SLUCH_PAY
       T_SCHET_SLUCH_SANK
       T_SCHET_SLUCH_SANK_EXP
       T_SCHET_SLUCH_SANK_HISTORY
       T_SCHET_SLUCH_SUM
       T_SCHET_SLUCH_SUMVPART
       T_SCHET_SUM
       T_SCHET_SUMVPART_TYPE
       T_SCHET_TARIFF_TYPE
       T_SCHET_USL
       T_SCHET_USL_MED_DEV
       T_SCHET_USL_NAPR
       T_SCHET_USL_ONK
       T_SCHET_USL_ONK_LEK_PR
       T_SCHET_USL_ONK_LEK_PR_DATE
       T_SCHET_USL_ONK_LEK_PR_INJ
       T_SCHET_USL_SCOPE_INFO
       T_SCHET_ZAP
       T_SMO_ACT
       T_SMO_ACT_ITEM
       T_SMO_ACT_ITEM_EXPERT
       T_SMO_EXPERTISE_ACT
       T_SMO_EXPERTISE_ACT_FILE
       T_SMO_EXPERTISE_BANK_FILE
       T_TOOTH
       T_USL_EIS

### Оптимизация базы данных

- Сжатие данных: Применяется стандартное сжатие на уровне таблиц и индексов в SQL Server для снижения объема хранимых данных.

- Удаление неиспользуемых индексов: Проводится аудит индексов для выявления и удаления неиспользуемых индексов с целью уменьшения нагрузки на базу данных.

- Архивирование устаревших данных:

    - В архивную среду выносятся исторические данные, превышающие установленный временной порог (напр., сведения по счетам-реестрам и экспертизам старше 2022 года).

    - Полная резервная копия базы данных перед процедурой архивации сохраняется на выделенном сетевом ресурсе для восстановления исторической информации при необходимости.

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

### Сжатие данных

Настройка сжатия данных (`Data Compression`) в Microsoft SQL Server позволяет уменьшить объем хранимой информации, используя сжатие строк и страниц.

Сжатие строк (`Row Compression`) оптимизирует хранение фиксированных данных, а сжатие страниц (`Page Compression`) дополнительно сжимает повторяющиеся значения на уровне страниц, что снижает потребление дискового пространства и улучшает производительность ввода-вывода за счет уменьшения объема обрабатываемых данных.

### Мониторинг состояния репликации

Мониторинг состояния репликации осуществляется с помощью:

- SQL Server Management Studio (SSMS): Для отслеживания производительности репликации используются системные представления, такие как `sys.dm_hadr_*`, что позволяет оперативно выявлять проблемы.

- Монитор репликации: Позволяет контролировать статус передачи данных и скорость репликации.

- Установлены правила оповещения при задержках более 30 секунд:

    - Оповещения приходят в записи событий в журнал мониторинга SQL Server.

    - Также предусмотрена возможность настройки автоматических оповещений по электронной почте при возникновении критических задержек.

### Отказоустойчивость

В системе реализован следующий механизм отказоустойчивости:

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

- После восстановления подчиненного сервера осуществляется синхронизация данных с использованием snapshot-снимков, что гарантирует целостность данных.