Միկրոծառայություններ. ինչ են դրանք, ինչու են դրանք և երբ դրանք իրականացնել

Ես երկար ժամանակ ուզում էի հոդված գրել միկրոսերվիսային ճարտարապետության թեմայով, բայց երկու բան ինձ խանգարում էր. Գիտելիքը պետք է ուսումնասիրվի և ուսումնասիրվի: Մյուս կողմից, կարծում եմ, որ լայն լսարանի շրջանում արդեն քննարկելու բան կա։ Այնպես որ այլընտրանքային կարծիքները ողջունելի են:

Conway-ի օրենքը և բիզնեսի, կազմակերպության և տեղեկատվական համակարգի հարաբերությունները

Եվս մեկ անգամ ինձ թույլ կտամ մեջբերել.

«Ցանկացած կազմակերպություն, որը նախագծում է համակարգ (լայն իմաստով), կստանա դիզայն, որի կառուցվածքը կրկնում է այդ կազմակերպության թիմերի կառուցվածքը»:
- Մելվին Քոնուեյ, 1967 թ

Իմ կարծիքով, այս օրենքն ավելի հավանական է, որ առնչվի բիզնեսի կազմակերպման իրագործելիությանը, այլ ոչ թե ուղղակիորեն տեղեկատվական համակարգին: Բացատրեմ օրինակով. Ենթադրենք, մենք ունենք բավականին կայուն բիզնես հնարավորություն այնպիսի երկարության կյանքի ցիկլով, որ իմաստ ունի կազմակերպել ձեռնարկություն (սա տառասխալ չէ, բայց ես շատ եմ սիրում այս տերմինը, որը ես գողացել եմ): Բնականաբար, այս բիզնեսի օժանդակ համակարգը կազմակերպչական և գործընթացային առումով կհամապատասխանի այս բիզնեսին:

Տեղեկատվական համակարգերի բիզնես կողմնորոշում

Բացատրեմ օրինակով. Ենթադրենք, կա պիցցա վաճառող բիզնես կազմակերպելու բիզնես հնարավորություն։ V1 տարբերակում (ասենք՝ նախնական տեղեկատվություն) ընկերությունը եղել է պիցցերիա, դրամարկղ, առաքման ծառայություն։ Այս տարբերակը երկարակյաց էր շրջակա միջավայրի ցածր փոփոխականության պայմաններում։ Այնուհետև նրան փոխարինեց 2-րդ տարբերակը՝ ավելի առաջադեմ և կարող է օգտագործել տեղեկատվական համակարգը իր հիմքում մոնոլիտ ճարտարապետությամբ բիզնեսի համար: Եվ այստեղ, իմ կարծիքով, ուղղակի սարսափելի անարդարություն կա մոնոլիտների նկատմամբ. իբր միաձույլ ճարտարապետությունը չի համապատասխանում տիրույթի բիզնես մոդելին. Այո, եթե այդպես լիներ, համակարգը ընդհանրապես չէր կարողանա աշխատել՝ հակասելով նույն Քոնուեյի օրենքին և ողջախոհությանը: Ոչ, մոնոլիտ ճարտարապետությունը լիովին համահունչ է բիզնեսի զարգացման այս փուլում բիզնես մոդելին. ես, իհարկե, նկատի ունեմ այն ​​փուլը, երբ համակարգը արդեն ստեղծվել և գործարկվել է: Բացարձակապես հրաշալի փաստ է, որ անկախ ճարտարապետական ​​մոտեցումից, և՛ սպասարկման վրա հիմնված ճարտարապետության 3-րդ տարբերակը, և՛ միկրոսերվիսների ճարտարապետության N տարբերակը հավասարապես լավ կաշխատեն։ Որն է բռնել:

Ամեն ինչ հոսում է, ամեն ինչ փոխվում է, թե՞ միկրոծառայությունները բարդության դեմ պայքարելու միջոց են:

Նախքան շարունակելը, եկեք նայենք միկրոսերվիսային ճարտարապետության վերաբերյալ որոշ սխալ պատկերացումներին:

Միկրոծառայությունների մոտեցման կողմնակիցները հաճախ պնդում են, որ մոնոլիտը միկրոծառայությունների բաժանումը հեշտացնում է զարգացման մոտեցումը՝ նվազեցնելով առանձին ծառայությունների կոդերի բազան: Իմ կարծիքով, այս հայտարարությունը կատարյալ անհեթեթություն է։ Լուրջ, մոնոլիտ և միատարր կոդի մեջ ակնհայտ փոխազդեցությունը բարդ է թվում: Եթե ​​դա իսկապես այդպես լիներ, ապա բոլոր նախագծերն ի սկզբանե կկառուցվեին որպես միկրոծառայություններ, մինչդեռ պրակտիկան ցույց է տալիս, որ միգրացիան մոնոլիտից միկրոծառայություններ շատ ավելի տարածված է: Բարդությունը չի վերանում, այն պարզապես տեղափոխվում է առանձին մոդուլներից դեպի ինտերֆեյսներ (լինի դա տվյալների ավտոբուսներ, RPC, API-ներ և այլ արձանագրություններ) և համակարգող համակարգեր: Եվ սա դժվար է!

