6.1. Архитектурные рекомендации¶
Данный раздел содержит архитектурные рекомендации, основанные на практическом опыте эксплуатации платформы и экономически обоснованных требованиях к аппаратному и программному обеспечению.
Рекомендации ориентированы на разные сценарии использования и учитывают как нагрузочные характеристики, так и требования к масштабируемости и надежности.
6.1.1. Минимальные требования к инфраструктуре¶
При выборе инфраструктуры рекомендуется исходить из целевого сценария использования платформы и предполагаемой нагрузки.
6.1.1.1. Enterprise Instance¶
Enterprise Instance предназначен для промышленной эксплуатации и рассчитан на нагрузку до 1000 именованных пользователей и до 300 конкурентных пользователей.
Целевой показатель SLA — время отклика до 3 секунд при стабильной нагрузке.
Минимальные требования к инфраструктуре:
- CPU: 16 vCPU
- RAM: 64 GB
- Storage: 1 TB NVMe
- Network: до 20 TB трафика
Оценочная стоимость аренды виртуальной машины с такими характеристиками составляет порядка 150–200 USD в месяц.
Данный вариант рекомендуется для production-окружений и корпоративных внедрений.
6.1.1.2. Dev Instance¶
Dev Instance предназначен для:
- разработки;
- демонстрации решений;
- показа кейсов и прототипов.
Рассчитан на нагрузку до 5 конкурентных пользователей.
Минимальные требования:
- CPU: 4 vCPU
- RAM: 8 GB
- Storage: ~25 GB
- Network: минимальные, зависят от сценария использования
В качестве Dev Instance может использоваться рабочий ноутбук разработчика или недорогая виртуальная машина.
6.1.2. Мультиинстанс-архитектура (process-to-process)¶
В крупных организациях с выраженной организационной структурой (головная компания, дочерние организации, филиалы, департаменты) рекомендуется использовать мультиинстанс-подход.
Суть подхода заключается в том, что экземпляры Synergy разворачиваются по логике организационной структуры: отдельный инстанс - на отдельную организационную единицу (например, на каждую дочернюю организацию или крупный контур).
Данный подход позволяет:
- изолировать процессы и данные между организационными единицами;
- повысить уровень безопасности за счет разделения контуров доступа;
- повысить отказоустойчивость (сбой в одном инстансе не останавливает работу остальных);
- упростить масштабирование за счет распределения нагрузки по нескольким инстансам;
- поддерживать независимые циклы изменений и сопровождения для разных контуров.
При использовании мультиинстанс-архитектуры допускается построение process-to-process взаимодействия между инстансами, когда выполнение процесса в одном инстансе может инициировать продолжение или отдельный участок процесса в другом инстансе (в рамках общей бизнес-логики компании).
6.1.2.1. Сводный инстанс¶
Дополнительно может быть выделен сводный инстанс, который используется как общий уровень для:
- централизованных справочников;
- сводной отчетности и аналитики;
- консолидации результатов процессов из дочерних контуров.
Сводный инстанс позволяет обеспечить единые источники данных и единый слой отчетности, не нарушая при этом изоляцию и автономность рабочих инстансов.
Примечание
Выбор мультиинстанс-архитектуры рекомендуется при наличии нескольких организационных контуров и необходимости разделения доступа, ответственности и нагрузки.
6.1.3. Архитектурные рекомендации по пользовательским порталам¶
При проектировании внешних пользовательских порталов рекомендуется учитывать количество конкурентных пользователей и профиль нагрузки.
6.1.3.1. Сценарий до 1000 конкурентных пользователей¶
При нагрузке до 1000 конкурентных пользователей рекомендуется использовать стандартные средства платформы Synergy.
В данном сценарии:
- пользовательский портал реализуется непосредственно на Synergy;
- формы, бизнес-валидации, маршруты и транзакции выполняются внутри платформы;
- инфраструктурные требования минимальны;
- профиль нагрузки предсказуем.
Такой подход обеспечивает:
- быстрый time-to-market;
- упрощенную архитектуру;
- снижение эксплуатационных затрат.
6.1.3.2. Сценарий свыше 1000 конкурентных пользователей¶
Нагрузка свыше 1000 конкурентных пользователей относится к классу highload и требует отдельного архитектурного проектирования.
В данном случае рекомендуется:
- разрабатывать внешний пользовательский портал как самостоятельное highload-приложение;
- применять горизонтальное масштабирование;
- проектировать архитектуру под конкретный профиль нагрузки.
Взаимодействие с Synergy в этом сценарии должно выполняться:
- асинхронно;
- через очереди сообщений;
- с обязательным использованием rate limiting;
- исключительно через API и события.
В данной архитектуре Synergy выступает в роли процессного и рабочего ядра, а внешний портал берет на себя всю нагрузку пользовательского взаимодействия.
6.1.4. Общие рекомендации¶
При выборе архитектурного подхода рекомендуется:
- четко определять целевой профиль нагрузки;
- избегать преждевременной оптимизации;
- использовать стандартные средства Synergy при умеренных нагрузках;
- выносить highload-компоненты во внешние сервисы только при наличии объективной необходимости.
Соблюдение данных рекомендаций позволяет достичь оптимального баланса между стоимостью владения, производительностью и масштабируемостью системы.