Աշխարհը կանգ չի առնում. Առաջընթացը ստեղծում է նոր տեխնոլոգիական մարտահրավերներ: Փոփոխվող պահանջներին համապատասխան՝ տեղեկատվական համակարգերի ճարտարապետությունը պետք է զարգանա: Այսօր մենք կխոսենք իրադարձությունների վրա հիմնված ճարտարապետության, միաժամանակության, համաժամանակության, ասինխրոնության և այն մասին, թե ինչպես կարելի է այս ամենի հետ խաղաղ ապրել Էրլանգում:
Ներածություն
Կախված նախագծված համակարգի չափերից և դրան ներկայացվող պահանջներից՝ մենք՝ մշակողներս, ընտրում ենք համակարգում տեղեկատվության փոխանակման եղանակը։ Շատ դեպքերում, ծառայությունների փոխազդեցությունը կազմակերպելու համար, աշխատանքային տարբերակ կարող է լինել բրոքերի հետ սխեման, օրինակ՝ հիմնված RabbitMQ-ի կամ kafka-ի վրա: Բայց երբեմն իրադարձությունների հոսքը, SLA-ն և համակարգի նկատմամբ վերահսկողության մակարդակը այնպիսին են, որ պատրաստի հաղորդագրությունները մեզ հարմար չեն: Իհարկե, դուք կարող եք մի փոքր բարդացնել համակարգը՝ պատասխանատվություն ստանձնելով տրանսպորտային շերտի և կլաստերի ձևավորման համար, օրինակ՝ օգտագործելով ZeroMQ կամ nanomsg: Բայց եթե համակարգն ունի բավարար թողունակություն և ստանդարտ Erlang կլաստերի հնարավորություններ, ապա լրացուցիչ սուբյեկտի ներդրման հարցը պահանջում է մանրամասն ուսումնասիրություն և տնտեսական հիմնավորում:
Ռեակտիվ բաշխված հավելվածների թեման բավականին լայն է։ Հոդվածի ձևաչափի մեջ մնալու համար այսօրվա քննարկման առարկան կլինեն միայն Erlang/Elixir-ի վրա կառուցված միատարր միջավայրերը։ Erlang/OTP էկոհամակարգը թույլ է տալիս իրականացնել ռեակտիվ ճարտարապետություն՝ նվազագույն ջանքերով: Բայց ամեն դեպքում մեզ անհրաժեշտ կլինի հաղորդագրությունների շերտ:
Տեսական հիմք
Դիզայնը սկսվում է նպատակների և սահմանափակումների սահմանմամբ: Հիմնական նպատակը զարգացման ոլորտում չէ՝ հանուն զարգացման։ Մենք պետք է ստանանք ապահով և մասշտաբային գործիք, որի հիման վրա կարող ենք ստեղծել և, որ ամենակարևորը, զարգացնել տարբեր մակարդակների ժամանակակից հավելվածներ. սկսած փոքր լսարանին սպասարկող մեկ սերվերի հավելվածներից, որոնք հետագայում կարող են վերածվել մինչև 50 կլաստերների։ -60 հանգույց՝ վերջացող կլաստերային ֆեդերացիաներով։ Այսպիսով, հիմնական նպատակն է առավելագույնի հասցնել շահույթը՝ նվազեցնելով վերջնական համակարգի մշակման և սեփականության արժեքը:
Եկեք առանձնացնենք վերջնական համակարգի 4 հիմնական պահանջ.
- Сիրադարձություններին ուղղված.
Համակարգը միշտ պատրաստ է անցնել իրադարձությունների հոսքով և կատարել անհրաժեշտ գործողություններ. - Мմասշտաբայնություն.
Առանձին բլոկները կարող են չափվել ինչպես ուղղահայաց, այնպես էլ հորիզոնական: Ամբողջ համակարգը պետք է ունակ լինի անսահման հորիզոնական աճի. - Оսխալների հանդուրժողականություն:
Բոլոր մակարդակները և բոլոր ծառայությունները պետք է կարողանան ինքնաբերաբար վերականգնվել ձախողումներից. - Гերաշխավորված արձագանքման ժամանակ:
Ժամանակը արժեքավոր է, և օգտվողները չպետք է շատ երկար սպասեն:
Հիշո՞ւմ եք հին հեքիաթը «Փոքրիկ շարժիչը, որը կարող էր» մասին: Որպեսզի նախագծված համակարգը հաջողությամբ դուրս գա նախատիպի փուլից և լինի առաջադեմ, դրա հիմքը պետք է համապատասխանի նվազագույն պահանջներին. SMOG.
Հաղորդագրություններին որպես ենթակառուցվածքային գործիք և բոլոր ծառայությունների հիմք է ավելացվել ևս մեկ կետ. ծրագրավորողների համար օգտագործման հեշտությունը:
Իրադարձություններին ուղղված
Որպեսզի հավելվածը մեկ սերվերից վերածվի կլաստերի, դրա ճարտարապետությունը պետք է աջակցի չամրացված միացմանը: Ասինխրոն մոդելը համապատասխանում է այս պահանջին: Դրանում ուղարկողն ու ստացողը հոգ են տանում հաղորդագրության տեղեկատվական բեռի մասին և չեն անհանգստանում համակարգի ներսում փոխանցման և երթուղղման մասին:
Մասշտաբայնություն
Մասշտաբայնությունը և համակարգի արդյունավետությունը միմյանց կողքին են: Հավելվածի բաղադրիչները պետք է կարողանան օգտագործել բոլոր առկա ռեսուրսները: Որքան ավելի արդյունավետ օգտագործենք հզորությունը և որքան օպտիմալ լինեն մեր մշակման մեթոդները, այնքան քիչ գումար ենք ծախսում սարքավորումների վրա:
Մեկ մեքենայի շրջանակներում Erlang-ը ստեղծում է բարձր մրցակցային միջավայր: Միաժամանակության և զուգահեռության միջև հավասարակշռությունը կարող է սահմանվել՝ ընտրելով Erlang VM-ին հասանելի օպերացիոն համակարգի թելերի քանակը և այդ թելերն օգտագործող ժամանակացույցերի քանակը:
Erlang գործընթացները չեն կիսում վիճակը և գործում են չարգելափակման ռեժիմում: Սա ապահովում է համեմատաբար ցածր ուշացում և ավելի բարձր թողունակություն, քան ավանդական արգելափակման վրա հիմնված հավելվածները: Erlang-ի ժամանակացույցն ապահովում է CPU-ի և IO-ի արդար բաշխումը, իսկ արգելափակման բացակայությունը թույլ է տալիս հավելվածին արձագանքել նույնիսկ առավելագույն բեռների կամ խափանումների ժամանակ:
Կլաստերային մակարդակում առկա է նաև հեռացման խնդիր: Կարևոր է, որ կլաստերի բոլոր մեքենաները հավասարապես բեռնված լինեն, և ցանցը չծանրաբեռնվի: Եկեք պատկերացնենք իրավիճակ. Հավելվածի ենթակառուցվածքում պահանջվող ինտերֆեյսը իրականացնող ծառայությունը միայն վերջին մղոնն է և պետք է պահանջի մի շարք այլ ծառայություններ՝ սկզբնական հարցմանը պատասխանելու համար: Ներքին հարցումները պահանջում են նաև երթուղի և հավասարակշռում:
Տվյալների հոսքերը արդյունավետ կառավարելու համար հաղորդագրությունների փոխանակումը պետք է մշակողներին տրամադրի ինտերֆեյս՝ կառավարելու երթուղավորումը և բեռի հավասարակշռումը: Դրա շնորհիվ մշակողները կկարողանան օգտագործելով միկրոսերվիսային օրինաչափություններ (ագրեգատոր, պրոքսի, շղթա, ճյուղ և այլն), լուծել ինչպես ստանդարտ, այնպես էլ հազվադեպ առաջացող խնդիրները:
Բիզնեսի տեսանկյունից մասշտաբայնությունը ռիսկերի կառավարման գործիքներից մեկն է: Հիմնական բանը հաճախորդների խնդրանքները բավարարելն է` օպտիմալ կերպով օգտագործելով սարքավորումները.
- Երբ առաջընթացի արդյունքում սարքավորումների հզորությունը մեծանում է. Այն պարապ չի մնա անկատար ծրագրաշարի պատճառով։ Erlang-ը լավ չափվում է ուղղահայաց և միշտ կկարողանա օգտագործել պրոցեսորի բոլոր միջուկները և հասանելի հիշողությունը;
- Ամպային միջավայրում մենք կարող ենք կառավարել սարքավորումների քանակը՝ կախված ընթացիկ կամ կանխատեսվող բեռից և երաշխավորել SLA:
սխալների հանդուրժողականություն
Դիտարկենք երկու աքսիոմ՝ «Ձախողումներն անընդունելի են» և «Անհաջողություններ միշտ կլինեն»։ Բիզնեսի համար ծրագրային ապահովման ձախողումը նշանակում է փողի կորուստ, իսկ ավելի վատ՝ հեղինակության կորուստ: Հավասարակշռելով հնարավոր կորուստների և անսարքությունների հանդուրժող ծրագրակազմի մշակման ծախսերի միջև՝ հաճախ կարելի է փոխզիջում գտնել:
Կարճաժամկետ կտրվածքով, ճարտարապետությունը, որը ներառում է սխալների հանդուրժողականություն, խնայում է գումար՝ առանց դարակաշարերի խմբավորման լուծումներ գնելու համար: Նրանք թանկ են, և նրանք նույնպես ունեն սխալներ:
Երկարաժամկետ հեռանկարում, անսարքությունների հանդուրժող ճարտարապետությունը բազմապատիկ վճարում է իր համար զարգացման բոլոր փուլերում:
Հաղորդագրությունները կոդի բազայում թույլ են տալիս մանրամասնորեն մշակել համակարգի բաղադրիչների փոխազդեցությունը զարգացման փուլում: Սա հեշտացնում է խափանումներին արձագանքելու և կառավարելու առաջադրանքը, քանի որ բոլոր կարևոր բաղադրիչները լուծում են խափանումները, և արդյունքում ստացված համակարգը գիտի, թե ինչպես ինքնաբերաբար վերադառնալ նորմալ՝ նախագծով ձախողումից հետո:
Արձագանքողականություն
Անկախ ձախողումներից, հավելվածը պետք է պատասխանի հարցումներին և համապատասխանի SLA-ին: Իրականությունն այն է, որ մարդիկ չեն ցանկանում սպասել, ուստի ձեռնարկությունները պետք է համապատասխանաբար հարմարվեն: Ակնկալվում է, որ ավելի ու ավելի շատ հավելվածներ կլինեն բարձր արձագանքող:
Պատասխանատու հավելվածները գործում են գրեթե իրական ժամանակում: Erlang VM-ն աշխատում է իրական ժամանակի փափուկ ռեժիմով: Որոշ ոլորտների համար, ինչպիսիք են բաժնետոմսերի առևտուրը, բժշկությունը և արդյունաբերական սարքավորումների վերահսկումը, կարևոր է իրական ժամանակի դժվար ռեժիմը:
Պատասխանատու համակարգերը բարելավում են UX-ը և օգուտ տալիս բիզնեսին:
Նախնական ամփոփում
Այս հոդվածը պլանավորելիս ես ուզում էի կիսվել հաղորդագրությունների փոխանակման բրոքեր ստեղծելու և դրա հիման վրա բարդ համակարգեր ստեղծելու իմ փորձով: Բայց տեսական և մոտիվացիոն մասը բավականին ծավալուն է ստացվել։
Հոդվածի երկրորդ մասում կխոսեմ փոխանակման կետերի ներդրման նրբությունների, հաղորդագրությունների օրինաչափությունների և դրանց կիրառման մասին։
Երրորդ մասում մենք կդիտարկենք ծառայությունների կազմակերպման, երթուղիների և հավասարակշռման ընդհանուր խնդիրները: Եկեք խոսենք համակարգերի մասշտաբայնության և սխալների հանդուրժողականության գործնական կողմի մասին:
Առաջին մասի ավարտ.
լուսանկար .
Source: www.habr.com