9.1. Архитектуралық ұсыныстар¶
Бұл бөлім платформаны практикалық пайдалану тәжірибесіне және аппараттық-бағдарламалық қамтамасыз етуге қойылатын экономикалық негізделген талаптарға сүйенген архитектуралық ұсыныстарды қамтиды.
Ұсыныстар пайдаланудың әртүрлі сценарийлеріне бағытталған және жүктеме сипаттамаларын да, масштабтау мен сенімділік талаптарын да ескереді.
9.1.1. Инфрақұрылымға қойылатын минималды талаптар¶
Инфрақұрылымды таңдаған кезде платформаны пайдаланудың мақсатты сценарийі мен күтілетін жүктемеден шыққан жөн.
9.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-орталарына және корпоративтік енгізулерге ұсынылады.
9.1.1.2. Dev Instance¶
Dev Instance мыналарға арналған:
- әзірлеуге;
- шешімдерді демонстрациялауға;
- кейстер мен прототиптерді көрсетуге.
5 бір мезгілдегі пайдаланушыға дейін жүктемеге есептелген.
Минималды талаптар:
- CPU: 4 vCPU
- RAM: 8 GB
- Storage: ~25 GB
- Network: минималды, пайдалану сценарийіне байланысты
Dev Instance ретінде әзірлеушінің жұмыс ноутбугі немесе арзан виртуалды машина пайдаланылуы мүмкін.
9.1.2. Мультиинстанс-архитектура (process-to-process)¶
Айқын ұйымдық құрылымы бар ірі ұйымдарда (бас компания, еншілес ұйымдар, филиалдар, департаменттер) мультиинстанс-тәсілді пайдалану ұсынылады.
Тәсілдің мәні мынада: Synergy даналары ұйымдық құрылым логикасы бойынша орналастырылады — әрбір ұйымдық бірлікке (мысалы, әрбір еншілес ұйымға немесе ірі контурға) жеке инстанс бөлінеді.
Бұл тәсіл мыналарға мүмкіндік береді:
- ұйымдық бірліктер арасындағы процестер мен деректерді оқшаулауға;
- кіру контурларын бөлу арқылы қауіпсіздік деңгейін арттыруға;
- ақаулыққа төзімділікті жоғарылатуға (бір инстанстағы сәтсіздік қалғандарының жұмысын тоқтатпайды);
- жүктемені бірнеше инстанс арасында бөлу арқылы масштабтауды жеңілдетуге;
- әртүрлі контурлар үшін өзгерістер мен сүйемелдеудің тәуелсіз циклдерін қолдауға.
Мультиинстанс-архитектураны пайдаланған кезде инстанстар арасында process-to-process өзара іс-қимыл құруға болады: бір инстанстағы процестің орындалуы екінші инстанстағы процестің жалғасуын немесе жеке бөлігін бастауы мүмкін (компанияның жалпы бизнес-логикасы шеңберінде).
9.1.2.1. Жиынтық инстанс¶
Қосымша ретінде мыналар үшін жалпы деңгей ретінде пайдаланылатын жиынтық инстанс бөлінуі мүмкін:
- орталықтандырылған анықтамалықтар;
- жиынтық есептілік пен аналитика;
- еншілес контурлардағы процестер нәтижелерін шоғырландыру.
Жиынтық инстанс жұмыс инстанстарының оқшаулануы мен дербестігін бұзбай, деректердің бірыңғай көздерін және бірыңғай есептілік деңгейін қамтамасыз етеді.
Note
Мультиинстанс-архитектураны таңдау бірнеше ұйымдық контур болған кезде және кіру, жауапкершілік пен жүктемені бөлу қажет болғанда ұсынылады.
9.1.3. Пайдаланушы порталдарына арналған архитектуралық ұсыныстар¶
Сыртқы пайдаланушы порталдарын жобалаған кезде бір мезгілдегі пайдаланушылар санын және жүктеме профилін ескеру ұсынылады.
9.1.3.1. 1000 бір мезгілдегі пайдаланушыға дейінгі сценарий¶
1000 бір мезгілдегі пайдаланушыға дейінгі жүктемеде Synergy платформасының стандартты құралдарын пайдалану ұсынылады.
Бұл сценарийде:
- пайдаланушы порталы тікелей Synergy-де іске асырылады;
- пішіндер, бизнес-валидациялар, маршруттар және транзакциялар платформа ішінде орындалады;
- инфрақұрылымдық талаптар минималды;
- жүктеме профилі болжамды.
Мұндай тәсіл мыналарды қамтамасыз етеді:
- жылдам time-to-market;
- жеңілдетілген архитектура;
- пайдалану шығындарының азаюы.
9.1.3.2. 1000 бір мезгілдегі пайдаланушыдан асқан сценарий¶
1000 бір мезгілдегі пайдаланушыдан асқан жүктеме highload класына жатады және жеке архитектуралық жобалауды қажет етеді.
Бұл жағдайда ұсынылады:
- сыртқы пайдаланушы порталын дербес highload-қолданба ретінде әзірлеу;
- горизонталды масштабтауды қолдану;
- архитектураны нақты жүктеме профиліне сай жобалау.
Бұл сценарийде Synergy-мен өзара іс-қимыл:
- асинхронды түрде;
- хабарлар кезегі арқылы;
- міндетті rate limiting пайдалана отырып;
- тек API және оқиғалар арқылы орындалуы тиіс.
Бұл архитектурада Synergy процестік және жұмыс ядросы рөлін атқарады, ал сыртқы портал пайдаланушы өзара іс-қимылының барлық жүктемесін өз мойнына алады.
9.1.4. Жалпы ұсыныстар¶
Архитектуралық тәсілді таңдаған кезде ұсынылады:
- мақсатты жүктеме профилін нақты анықтау;
- мерзімінен бұрын оңтайландырудан аулақ болу;
- орташа жүктемеде Synergy-дің стандартты құралдарын пайдалану;
- объективті қажеттілік болған кезде ғана highload-компоненттерді сыртқы сервистерге шығару.
Осы ұсыныстарды сақтау жүйенің иелену құны, өнімділігі және масштабталуы арасындағы оңтайлы тепе-теңдікке қол жеткізуге мүмкіндік береді.