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