Дүние бір орында тұрмайды. Прогресс жаңа технологиялық қиындықтарды тудырады. Өзгеретін талаптарға сәйкес ақпараттық жүйелердің архитектурасы дамуы керек. Бүгін біз оқиғаға негізделген архитектура, параллельдік, конкурренттілік, асинхрония және осының бәрімен Эрлангта қалай бейбіт өмір сүруге болатыны туралы сөйлесетін боламыз.
Кіріспе
Жобаланған жүйенің көлеміне және оған қойылатын талаптарға байланысты біз, әзірлеушілер, жүйеде ақпарат алмасу әдісін таңдаймыз. Көп жағдайда қызметтердің өзара әрекеттесуін ұйымдастыру үшін жұмыс опциясы брокермен схема болуы мүмкін, мысалы, RabbitMQ немесе kafka негізінде. Бірақ кейде оқиғалар ағыны, SLA және жүйені бақылау деңгейі дайын хабар алмасу бізге сәйкес келмейтіндей болады. Әрине, тасымалдау қабаты мен кластерді қалыптастыру үшін жауапкершілікті өз мойнына алу арқылы жүйені аздап қиындата аласыз, мысалы, ZeroMQ немесе nanomsg. Бірақ егер жүйеде стандартты Erlang кластерінің өткізу қабілеті мен мүмкіндіктері жеткілікті болса, онда қосымша нысанды енгізу мәселесі егжей-тегжейлі зерттеуді және экономикалық негіздеуді талап етеді.
Реактивті таратылған қосымшалардың тақырыбы өте кең. Мақаланың форматында сақтау үшін бүгінгі талқылау тақырыбы тек Erlang/Elixir негізінде құрылған біртекті орталар болады. Erlang/OTP экожүйесі ең аз күш жұмсай отырып, реактивті архитектураны жүзеге асыруға мүмкіндік береді. Бірақ кез келген жағдайда бізге хабар алмасу қабаты қажет болады.
Теориялық негізі
Дизайн мақсаттар мен шектеулерді анықтаудан басталады. Басты мақсат даму үшін даму аймағында емес. Біз қауіпсіз және масштабталатын құралды алуымыз керек, оның негізінде біз әртүрлі деңгейдегі заманауи қосымшаларды жасай аламыз және ең бастысы жасай аламыз: шағын аудиторияға қызмет көрсететін бір серверлік қосымшалардан бастап, кейінірек олар 50 кластерге дейін дами алады. -60 түйін, кластерлік федерациялармен аяқталады. Осылайша, түпкілікті жүйені игеру мен иеленуге кететін шығындарды азайту арқылы пайданы барынша арттыру басты мақсат болып табылады.
Соңғы жүйеге қойылатын 4 негізгі талапты бөліп көрсетейік:
- Соқиғаға бағытталған.
Жүйе әрқашан оқиғалар ағымынан өтуге және қажетті әрекеттерді орындауға дайын; - Мауқымдылық.
Жеке блоктарды тігінен де, көлденеңінен де масштабтауға болады. Бүкіл жүйе шексіз көлденең өсуге қабілетті болуы керек; - Оақауларға төзімділік.
Барлық деңгейлер мен барлық қызметтер сәтсіздіктерден автоматты түрде қалпына келтіру мүмкіндігі болуы керек; - Гкепілдік берілген жауап уақыты.
Уақыт құнды және пайдаланушылар тым көп күтпеу керек.
«Мүмкін болатын кішкентай қозғалтқыш» туралы ескі ертегі есіңізде ме? Жобаланған жүйе прототиптік кезеңнен сәтті шығып, прогрессивті болуы үшін оның негізі ең төменгі талаптарға сай болуы керек. SMOG.
Инфрақұрылымдық құрал және барлық қызметтердің негізі ретінде хабар алмасуға тағы бір тармақ қосылды: бағдарламашылар үшін пайдаланудың қарапайымдылығы.
Оқиғаға бағытталған
Бағдарламаның бір серверден кластерге өсуі үшін оның архитектурасы бос байланыстыруды қолдауы керек. Асинхронды модель осы талапқа жауап береді. Онда жіберуші мен алушы хабарламаның ақпараттық жүктемесіне қамқорлық жасайды және жүйе ішінде жіберу мен бағыттау туралы алаңдамайды.
Масштабтылық
Масштабтылық пен жүйенің тиімділігі бір-біріне жақын. Қолданбаның құрамдастары барлық қол жетімді ресурстарды пайдалана алуы керек. Біз қуаттылықты неғұрлым тиімді пайдалана алсақ және өңдеу әдістеріміз неғұрлым оңтайлы болса, жабдыққа соғұрлым аз ақша жұмсаймыз.
Бір машинаның ішінде Эрланг жоғары бәсекелестік орта жасайды. Сәйкестік пен параллельдік арасындағы тепе-теңдікті Erlang VM қол жетімді операциялық жүйе ағындарының санын және осы ағындарды пайдаланатын жоспарлаушылар санын таңдау арқылы орнатуға болады.
Erlang процестері күйді бөліспейді және блокталмаған режимде жұмыс істейді. Бұл блоктауға негізделген дәстүрлі қолданбаларға қарағанда салыстырмалы түрде төмен кідіріс пен жоғары өткізу қабілеттілігін қамтамасыз етеді. Erlang жоспарлағышы процессор мен IO-ның әділ бөлінуін қамтамасыз етеді, ал бұғаттаудың болмауы қолданбаға тіпті ең жоғары жүктемелер немесе сәтсіздіктер кезінде де жауап беруге мүмкіндік береді.
Кластер деңгейінде кәдеге жарату мәселесі де бар. Кластердегі барлық машиналар біркелкі жүктелуі және желіге шамадан тыс жүктелмеуі маңызды. Жағдайды елестетіп көрейік: пайдаланушы трафигі кіріс балансерлеріне түседі (haproxy, nginx және т. Қолданбаның инфрақұрылымында қажетті интерфейсті жүзеге асыратын қызмет тек соңғы миль болып табылады және бастапқы сұрауға жауап беру үшін бірқатар басқа қызметтерді сұрауы керек. Ішкі сұраулар сонымен қатар маршруттау мен теңгерімдеуді қажет етеді.
Деректер ағындарын тиімді басқару үшін хабар алмасу әзірлеушілерге маршруттауды және жүктемені теңестіруді басқару үшін интерфейсті қамтамасыз етуі керек. Осының арқасында әзірлеушілер микросервис үлгілерін (агрегатор, прокси, тізбек, тармақ және т.б.) пайдалана отырып, стандартты мәселелерді де, сирек кездесетін мәселелерді де шеше алады.
Бизнес тұрғысынан ауқымдылық тәуекелдерді басқару құралдарының бірі болып табылады. Ең бастысы - жабдықты оңтайлы пайдалану арқылы тұтынушылардың сұраныстарын қанағаттандыру:
- Прогресс нәтижесінде жабдықтың қуаты артқанда. Ол жетілмеген бағдарламалық жасақтамаға байланысты жұмыс істемейді. Erlang тігінен жақсы масштабталады және әрқашан барлық процессор өзектерін және қолжетімді жадты пайдалана алады;
- Бұлтты орталарда біз ағымдағы немесе болжанатын жүктемеге байланысты жабдықтың көлемін басқара аламыз және SLA кепілдік бере аламыз.
ақауларға төзімділік
Екі аксиоманы қарастырайық: «Сәтсіздіктерге жол берілмейді» және «Әрқашан сәтсіздіктер болады». Бизнес үшін бағдарламалық жасақтаманың істен шығуы ақшаны жоғалтуды білдіреді, ал одан да жаманы, беделді жоғалту. Ықтимал шығындар мен ақауларға төзімді бағдарламалық қамтамасыз етуді әзірлеу құны арасындағы теңгерімділік жиі ымыраға келуге болады.
Қысқа мерзімді перспективада ақауларға төзімділікті қамтитын архитектура кластерлік шешімдерді сатып алуға ақша үнемдейді. Олар қымбат және оларда қателер де бар.
Ұзақ мерзімді перспективада ақауларға төзімді архитектура дамудың барлық кезеңдерінде өзін бірнеше есе ақтайды.
Кодтық базаның ішіндегі хабар алмасу әзірлеу сатысында жүйе ішіндегі компоненттердің өзара әрекеттесуін егжей-тегжейлі пысықтауға мүмкіндік береді. Бұл сәтсіздіктерге жауап беру және басқару тапсырмасын жеңілдетеді, өйткені барлық маңызды құрамдас бөліктер сәтсіздіктерді өңдейді және нәтижесінде алынған жүйе ақаулықтан кейін дизайн бойынша автоматты түрде қалыпты жағдайға қалай оралу керектігін біледі.
Жауаптылық
Сәтсіздіктерге қарамастан, қолданба сұрауларға жауап беруі және SLA талаптарына сәйкес келуі керек. Шындығында, адамдар күтуді қаламайды, сондықтан бизнес соған сәйкес бейімделуі керек. Барған сайын көбірек қосымшалар жоғары жауап береді деп күтілуде.
Жауап беретін қолданбалар нақты уақыт режимінде жұмыс істейді. Erlang VM жұмсақ нақты уақыт режимінде жұмыс істейді. Биржа саудасы, медицина және өнеркәсіптік жабдықты бақылау сияқты кейбір салалар үшін нақты уақыт режимінің қиын режимі маңызды.
Жауапты жүйелер UX жақсартады және бизнеске пайда әкеледі.
Алдын ала қорытынды
Осы мақаланы жоспарлау кезінде мен хабарлама алмасу брокерін құру және оның негізінде күрделі жүйелерді құру тәжірибеммен бөліскім келді. Бірақ теориялық және мотивациялық бөлігі өте ауқымды болып шықты.
Мақаланың екінші бөлігінде мен алмасу нүктелерін енгізудің нюанстары, хабар алмасу үлгілері және оларды қолдану туралы айтатын боламын.
Үшінші бөлімде қызметтерді ұйымдастыру, маршруттау және теңгерімдеудің жалпы мәселелерін қарастырамыз. Жүйелердің ауқымдылығы мен ақауларға төзімділігінің практикалық жағы туралы сөйлесейік.
Бірінші бөлімнің соңы.
фото .
Ақпарат көзі: www.habr.com