Բարև, Հաբր: Այսօր ես շարունակում եմ հրապարակումների շարքը, որոնք գրել եմ հատուկ դասընթացի նոր հոսքի մեկնարկի համար: .
Ներածություն
Ճարտարապետական ոճի ընտրությունը տեղեկատվական համակարգ կառուցելիս հիմնարար տեխնիկական որոշումներից մեկն է: Հոդվածների այս շարքում ես առաջարկում եմ վերլուծել ամենահայտնի ճարտարապետական ոճերը շինարարական հավելվածների համար և պատասխանել այն հարցին, թե երբ է առավել նախընտրելի ճարտարապետական ոճը: Ներկայացման գործընթացում ես կփորձեմ գծել տրամաբանական շղթա, որը բացատրում է ճարտարապետական ոճերի զարգացումը մոնոլիտից մինչև միկրոսերվիսներ:
В մենք զբաղվեցինք մոնոլիտով և եկանք այն եզրակացության, որ մոնոլիտն ունի մի շարք խնդիրներ՝ չափ, կապ, տեղակայում, մասշտաբայնություն, հուսալիություն և կոշտություն:
Այս անգամ առաջարկում եմ խոսել համակարգի՝ որպես մոդուլների/գրադարանների (բաղադրիչների վրա հիմնված ճարտարապետություն) կամ ծառայությունների (ծառայության վրա հիմնված ճարտարապետություն) մի շարք կազմակերպելու հնարավորությունների մասին։
Բաղադրիչների վրա հիմնված ճարտարապետություն
Բաղադրիչների վրա հիմնված ճարտարապետությունը ներառում է համակարգի կատարումը որպես բաղադրիչների մի շարք, որոնք կարող են օգտագործվել ինչպես ընթացիկ, այնպես էլ ապագա նախագծերում: Համակարգը բաղադրիչների բաժանելիս հաշվի են առնվում հետևյալը. դրանց կրկնակի օգտագործման հնարավորությունը, փոխարինելիությունը, համատեքստի անկախությունը, ընդարձակելիությունը, պարփակումը և անկախությունը:
Բաղադրիչների պատշաճ օգտագործմամբ «կեղտի մեծ գնդակի» (մեծ չափս + բարձր զուգավորում) խնդիրը լուծվում է, և բաղադրիչներն իրենք կարող են լինել ինչպես հավաքման միավորներ (մոդուլներ, գրադարաններ), այնպես էլ տեղակայման միավորներ (ծառայություններ): Տեղակայման միավորները միշտ չէ, որ քարտեզագրվում են գործող գործընթացին. օրինակ, վեբ հավելվածը և տվյալների բազան տեղադրվում են միասին:
Ամենից հաճախ մոնոլիտները մշակվում են որպես մոդուլների մի շարք: Այս մոտեցումը հանգեցնում է անկախ զարգացման, բայց անկախ մասշտաբի և տեղակայման, սխալների հանդուրժողականության և ընդհանուր տեխնոլոգիական փաթեթից անկախության խնդիրները մնում են: Այդ իսկ պատճառով մոդուլը մասամբ անկախ բաղադրիչ է։
Նման մոնոլիտի ամենամեծ խնդիրն այն է, որ մոդուլների բաժանումը զուտ տրամաբանական է և հեշտությամբ կարող է խախտվել մշակողների կողմից: Կարող է հայտնվել առանցքային մոդուլ, որն աստիճանաբար վերածվում է աղբանոցի, մոդուլների միջև կախվածության գրաֆիկը կարող է մեծանալ և այլն։ Նման խնդիրներից խուսափելու համար մշակումը պետք է իրականացվի կա՛մ շատ հասուն թիմի կողմից, կա՛մ «ճարտարապետի» ղեկավարությամբ, ով զբաղվում է լրիվ դրույքով կոդերի վերանայմամբ և ծեծում է տրամաբանական կառուցվածքը խախտող մշակողների ձեռքը:
«Իդեալական» մոնոլիտը տրամաբանորեն առանձնացված մոդուլների մի շարք է, որոնցից յուրաքանչյուրը նայում է իր տվյալների բազայում:
Ծառայության վրա հիմնված ճարտարապետություն
Եթե ենթադրվում է, որ համակարգը կազմակերպված է ծառայությունների փաթեթի տեսքով, ապա խոսքը գնում է սպասարկման ուղղվածության ճարտարապետության մասին։ Դրա սկզբունքներն են՝ օգտատերերի վրա հիմնված հավելվածների փոխգործունակությունը, բիզնես ծառայության վերօգտագործումը, տեխնոլոգիական փաթեթի անկախությունը և ինքնավարությունը (անկախ էվոլյուցիա, մասշտաբայնություն և տեղակայում):
Ծառայության վրա հիմնված ճարտարապետությունը (SOA = սպասարկման կողմնորոշված ճարտարապետություն) լուծում է մոնոլիտի բոլոր բացահայտված խնդիրները. միայն մեկ ծառայության վրա է ազդում, երբ փոփոխություն է տեղի ունենում, և լավ սահմանված API-ն աջակցում է բաղադրիչների լավ ամփոփումը:
Բայց ամեն ինչ այնքան էլ հարթ չէ. SOA-ն նոր խնդիրներ է ստեղծում: Հեռակա զանգերն ավելի թանկ են, քան տեղականը, և բաղադրիչների միջև պարտականությունների վերաբաշխումը զգալիորեն թանկացել է:
Ի դեպ, ծառայության շատ կարևոր հատկանիշ է անկախ տեղակայման հնարավորությունը։ Եթե ծառայությունները պետք է տեղակայվեն միասին կամ, առավել եւս, որոշակի հաջորդականությամբ, ապա համակարգը չի կարող համարվել սպասարկման վրա հիմնված: Տվյալ դեպքում խոսում են բաշխված մոնոլիտի մասին (հակաօրինաչափ է համարվում ոչ միայն SOA-ի, այլ նաև միկրոսերվիսային ճարտարապետության տեսակետից)։
Ծառայությունների վրա հիմնված ճարտարապետությունը լավ աջակցվում է ճարտարապետական համայնքի և վաճառողների կողմից: Սա ենթադրում է բազմաթիվ դասընթացների և հավաստագրերի, լավ մշակված օրինաչափությունների առկայություն։ Վերջինս ներառում է, օրինակ, հայտնի ձեռնարկությունների սպասարկման ավտոբուսը (ESB = ձեռնարկության սպասարկման ավտոբուս): Միևնույն ժամանակ, ESB-ը վաճառողների ուղեբեռ է, այն պարտադիր չէ, որ օգտագործվի SOA-ում:
Ծառայությունների վրա հիմնված ճարտարապետության ժողովրդականությունը գագաթնակետին հասավ մոտ 2008 թվականին, որից հետո այն սկսեց նվազել, ինչը զգալիորեն ավելի դրամատիկ դարձավ միկրոծառայությունների հայտնվելուց հետո (~2015 թ.):
Ամփոփում
Այն բանից հետո, երբ մենք քննարկեցինք ծառայությունների և մոդուլների տեսքով տեղեկատվական համակարգերի կազմակերպման հնարավորությունները, ես առաջարկում եմ վերջապես անցնել միկրոսերվիսային ճարտարապետության սկզբունքներին և հաջորդ մասում հատուկ ուշադրություն դարձնել միկրոսերվիսային ճարտարապետության և սպասարկման վրա հիմնված ճարտարապետության տարբերությանը:
Source: www.habr.com