Բարև, Հաբր: Այսօր ես շարունակում եմ հրապարակումների շարքը, որոնք գրել եմ հատուկ դասընթացի նոր հոսքի մեկնարկի համար: .
Ներածություն
Ճարտարապետական ոճի ընտրությունը տեղեկատվական համակարգ կառուցելիս հիմնարար տեխնիկական որոշումներից մեկն է: Հոդվածների այս շարքում ես առաջարկում եմ վերլուծել ամենահայտնի ճարտարապետական ոճերը շինարարական հավելվածների համար և պատասխանել այն հարցին, թե երբ է առավել նախընտրելի ճարտարապետական ոճը: Ներկայացման գործընթացում ես կփորձեմ գծել տրամաբանական շղթա, որը բացատրում է ճարտարապետական ոճերի զարգացումը մոնոլիտից մինչև միկրոսերվիսներ:
Անցյալ անգամ մենք խոսեցինք մոնոլիտների տարբեր տեսակների և դրանց կառուցման համար բաղադրիչների օգտագործման մասին, ինչպես կառուցման, այնպես էլ տեղակայման բաղադրիչների մասին: Մենք հասկանում ենք սպասարկման վրա հիմնված ճարտարապետություն:
Այժմ մենք վերջապես կսահմանենք միկրոսերվիսային ճարտարապետության հիմնական բնութագրերը:
Ճարտարապետությունների փոխհարաբերությունները
Պետք է հասկանալ, որ նախորդ հոդվածներում տրված սահմանումների հիման վրա ցանկացած ծառայություն բաղադրիչ է, բայց ամեն ծառայություն չէ, որ միկրոծառայություն է։
Microservice Architecture-ի բնութագրերը
Միկրոծառայությունների ճարտարապետության հիմնական բնութագրերն են.
- Կազմակերպված բիզնես հնարավորությունների շուրջ
- Ապրանքներ, ոչ նախագծեր
- Խելացի վերջնակետեր և համր խողովակներ
- Ապակենտրոնացված կառավարում
- Ապակենտրոնացված տվյալների կառավարում
- Ենթակառուցվածքների ավտոմատացում
- Դիզայն ձախողման համար
- Ճարտարապետություն էվոլյուցիոն զարգացմամբ (Էվոլյուցիոն դիզայն)
1-ին կետը գալիս է սպասարկման վրա հիմնված ճարտարապետությունից, քանի որ միկրոծառայությունները ծառայությունների հատուկ դեպք են: Մյուս կետերը արժանի են առանձին քննարկման:
Կազմակերպված բիզնես հնարավորությունների շուրջ
Այժմ անհրաժեշտ է հիշել Քոնուեյի օրենքը. համակարգեր ստեղծող կազմակերպությունները կազմակերպում են դրա ճարտարապետությունը՝ պատճենելով այդ կազմակերպությունների ներսում փոխգործակցության կառուցվածքը: Որպես օրինակ կարող ենք հիշել կոմպիլյատոր ստեղծելու դեպքը. յոթ հոգուց բաղկացած թիմը մշակել է յոթ անցանց կոմպիլյատոր, իսկ հինգ հոգուց բաղկացած թիմը՝ հինգ անցանցով կոմպիլյատոր:
Եթե մենք խոսում ենք մոնոլիտների և միկրոսերվիսների մասին, ապա եթե զարգացումը կազմակերպվում է ֆունկցիոնալ բաժինների կողմից (backend, frontend, տվյալների բազայի ադմինիստրատորներ), ապա մենք ստանում ենք դասական մոնոլիտ։
Միկրոծառայությունների ձեռքբերման համար թիմերը պետք է կազմակերպվեն բիզնեսի հնարավորություններով (պատվերներ, առաքումներ, կատալոգային թիմ): Այս կազմակերպությունը թիմերին թույլ կտա կենտրոնանալ հավելվածի կոնկրետ մասերի կառուցման վրա:
Ապրանքներ, ոչ նախագծեր
Ծրագրի մոտեցումը, որտեղ թիմը մշակված ֆունկցիոնալությունը փոխանցում է այլ թիմերի, լիովին անպիտան է միկրոսերվիսային ճարտարապետության դեպքում: Թիմը պետք է աջակցի համակարգին իր կյանքի ողջ ցիկլի ընթացքում: Միկրոծառայությունների ներդրման առաջատարներից մեկը՝ Amazon-ը, հայտարարել է. Արտադրանքի մոտեցումը թիմին թույլ է տալիս զգալ բիզնեսի կարիքները:
Խելացի վերջնակետեր և համր խողովակներ
SOA ճարտարապետությունը մեծ ուշադրություն է դարձրել կապի ուղիներին, մասնավորապես Enterprise Service Bus-ին: Ինչը հաճախ հանգեցնում է Սպագետի Սխալ տուփի, այսինքն՝ մոնոլիտի բարդությունը վերածվում է ծառայությունների միջև կապերի բարդության։ Microservice ճարտարապետությունը օգտագործում է միայն պարզ հաղորդակցման մեթոդներ:
Ապակենտրոնացված կառավարում
Միկրոծառայությունների վերաբերյալ հիմնական որոշումները պետք է կայացնեն այն մարդիկ, ովքեր իրականում զարգացնում են միկրոծառայությունները: Այստեղ առանցքային որոշումները նշանակում են ընտրություն
ծրագրավորման լեզուներ, տեղակայման մեթոդաբանություն, հանրային ինտերֆեյսի պայմանագրեր և այլն:
Ապակենտրոնացված տվյալների կառավարում
Ստանդարտ մոտեցումը, որտեղ հավելվածը հենվում է մեկ տվյալների բազայի վրա, չի կարող հաշվի առնել յուրաքանչյուր կոնկրետ ծառայության առանձնահատկությունները: MSA-ն ներառում է տվյալների ապակենտրոնացված կառավարում, ներառյալ տարբեր տեխնոլոգիաների օգտագործումը:
Ենթակառուցվածքների ավտոմատացում
MSA-ն աջակցում է շարունակական տեղակայման և առաքման գործընթացներին: Դրան կարելի է հասնել միայն գործընթացների ավտոմատացման միջոցով: Միևնույն ժամանակ, մեծ թվով ծառայությունների տեղակայումն այլևս սարսափելի բան չի թվում: Տեղակայման գործընթացը պետք է ձանձրալի դառնա: Երկրորդ ասպեկտը կապված է արտադրանքի միջավայրում ծառայությունների կառավարման հետ: Առանց ավտոմատացման, տարբեր գործառնական միջավայրերում գործող գործընթացների կառավարումն անհնար է դառնում:
Դիզայն ձախողման համար
MSA-ի բազմաթիվ ծառայություններ հակված են ձախողման: Միևնույն ժամանակ, բաշխված համակարգում սխալների կառավարումը չնչին խնդիր չէ: Հավելվածի ճարտարապետությունը պետք է դիմացկուն լինի նման խափանումների նկատմամբ: Ռեբեկա Փարսոնսը կարծում է, որ շատ կարևոր է, որ մենք այլևս չօգտագործենք ծառայությունների միջև ներընթացային հաղորդակցությունը, փոխարենը հաղորդակցության համար դիմում ենք HTTP-ին, որը գրեթե այդքան էլ հուսալի չէ:
Ճարտարապետություն էվոլյուցիոն զարգացմամբ (Էվոլյուցիոն դիզայն)
MSA համակարգի ճարտարապետությունը պետք է զարգանա էվոլյուցիոն ճանապարհով: Ցանկալի է սահմանափակել անհրաժեշտ փոփոխությունները մեկ ծառայության սահմաններով: Պետք է հաշվի առնել նաև այլ ծառայությունների վրա ազդեցությունը։ Ավանդական մոտեցումն է՝ փորձել լուծել այս խնդիրը տարբերակման միջոցով, սակայն MSA-ն առաջարկում է օգտագործել տարբերակում
որպես վերջին միջոց:
Ամփոփում
Վերոնշյալ բոլորից հետո մենք կարող ենք ձևակերպել, թե ինչ են միկրոծառայությունները: Microservice-ի ճարտարապետությունը մոտեցում է զարգացնելու մեկ հավելված՝ որպես փոքր ծառայությունների հավաքածու, որոնցից յուրաքանչյուրն աշխատում է իր սեփական գործընթացով և փոխազդում է թեթև մեխանիզմների միջոցով, հաճախ՝ HTTP ռեսուրսների API: Այս ծառայությունները կառուցված են բիզնեսի հնարավորությունների վրա և կարող են գործարկվել ինքնուրույն՝ ամբողջությամբ օգտագործելով
տեղակայման ավտոմատ մեխանիզմ: Այս ծառայությունների կենտրոնացված կառավարման նվազագույն մակարդակ կա, որը կարող է գրվել ծրագրավորման տարբեր լեզուներով և օգտագործել տվյալների պահպանման տարբեր տեխնոլոգիաներ:
Source: www.habr.com