Բարև, հաբր. Դասընթացների նոր հոսքի գրանցումը բաց է հենց հիմա OTUS-ում . Դասընթացի մեկնարկի նախօրեին ուզում եմ ձեզ հետ կիսվել իմ բնօրինակ հոդվածով։
Ներածություն
Ճարտարապետական ոճի ընտրությունը տեղեկատվական համակարգ կառուցելիս հիմնարար տեխնիկական որոշումներից մեկն է: Հոդվածների այս շարքում ես առաջարկում եմ վերլուծել ամենահայտնի ճարտարապետական ոճերը շինարարական հավելվածների համար և պատասխանել այն հարցին, թե երբ է առավել նախընտրելի ճարտարապետական ոճը: Ներկայացման գործընթացում ես կփորձեմ գծել տրամաբանական շղթա, որը բացատրում է ճարտարապետական ոճերի զարգացումը մոնոլիտից մինչև միկրոսերվիսներ:
Մի քիչ պատմություն
Եթե փորձեք ծրագրավորողներին հարցնել. «Ինչու՞ են մեզ անհրաժեշտ միկրոծառայություններ», դուք կստանաք տարբեր պատասխաններ: Դուք կլսեք, որ միկրոսերվիսները բարելավում են մասշտաբայնությունը, կոդն ավելի հեշտ հասկանալի են դարձնում, կբարելավեն սխալների հանդուրժողականությունը, և երբեմն կլսեք, որ դրանք թույլ են տալիս «մաքրել ձեր կոդը»: Եկեք նայենք պատմությանը՝ հասկանալու համար, թե որն է միկրոծառայությունների առաջացման նպատակը:
Մի խոսքով, մեր ներկայիս պատկերացումներով միկրոծառայություններն առաջացել են հետևյալ կերպ. 2011 թվականին Ջեյմս Լյուիսը, վերլուծելով տարբեր ընկերությունների աշխատանքը, ուշադրություն հրավիրեց նոր «միկրո-հավելվածի» օրինաչափության առաջացման վրա, որն օպտիմիզացրեց SOA-ն՝ արագացնելու տեղակայումը: ծառայություններ։ Որոշ ժամանակ անց՝ 2012 թվականին, ճարտարապետական գագաթնաժողովում, նախշը վերանվանվեց միկրոսերվիս: Այսպիսով, միկրոծառայությունների ներդրման սկզբնական նպատակն էր բարելավել տխրահռչակները շուկա դուրս գալու ժամանակ.
2015 թվականին միկրոսերվիսները բուռն ալիքի վրա էին: Որոշ ուսումնասիրությունների համաձայն, ոչ մի գիտաժողով ամբողջական չի եղել առանց միկրոծառայությունների թեմայի վերաբերյալ զեկույցի: Ավելին, որոշ կոնֆերանսներ նվիրված էին բացառապես միկրոսերվիսներին։ Մեր օրերում շատ նախագծեր սկսում են օգտագործել այս ճարտարապետական ոճը, և եթե նախագիծը պարունակում է տոննա ժառանգական կոդ, ապա հավանաբար ակտիվորեն իրականացվում է միգրացիա դեպի միկրոսերվիսներ։
Չնայած վերը նշված բոլորին, բավականին փոքր թվով ծրագրավորողներ դեռ կարող են սահմանել «միկրոծառայություն» հասկացությունը: Բայց այս մասին կխոսենք մի փոքր ուշ...
Մոնոլիտ
Ճարտարապետական ոճը, որը հակադրում է միկրոսերվիսներին, մոնոլիտն է (կամ բոլորը մեկում): Հավանաբար, իմաստ չունի ասել, թե ինչ է մոնոլիտը, ուստի ես անմիջապես կթվարկեմ այս ճարտարապետական ոճի թերությունները, որոնք սկիզբ դրեցին ճարտարապետական ոճերի հետագա զարգացմանը. Ստորև առաջարկում եմ առանձին-առանձին դիտարկել թերություններից յուրաքանչյուրը։
չափ
Մոնոլիտը շատ մեծ է: Եվ այն սովորաբար շփվում է շատ մեծ տվյալների բազայի հետ: Հավելվածը դառնում է չափազանց մեծ, որպեսզի մեկ մշակողն ընդհանրապես չհասկանա: Միայն նրանք, ովքեր շատ ժամանակ են ծախսել այս կոդի վրա աշխատելու համար, կարող են լավ աշխատել մոնոլիտի հետ, մինչդեռ սկսնակները շատ ժամանակ կծախսեն՝ փորձելով պարզել մոնոլիտը, և երաշխիք չկա, որ նրանք կհասկանան այն: Սովորաբար, մոնոլիտով աշխատելիս միշտ կա ինչ-որ «պայմանական» ավագ, ով քիչ թե շատ լավ գիտի մոնոլիտը և մեկուկես տարվա ընթացքում ծեծում է այլ նոր ծրագրավորողների ձեռքը։ Բնականաբար, նման պայմանական ավագը ձախողման մեկ կետ է, և նրա հեռանալը կարող է հանգեցնել մոնոլիտի մահվան:
Կապակցվածություն
Մոնոլիտը «ցեխի մեծ գունդ» է, որի փոփոխությունները կարող են հանգեցնել անկանխատեսելի հետևանքների։ Մի տեղ փոփոխություններ անելով՝ կարող ես վնասել մոնոլիտը մյուսում (նույն «ականջդ քորեցիր, *@ ընկավ»): Դա պայմանավորված է նրանով, որ մոնոլիտի բաղադրիչներն ունեն շատ բարդ և, որ ամենակարեւորն է, ոչ ակնհայտ հարաբերություններ:
Տեղակայում
Մոնոլիտ տեղադրելը, նրա բաղադրիչների միջև բարդ հարաբերությունների պատճառով, երկար գործընթաց է՝ իր սեփական ծեսով: Նման ծեսը սովորաբար ամբողջովին ստանդարտացված չէ և փոխանցվում է «բանավոր»։
Մասշտաբայնություն
Մոնոլիտ մոդուլները կարող են ունենալ հակասական ռեսուրսների կարիքներ, որոնք պահանջում են փոխզիջում կատարել ապարատային առումով: Պատկերացրեք, որ դուք ունեք մի մոնոլիտ, որը բաղկացած է A և B ծառայություններից: A ծառայությունը պահանջում է կոշտ սկավառակի չափը, իսկ B ծառայությունը պահանջում է RAM-ի վրա: Այս դեպքում կամ մեքենան, որի վրա տեղադրված է մոնոլիտը, պետք է աջակցի երկու ծառայությունների պահանջներին, կամ դուք ստիպված կլինեք ձեռքով, արհեստականորեն անջատել ծառայություններից մեկը:
Մեկ այլ օրինակ (ավելի դասական). A ծառայությունը շատ ավելի տարածված է, քան ծառայությունը B, այնպես որ դուք ցանկանում եք, որ լինի 100 ծառայություն A և 10 ծառայություն B: Կրկին երկու տարբերակ. Բ ծառայությունները պետք է ձեռքով անջատվեն:
Հուսալիություն
Քանի որ բոլոր ծառայությունները գտնվում են միասին, եթե մոնոլիտը ընկնում է, ապա բոլոր ծառայությունները միանգամից ընկնում են: Իրականում, սա կարող է այդքան էլ վատ չլինել, համենայն դեպս բաշխված համակարգում մասնակի խափանումներ չեն լինի, բայց մյուս կողմից, ֆունկցիոնալ սխալի պատճառով, որն օգտագործվում է օգտատերերի 0.001%-ի կողմից, կարող եք կորցնել բոլոր օգտվողներին: ձեր համակարգի.
Իներցիա
Մոնոլիտի չափերի պատճառով դժվար է անցնել նոր տեխնոլոգիաների։ Արդյունքում, նույն ավագին պահելը առանձին խնդիր է։ Ծրագրի սկզբում ընտրված տեխնոլոգիական կույտը կարող է դառնալ բլոկ, որը խոչընդոտում է արտադրանքի զարգացմանը:
Ամփոփում
Հաջորդ անգամ մենք կխոսենք այն մասին, թե ինչպես են մարդիկ փորձել լուծել այս խնդիրները՝ անցնելով բաղադրիչներին և SOA-ին:
Կարդալ ավելին:
Source: www.habr.com