Архитектурные рекомендации ============================= Данный раздел содержит архитектурные рекомендации, основанные на практическом опыте эксплуатации платформы и экономически обоснованных требованиях к аппаратному и программному обеспечению. Рекомендации ориентированы на разные сценарии использования и учитывают как нагрузочные характеристики, так и требования к масштабируемости и надежности. Минимальные требования к инфраструктуре ---------------------------------------- При выборе инфраструктуры рекомендуется исходить из целевого сценария использования платформы и предполагаемой нагрузки. 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-окружений и корпоративных внедрений. Dev Instance ~~~~~~~~~~~~ **Dev Instance** предназначен для: * разработки; * демонстрации решений; * показа кейсов и прототипов. Рассчитан на нагрузку до **5 конкурентных пользователей**. Минимальные требования: * **CPU**: 4 vCPU * **RAM**: 8 GB * **Storage**: ~25 GB * **Network**: минимальные, зависят от сценария использования В качестве Dev Instance может использоваться рабочий ноутбук разработчика или недорогая виртуальная машина. Мультиинстанс-архитектура (process-to-process) ---------------------------------------------- В крупных организациях с выраженной организационной структурой (головная компания, дочерние организации, филиалы, департаменты) рекомендуется использовать мультиинстанс-подход. Суть подхода заключается в том, что экземпляры Synergy разворачиваются по логике организационной структуры: отдельный инстанс - на отдельную организационную единицу (например, на каждую дочернюю организацию или крупный контур). Данный подход позволяет: * изолировать процессы и данные между организационными единицами; * повысить уровень безопасности за счет разделения контуров доступа; * повысить отказоустойчивость (сбой в одном инстансе не останавливает работу остальных); * упростить масштабирование за счет распределения нагрузки по нескольким инстансам; * поддерживать независимые циклы изменений и сопровождения для разных контуров. При использовании мультиинстанс-архитектуры допускается построение process-to-process взаимодействия между инстансами, когда выполнение процесса в одном инстансе может инициировать продолжение или отдельный участок процесса в другом инстансе (в рамках общей бизнес-логики компании). Сводный инстанс ~~~~~~~~~~~~~~~ Дополнительно может быть выделен **сводный инстанс**, который используется как общий уровень для: * централизованных справочников; * сводной отчетности и аналитики; * консолидации результатов процессов из дочерних контуров. Сводный инстанс позволяет обеспечить единые источники данных и единый слой отчетности, не нарушая при этом изоляцию и автономность рабочих инстансов. .. note:: Выбор мультиинстанс-архитектуры рекомендуется при наличии нескольких организационных контуров и необходимости разделения доступа, ответственности и нагрузки. Архитектурные рекомендации по пользовательским порталам -------------------------------------------------------- При проектировании внешних пользовательских порталов рекомендуется учитывать количество конкурентных пользователей и профиль нагрузки. Сценарий до 1000 конкурентных пользователей ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ При нагрузке до **1000 конкурентных пользователей** рекомендуется использовать стандартные средства платформы Synergy. В данном сценарии: * пользовательский портал реализуется непосредственно на Synergy; * формы, бизнес-валидации, маршруты и транзакции выполняются внутри платформы; * инфраструктурные требования минимальны; * профиль нагрузки предсказуем. Такой подход обеспечивает: * быстрый **time-to-market**; * упрощенную архитектуру; * снижение эксплуатационных затрат. Сценарий свыше 1000 конкурентных пользователей ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Нагрузка свыше **1000 конкурентных пользователей** относится к классу **highload** и требует отдельного архитектурного проектирования. В данном случае рекомендуется: * разрабатывать внешний пользовательский портал как самостоятельное highload-приложение; * применять горизонтальное масштабирование; * проектировать архитектуру под конкретный профиль нагрузки. Взаимодействие с Synergy в этом сценарии должно выполняться: * асинхронно; * через очереди сообщений; * с обязательным использованием **rate limiting**; * исключительно через API и события. В данной архитектуре Synergy выступает в роли **процессного и рабочего ядра**, а внешний портал берет на себя всю нагрузку пользовательского взаимодействия. Общие рекомендации ------------------ При выборе архитектурного подхода рекомендуется: * четко определять целевой профиль нагрузки; * избегать преждевременной оптимизации; * использовать стандартные средства Synergy при умеренных нагрузках; * выносить highload-компоненты во внешние сервисы только при наличии объективной необходимости. Соблюдение данных рекомендаций позволяет достичь оптимального баланса между стоимостью владения, производительностью и масштабируемостью системы.