Տարասեռ կույտի օգտագործման առավելությունը նույնպես կասկածելի է: Ես չեմ վիճարկի, որ դա նույնպես հնարավոր է, բայց իրականում դա հազվադեպ է պատահում (Նայելով առաջ, դա պետք է տեղի ունենա, բայց ավելի շուտ որպես հետևանք, քան առավելություն):

Ապրանքի կյանքի ցիկլը և ծառայության կյանքի ցիկլը

Եվս մեկ նայեք վերևի գծապատկերին: Պատահական չէ, որ ես նկատեցի բիզնեսի առանձին տարբերակի կյանքի ցիկլի նվազումը. ժամանակակից պայմաններում բիզնեսի տարբերակների միջև անցման արագացումն է որոշիչ նրա հաջողության համար։ Ապրանքի հաջողությունը որոշվում է նրանում բիզնես վարկածների փորձարկման արագությամբ. Եվ այստեղ, իմ կարծիքով, կայանում է միկրոսերվիսային ճարտարապետության հիմնական առավելությունը։ Բայց արի գնանք հերթականությամբ։

Անցնենք տեղեկատվական համակարգերի էվոլյուցիայի հաջորդ փուլին՝ SOA-ի սպասարկման վրա հիմնված ճարտարապետությանը: Այսպիսով, ինչ-որ պահի մենք ընդգծեցինք մեր արտադրանքի մեջ երկարատև ծառայություններ - երկարակյաց այն առումով, որ ապրանքի տարբերակների միջև տեղաշարժվելիս կա հնարավորություն, որ ծառայության կյանքի ցիկլը ավելի երկար լինի, քան արտադրանքի հաջորդ տարբերակի կյանքի ցիկլը: Տրամաբանական կլիներ դրանք ընդհանրապես չփոխել՝ մենք Կարևորը հաջորդ տարբերակին անցնելու արագությունն է. Բայց ավաղ, մենք ստիպված ենք անընդհատ փոփոխություններ կատարել ծառայությունների մեջ, և այստեղ ամեն ինչ աշխատում է մեզ համար, DevOps-ի պրակտիկա, կոնտեյներացում և այլն, այն ամենը, ինչ գալիս է մտքում: Բայց դրանք դեռ միկրոծառայություններ չեն:

Միկրոծառայությունները՝ որպես բարդության դեմ պայքարի միջոց... կոնֆիգուրացիայի կառավարում

Եվ այստեղ մենք վերջապես կարող ենք անցնել միկրոծառայությունների որոշիչ դերին. սա մոտեցում է, որը հեշտացնում է արտադրանքի կոնֆիգուրացիայի կառավարումը: Ավելի մանրամասն, յուրաքանչյուր միկրոծառայության գործառույթը ճշգրիտ նկարագրում է արտադրանքի ներսում բիզնես գործառույթը՝ ըստ տիրույթի մոդելի, և դրանք այն բաներն են, որոնք ապրում են ոչ թե կարճատև տարբերակով, այլ երկարակյաց բիզնես հնարավորությամբ: Եվ ապրանքի հաջորդ տարբերակին անցումը տեղի է ունենում բառացիորեն աննկատ. դու փոխում ես/ավելացնում ես մեկ միկրոսերվիս, և, հնարավոր է, միայն դրանց փոխազդեցության սխեման, և հանկարծ հայտնվում ես ապագայում՝ հետևում թողնելով լացող մրցակիցներին, ովքեր շարունակում են ցատկել տարբերակների միջև: նրանց մոնոլիտները. Հիմա պատկերացրեք, որ կա միկրոծառայությունների բավականին մեծ ծավալ՝ նախապես սահմանված ինտերֆեյսներով և բիզնես հնարավորություններով։ Եվ դուք գալիս եք և պատրաստի միկրոսերվիսներից կառուցում եք ձեր արտադրանքի կառուցվածքը, օրինակ՝ ուղղակի դիագրամ գծելով։ Շնորհավորում ենք, դուք հարթակ ունեք, և այժմ կարող եք բիզնես ներգրավել ձեզ համար: Երազներ Երազներ.

Արդյունքները

• Համակարգի ճարտարապետությունը պետք է որոշվի դրա բաղադրիչների կյանքի ցիկլով: Եթե ​​բաղադրիչը ապրում է արտադրանքի տարբերակում, ապա իմաստ չունի մեծացնել համակարգի բարդությունը՝ օգտագործելով միկրոսպասարկման մոտեցումը:
• Միկրոծառայությունների ճարտարապետությունը պետք է հիմնված լինի տիրույթի մոդելի վրա, քանի որ բիզնեսի հնարավորությունը ամենաերկարակյաց տիրույթն է
• Առաքման պրակտիկաները (DevOps-ի պրակտիկա) և նվագախումբն ամենակարևորներից են միկրոսերվիսային ճարտարապետության համար, քանի որ բաղադրիչների փոփոխության արագության աճը մեծացնում է առաքման արագության և որակի պահանջները:

Source: www.habr.com