Դուք ամիսներ եք ծախսել՝ վերափոխելով ձեր մոնոլիտը միկրոսերվիսների, և վերջապես բոլորը հավաքվել են անջատիչը շրջելու համար: Դուք գնում եք առաջին վեբ էջ... և ոչինչ չի լինում: Դուք վերաբեռնում եք այն, և նորից ոչ մի լավ բան չկա, կայքը այնքան դանդաղ է, որ մի քանի րոպե չի արձագանքում: Ինչ է պատահել?
Իր ելույթում Ջիմի Բոգարդը «հետմահու» կանցկացնի իրական միկրոծառայության աղետի վերաբերյալ: Նա ցույց կտա իր հայտնաբերած մոդելավորման, զարգացման և արտադրության խնդիրները, և թե ինչպես իր թիմը կամաց-կամաց փոխակերպեց նոր բաշխված մոնոլիտը ողջախոհության վերջնական պատկերի: Թեև անհնար է ամբողջությամբ կանխել նախագծման սխալները, դուք կարող եք գոնե նախագծման գործընթացի սկզբում բացահայտել խնդիրները, որպեսզի վերջնական արտադրանքը դառնա հուսալի բաշխված համակարգ:
Ողջույն բոլորին, ես Ջիմմին եմ, և այսօր դուք կլսեք, թե ինչպես կարող եք խուսափել մեգա աղետներից միկրոսերվիսներ կառուցելիս: Սա մի ընկերության պատմություն է, որտեղ ես աշխատել եմ մոտ մեկուկես տարի՝ օգնելու կանխել իրենց նավը այսբերգի բախումից: Այս պատմությունը ճիշտ պատմելու համար մենք պետք է հետ գնանք ժամանակը և խոսենք այն մասին, թե որտեղից է սկսել այս ընկերությունը և ինչպես է աճել նրա ՏՏ ենթակառուցվածքը ժամանակի ընթացքում: Այս աղետի ժամանակ անմեղների անունները պաշտպանելու համար ես փոխել եմ այս ընկերության անունը Bell Computers: Հաջորդ սլայդը ցույց է տալիս, թե ինչպիսի տեսք ուներ նման ընկերությունների ՏՏ ենթակառուցվածքը 90-ականների կեսերին։ Սա տիպիկ ճարտարապետություն է մեծ համընդհանուր անսարքությունների հանդուրժող HP Tandem Mainframe սերվերի` համակարգչային տեխնիկայի խանութը գործարկելու համար:
Նրանք պետք է կառուցեին համակարգ՝ կառավարելու բոլոր պատվերները, վաճառքը, վերադարձը, ապրանքների կատալոգները և հաճախորդների բազան, ուստի նրանք ընտրեցին այդ պահին ամենատարածված հիմնական լուծումը: Այս հսկա համակարգը պարունակում էր ընկերության մասին ամեն ինչ, հնարավոր ամեն ինչ, և յուրաքանչյուր գործարք իրականացվում էր այս հիմնական համակարգի միջոցով: Նրանք իրենց բոլոր ձվերը պահում էին մեկ զամբյուղի մեջ և կարծում էին, որ դա նորմալ է: Միակ բանը, որ այստեղ ներառված չէ, փոստով պատվերների կատալոգներն են և պատվերների կատարումը հեռախոսով:
Ժամանակի ընթացքում համակարգն ավելի ու ավելի մեծացավ, և այնտեղ կուտակվեց հսկայական աղբ: Բացի այդ, COBOL-ը աշխարհի ամենաարտահայտիչ լեզուն չէ, ուստի համակարգը ի վերջո դարձավ մեծ, միաձույլ աղբի կտոր: 2000 թվականին նրանք տեսան, որ շատ ընկերություններ ունեին վեբկայքեր, որոնց միջոցով նրանք իրականացնում էին բացարձակապես իրենց բիզնեսը, և որոշեցին ստեղծել իրենց առաջին առևտրային dot-com կայքը:
Նախնական դիզայնը բավականին գեղեցիկ տեսք ուներ և բաղկացած էր բարձր մակարդակի bell.com կայքից և առանձին հավելվածների համար մի շարք ենթադոմեյններից՝ catalog.bell.com, accounts.bell.com, orders.bell.com, արտադրանքի որոնում search.bell: com. Յուրաքանչյուր ենթադոմեյն օգտագործում էր ASP.Net 1.0 շրջանակը և իր սեփական տվյալների բազաները, և նրանք բոլորը խոսեցին համակարգի հետին մասի հետ: Այնուամենայնիվ, բոլոր պատվերները շարունակեցին մշակվել և իրականացվել մեկ հսկայական հիմնական համակարգում, որի մեջ մնաց ամբողջ աղբը, բայց ճակատային մասը առանձին վեբկայքեր էին՝ անհատական հավելվածներով և առանձին տվյալների բազաներով:
Այսպիսով, համակարգի դիզայնը կանոնավոր և տրամաբանական տեսք ուներ, բայց իրական համակարգը այնպիսին էր, ինչպիսին ցույց է տրված հաջորդ սլայդում:
Բոլոր տարրերը զանգեր էին ուղղում միմյանց, մուտք էին գործում API-ներ, ներկառուցված երրորդ կողմի dll-ներ և այլն: Հաճախ էր պատահում, որ տարբերակների կառավարման համակարգերը բռնում էին ուրիշի կոդը, խցկում այն նախագծի ներսում, և հետո ամեն ինչ կոտրվում էր: MS SQL Server 2005-ն օգտագործում էր կապի սերվերների հայեցակարգը, և չնայած ես սլայդի վրա չցուցադրեցի սլաքները, տվյալների բազաներից յուրաքանչյուրը նույնպես խոսեց միմյանց հետ, քանի որ սխալ բան չկա մի քանի տվյալների բազաներից ստացված տվյալների հիման վրա աղյուսակներ կառուցելու մեջ:
Քանի որ նրանք այժմ որոշակի տարանջատում ունեին համակարգի տարբեր տրամաբանական տարածքների միջև, դա դարձավ կեղտի բաշխված բծեր, ընդ որում ամենամեծ աղբը դեռևս մնում էր հիմնական համակարգում:
Զավեշտալին այն էր, որ այս mainframe-ը ստեղծվել էր Bell Computers-ի մրցակիցների կողմից և դեռ պահպանվում էր նրանց տեխնիկական խորհրդատուների կողմից: Համոզված լինելով իր հավելվածների անբավարար կատարման մեջ՝ ընկերությունը որոշել է ազատվել դրանցից և վերանախագծել համակարգը։
Գործող հավելվածը արտադրվում էր 15 տարի, ինչը ռեկորդային է ASP.Net-ի վրա հիմնված հավելվածների համար: Ծառայությունն ընդունում էր պատվերներ ամբողջ աշխարհից, և այս մեկ հավելվածից տարեկան եկամուտը հասնում էր միլիարդ դոլարի։ Շահույթի զգալի մասը ստացել է bell.com կայքը։ Սև ուրբաթ օրերին կայքի միջոցով կատարված պատվերների թիվը հասնում էր մի քանի միլիոնի։ Այնուամենայնիվ, գոյություն ունեցող ճարտարապետությունը թույլ չի տվել որևէ զարգացում, քանի որ համակարգի տարրերի կոշտ փոխկապակցումները գործնականում թույլ չեն տվել որևէ փոփոխություն կատարել ծառայության մեջ:
Ամենալուրջ խնդիրը մի երկրից պատվեր պատվիրելու, դրա դիմաց մյուս երկրում վճարելու և երրորդին ուղարկելու անհնարինությունն էր, չնայած այն հանգամանքին, որ նման առևտրային սխեման շատ տարածված է համաշխարհային ընկերություններում: Գոյություն ունեցող կայքը նման բան թույլ չէր տալիս, ուստի նրանք ստիպված էին ընդունել և կատարել այդ պատվերները հեռախոսով: Դա հանգեցրեց նրան, որ ընկերությունն ավելի ու ավելի է մտածում ճարտարապետությունը փոխելու, մասնավորապես միկրոծառայությունների անցնելու մասին:
Նրանք խելացի բան արեցին՝ նայելով այլ ընկերություններին, որպեսզի տեսնեն, թե ինչպես են նրանք լուծել նմանատիպ խնդիր: Այս լուծումներից մեկը Netflix ծառայության ճարտարապետությունն էր, որը բաղկացած է API-ի և արտաքին տվյալների բազայի միջոցով միացված միկրոծառայություններից:
Bell Computers-ի ղեկավարությունը որոշել է կառուցել հենց այդպիսի ճարտարապետություն՝ հավատարիմ մնալով որոշակի հիմնական սկզբունքներին: Նախ, նրանք վերացրել են տվյալների կրկնօրինակումը` օգտագործելով տվյալների բազայի ընդհանուր մոտեցումը: Տվյալներ չեն ուղարկվել, ընդհակառակը, բոլոր նրանց, ովքեր դրա կարիքն ուներ, պետք է դիմեին կենտրոնացված աղբյուրին։ Դրան հաջորդեց մեկուսացումը և ինքնավարությունը. յուրաքանչյուր ծառայություն անկախ էր մյուսներից: Նրանք որոշեցին օգտագործել Web API-ն բացարձակապես ամեն ինչի համար. եթե ցանկանում էիք տվյալներ ստանալ կամ փոփոխություններ կատարել մեկ այլ համակարգում, այդ ամենը արվում էր Web API-ի միջոցով: Վերջին մեծ բանը նոր հիմնական սարքն էր, որը կոչվում էր «Bell on Bell»՝ ի տարբերություն «Bell» հիմնական սարքի, որը հիմնված է մրցակիցների սարքավորման վրա:
Այսպիսով, 18 ամսվա ընթացքում նրանք համակարգը կառուցեցին այս հիմնական սկզբունքների շուրջ և հասցրին այն նախնական արտադրության: Հանգստյան օրերից հետո վերադառնալով աշխատանքի՝ մշակողները հավաքվել են և միացրել բոլոր սերվերները, որոնց միացված է նոր համակարգը։ 18 ամիս աշխատանք, հարյուրավոր ծրագրավորողներ, ամենաարդիական Bell սարքավորումը, և ոչ մի դրական արդյունք: Սա հիասթափեցրել է շատ մարդկանց, քանի որ նրանք բազմիցս գործարկել են այս համակարգը իրենց նոութբուքերի վրա, և ամեն ինչ լավ էր:
Նրանք խելացի էին, որ իրենց ամբողջ գումարը գցեցին այս խնդրի լուծման վրա։ Նրանք տեղադրեցին ամենաժամանակակից սերվերի դարակաշարերը անջատիչներով, օգտագործեցին գիգաբիթ օպտիկական մանրաթել, ամենահզոր սերվերի սարքավորումը խելագար քանակությամբ RAM-ով, միացրին այդ ամենը, կազմաձևեցին այն, և նորից ոչինչ: Այնուհետև նրանք սկսեցին կասկածել, որ պատճառը կարող է լինել ժամանակի դադարները, այնպես որ նրանք մտան բոլոր վեբ կարգավորումները, բոլոր API-ի կարգավորումները և թարմացրին ամբողջ ժամանակի ավարտի կոնֆիգուրացիան առավելագույն արժեքների, այնպես որ նրանք կարող էին միայն նստել և սպասել, որ ինչ-որ բան տեղի ունենա: դեպի կայք։ Նրանք սպասեցին և սպասեցին և սպասեցին 9 ու կես րոպե, մինչև կայքը վերջապես բեռնվի:
Դրանից հետո նրանց գլխի ընկավ, որ ստեղծված իրավիճակը մանրակրկիտ վերլուծության կարիք ունի, և նրանք մեզ հրավիրեցին։ Առաջին բանը, որ մենք պարզեցինք, այն էր, որ զարգացման բոլոր 18 ամիսների ընթացքում ոչ մի իրական «միկրո» չի ստեղծվել. ամեն ինչ միայն ավելի մեծացավ: Դրանից հետո մենք սկսեցինք գրել հետմահու, որը նաև հայտնի է որպես «հետադարձ հայացք», կամ «տխուր հետահայաց», որը նաև հայտնի է որպես «մեղադրական փոթորիկ», որը նման է «ուղեղային փոթորկին», որպեսզի հասկանանք աղետի պատճառը:
Մենք ունեինք մի քանի հուշումներ, որոնցից մեկը երթևեկության ամբողջական հագեցվածությունն էր API-ի կանչի պահին: Երբ դուք օգտագործում եք մոնոլիտ ծառայության ճարտարապետություն, դուք կարող եք անմիջապես հասկանալ, թե կոնկրետ ինչն է սխալվել, քանի որ դուք ունեք մեկ կույտի հետք, որը հայտնում է այն ամենը, ինչ կարող էր առաջացնել ձախողումը: Այն դեպքում, երբ մի շարք ծառայություններ միաժամանակ մուտք են գործում նույն API-ին, հետքը հետևելու ոչ մի միջոց չկա, բացի WireShark-ի նման ցանցի մոնիտորինգի լրացուցիչ գործիքներից, որոնց շնորհիվ կարող եք ուսումնասիրել մեկ հարցում և պարզել, թե ինչ է տեղի ունեցել դրա իրականացման ընթացքում: Այսպիսով, մենք վերցրեցինք մեկ վեբ էջ և ծախսեցինք գրեթե 2 շաբաթ՝ հավաքելով գլուխկոտրուկի կտորները, տարբեր զանգեր կատարելով դրան և վերլուծելով, թե դրանցից յուրաքանչյուրը ինչի է հանգեցրել:
Նայեք այս նկարին. Այն ցույց է տալիս, որ մեկ արտաքին հարցումը ծառայությանը հուշում է կատարել բազմաթիվ ներքին զանգեր, որոնք վերադառնում են: Ստացվում է, որ յուրաքանչյուր ներքին զանգ կատարում է հավելյալ ցատկ, որպեսզի կարողանա ինքնուրույն սպասարկել այս հարցումը, քանի որ այն չի կարող այլ տեղ դիմել՝ անհրաժեշտ տեղեկատվություն ստանալու համար։ Այս նկարը կարծես զանգերի անիմաստ կասկադ լինի, քանի որ արտաքին հարցումը կանչում է լրացուցիչ ծառայություններ, որոնք կանչում են այլ լրացուցիչ ծառայություններ և այլն, գրեթե անվերջ:
Այս գծապատկերի կանաչ գույնը ցույց է տալիս կիսաշրջան, որում ծառայությունները զանգահարում են միմյանց՝ A ծառայությունը զանգահարում է B ծառայությունը, B ծառայությունը զանգահարում է ծառայություն C, և այն կրկին կանչում է ծառայություն A: Արդյունքում մենք ստանում ենք «բաշխված փակուղի»: Մեկ հարցումը ստեղծեց ցանցի հազար API զանգ, և քանի որ համակարգը չուներ ներկառուցված սխալների հանդուրժողականություն և հանգույցի պաշտպանություն, հարցումը կձախողվի, եթե այս API զանգերից նույնիսկ մեկը ձախողվեր:
Մենք որոշ մաթեմատիկա արեցինք: Յուրաքանչյուր API զանգ ուներ SLA ոչ ավելի, քան 150 ms և 99,9% գործարկման ժամանակ: Մեկ հարցումն առաջացրել է 200 տարբեր զանգեր, և լավագույն դեպքում էջը կարող էր ցուցադրվել 200 x 150 ms = 30 վայրկյանում: Բնականաբար, սա լավ չէր: 99,9-ով բազմապատկելով 200%-ը, մենք ստացանք 0% հասանելիություն: Պարզվում է՝ այս ճարտարապետությունն ի սկզբանե դատապարտված էր ձախողման։
Մենք ծրագրավորողներից հետաքրքրվեցինք, թե 18 ամիս աշխատելուց հետո ինչպե՞ս չճանաչեցին այս խնդիրը: Պարզվեց, որ նրանք հաշվում էին միայն SLA-ն իրենց գործարկած կոդի համար, բայց եթե իրենց ծառայությունը զանգահարում էր այլ ծառայություն, նրանք այդ ժամանակը չէին հաշվում իրենց SLA-ում: Այն ամենը, ինչ գործարկվել է մեկ գործընթացի ընթացքում, հավատարիմ է եղել 150 ms արժեքին, սակայն սպասարկման այլ գործընթացների հասանելիությունը բազմապատիկ ավելացրել է ընդհանուր ուշացումը: Առաջին դասը, որ քաղվեց, հետևյալն էր. «Դուք վերահսկո՞ւմ եք ձեր SLA-ն, թե՞ SLA-ն է վերահսկում ձեզ»: Մեր դեպքում դա վերջինն էր։
Հաջորդ բանը, որ մենք հայտնաբերեցինք, այն էր, որ նրանք գիտեին Փիթեր Դեյչի և Ջեյմս Գոսլինգի կողմից ձևակերպված բաշխված հաշվողական սխալ պատկերացումների մասին, բայց նրանք անտեսեցին դրա առաջին մասը: Այն նշում է, որ «ցանցը հուսալի է», «զրոյական ուշացում» և «անսահման թողունակություն» հայտարարությունները թյուր պատկերացումներ են: Այլ սխալ պատկերացումները ներառում են «ցանցն ապահով է», «տոպոլոգիան երբեք չի փոխվում», «միշտ կա միայն մեկ ադմինիստրատոր», «տվյալների փոխանցման արժեքը զրոյական է» և «ցանցը միատարր է» արտահայտությունները։
Նրանք սխալ են թույլ տվել, քանի որ իրենց ծառայությունը փորձարկել են տեղական մեքենաների վրա և երբեք չեն կապվել արտաքին ծառայությունների հետ: Լոկալ մշակելիս և տեղական քեշ օգտագործելիս նրանք երբեք չեն հանդիպել ցանցի հոփեր: Զարգացման բոլոր 18 ամիսների ընթացքում նրանք երբեք չեն մտածել, թե ինչ կարող է տեղի ունենալ, եթե արտաքին ծառայությունները ազդեն:
Եթե նայեք նախորդ նկարում նշված ծառայության սահմաններին, ապա կարող եք տեսնել, որ դրանք բոլորը սխալ են: Կան բազմաթիվ աղբյուրներ, որոնք խորհուրդ են տալիս, թե ինչպես սահմանել ծառայության սահմանները, և շատերը դա անում են սխալ, ինչպես Microsoft-ը հաջորդ սլայդում:
Այս նկարը MS բլոգից է «Ինչպես կառուցել միկրոսերվիսներ» թեմայով: Սա ցույց է տալիս պարզ վեբ հավելված, բիզնես տրամաբանության բլոկ և տվյալների բազա: Հարցումը գալիս է ուղղակիորեն, հավանաբար կա մեկ սերվեր վեբի համար, մեկ սերվեր բիզնեսի համար և մեկը տվյալների բազայի համար: Եթե ավելացնեք տրաֆիկը, պատկերը մի փոքր կփոխվի։
Այստեղ գալիս է բեռի հավասարակշռիչ՝ երկու վեբ սերվերների միջև տրաֆիկը բաշխելու համար, քեշ, որը գտնվում է վեբ ծառայության և բիզնես տրամաբանության միջև, և մեկ այլ քեշ՝ բիզնես տրամաբանության և տվյալների բազայի միջև: Սա հենց այն ճարտարապետությունն է, որն օգտագործվում էր 2000-ականների կեսերին իր բեռի հավասարակշռման և կապույտ/կանաչ տեղակայման համար: Մինչև որոշ ժամանակ ամեն ինչ լավ էր աշխատում, քանի որ այս սխեման նախատեսված էր մոնոլիտ կառուցվածքի համար։
Հետևյալ նկարը ցույց է տալիս, թե ինչպես է MS-ը խորհուրդ տալիս մոնոլիտից անցնել միկրոսերվիսներին՝ պարզապես հիմնական ծառայություններից յուրաքանչյուրը բաժանել առանձին միկրոծառայությունների: Հենց այս սխեմայի իրականացման ժամանակ Բելը սխալվեց.
Նրանք իրենց բոլոր ծառայությունները բաժանեցին տարբեր մակարդակների, որոնցից յուրաքանչյուրը բաղկացած էր բազմաթիվ անհատական ծառայություններից: Օրինակ, վեբ ծառայությունը ներառում էր բովանդակության մատուցման և վավերացման միկրոծառայություններ, բիզնես տրամաբանության ծառայությունը բաղկացած էր պատվերների և հաշվի տեղեկատվության մշակման միկրոծառայություններից, տվյալների բազան բաժանված էր մի շարք միկրոծառայությունների` մասնագիտացված տվյալներով: Ե՛վ համացանցը, և՛ բիզնես տրամաբանությունը, և՛ տվյալների բազան քաղաքացիություն չունեցող ծառայություններ էին:
Այնուամենայնիվ, այս պատկերը լիովին սխալ էր, քանի որ այն չի քարտեզագրել ընկերության ՏՏ կլաստերից դուրս որևէ բիզնես միավոր: Այս սխեման հաշվի չի առել որևէ կապ արտաքին աշխարհի հետ, ուստի պարզ չէր, թե ինչպես, օրինակ, երրորդ կողմի բիզնեսի վերլուծություն ստանալ: Ես նշում եմ, որ նրանք նաև ունեին մի քանի ծառայություններ, որոնք հորինված էին պարզապես առանձին աշխատողների կարիերան զարգացնելու համար, ովքեր ձգտում էին հնարավորինս շատ մարդկանց կառավարել՝ դրա համար ավելի շատ գումար ստանալու համար:
Նրանք կարծում էին, որ միկրոծառայություններ տեղափոխվելը նույնքան հեշտ էր, որքան իրենց ներքին N- մակարդակի ֆիզիկական շերտի ենթակառուցվածքը վերցնելը և Docker-ը կպցնելը դրա վրա: Եկեք նայենք, թե ինչ տեսք ունի N- մակարդակի ավանդական ճարտարապետությունը:
Այն բաղկացած է 4 մակարդակից՝ UI ինտերֆեյսի մակարդակ, բիզնես տրամաբանության մակարդակ, տվյալների հասանելիության մակարդակ և տվյալների բազա: Ավելի առաջադեմ է DDD-ն (Domain-Driven Design) կամ ծրագրային ուղղվածության ճարտարապետությունը, որտեղ երկու միջին մակարդակները տիրույթի օբյեկտներն են և պահեստը:
Ես փորձեցի այս ճարտարապետության մեջ դիտարկել փոփոխությունների տարբեր ոլորտներ, պատասխանատվության տարբեր ոլորտներ: Տիպիկ N- մակարդակի կիրառման մեջ դասակարգվում են փոփոխության տարբեր ոլորտներ, որոնք ներթափանցում են կառուցվածքը ուղղահայաց վերևից ներքև: Սրանք Catalog, Config կարգավորումներն են, որոնք կատարվել են առանձին համակարգիչների վրա և Checkout-ի ստուգումները, որոնք մշակվել են իմ թիմի կողմից:
Այս սխեմայի առանձնահատկությունն այն է, որ փոփոխության այս ոլորտների սահմաններն ազդում են ոչ միայն բիզնեսի տրամաբանության մակարդակի վրա, այլև տարածվում են տվյալների բազայի վրա:
Եկեք տեսնենք, թե ինչ է նշանակում լինել ծառայություն: Ծառայության սահմանման 6 բնորոշ հատկություն կա՝ դա ծրագրակազմ է, որը.
- ստեղծվել և օգտագործվել է որոշակի կազմակերպության կողմից.
- պատասխանատու է համակարգի ներսում որոշակի տեսակի տեղեկատվության բովանդակության, մշակման և/կամ տրամադրման համար.
- կարող է կառուցվել, տեղակայվել և գործել ինքնուրույն՝ հատուկ գործառնական կարիքները բավարարելու համար.
- շփվում է սպառողների և այլ ծառայությունների հետ՝ տրամադրելով տեղեկատվություն համաձայնագրերի կամ պայմանագրային երաշխիքների հիման վրա.
- պաշտպանում է իրեն չարտոնված մուտքից, իսկ իր տեղեկատվությունը կորստից.
- վերաբերվում է ձախողումներին այնպես, որ դրանք չհանգեցնեն տեղեկատվության վնասի:
Այս բոլոր հատկությունները կարելի է արտահայտել մեկ բառով «ինքնավարություն»: Ծառայությունները գործում են միմյանցից անկախ, բավարարում են որոշակի սահմանափակումներ և սահմանում են պայմանագրեր, որոնց հիման վրա մարդիկ կարող են ստանալ իրենց անհրաժեշտ տեղեկատվությունը: Ես չնշեցի կոնկրետ տեխնոլոգիաներ, որոնց կիրառումն ինքնին հասկանալի է։
Հիմա եկեք նայենք միկրոծառայությունների սահմանմանը.
- միկրոսերվիսը փոքր չափի է և նախատեսված է մեկ կոնկրետ խնդիր լուծելու համար.
- Միկրոծառայությունն ինքնավար է.
- Միկրոսերվիսային ճարտարապետություն ստեղծելիս օգտագործվում է քաղաքաշինության փոխաբերությունը: Սա Սեմ Նյումանի «Building Microservices» գրքի սահմանումն է:
Սահմանափակ համատեքստի սահմանումը վերցված է Էրիկ Էվանսի Domain-Driven Design գրքից: Սա DDD-ի հիմնական օրինակն է՝ ճարտարապետության նախագծման կենտրոնում, որն աշխատում է ծավալային ճարտարապետական մոդելների հետ՝ դրանք բաժանելով տարբեր Սահմանափակ համատեքստերի և բացահայտորեն սահմանելով նրանց միջև փոխազդեցությունները:
Պարզ ասած, Bounded Context-ը նշանակում է այն շրջանակը, որում կարող է օգտագործվել որոշակի մոդուլ: Այս համատեքստում կա տրամաբանորեն միասնական մոդել, որը կարելի է տեսնել, օրինակ, ձեր բիզնեսի տիրույթում: Եթե պատվերների մեջ ներգրավված անձնակազմին հարցնեք «ով է հաճախորդը», դուք կստանաք մեկ սահմանում, եթե հարցնեք վաճառքով զբաղվողներին, կստանաք մեկ այլ, իսկ կատարողները ձեզ կտան երրորդ սահմանումը:
Այսպիսով, Bounded Context-ը ասում է, որ եթե մենք չենք կարող հստակ սահմանում տալ, թե որն է մեր ծառայությունների սպառողը, եկեք սահմանենք այն սահմանները, որոնցում կարող ենք խոսել այս տերմինի իմաստի մասին, և այնուհետև սահմանենք անցումային կետերը այս տարբեր սահմանումների միջև: Այսինքն՝ եթե մենք խոսում ենք պատվիրատուի մասին պատվերներ տեղադրելու տեսակետից, սա նշանակում է այս ու այն, իսկ եթե վաճառքի տեսանկյունից՝ սա նշանակում է այս ու այն։
Միկրոծառայության հաջորդ սահմանումը ցանկացած տեսակի ներքին գործառնությունների պարկուճն է, որը կանխում է աշխատանքային գործընթացի բաղադրիչների «արտահոսքը» շրջակա միջավայր: Հաջորդը գալիս է «արտաքին փոխազդեցությունների կամ արտաքին հաղորդակցության բացահայտ պայմանագրերի սահմանումը», որը ներկայացված է SLA-ներից վերադարձվող պայմանագրերի գաղափարով: Վերջին սահմանումը բջջի կամ բջջի փոխաբերությունն է, որը նշանակում է միկրոծառայության շրջանակներում մի շարք գործողությունների ամբողջական ընդգրկում և դրանում արտաքին աշխարհի հետ հաղորդակցման համար ընկալիչների առկայություն:
Այսպիսով, մենք ասացինք Bell Computers-ի տղաներին. «Մենք չենք կարող շտկել ձեր ստեղծած քաոսից որևէ մեկը, քանի որ դուք պարզապես գումար չունեք դա անելու համար, բայց մենք կուղղենք միայն մեկ ծառայություն, որպեսզի այդ ամենը դառնա: իմաստ»։ Այս պահին ես կսկսեմ ձեզ ասելով, թե ինչպես մենք շտկեցինք մեր միակ ծառայությունն այնպես, որ այն պատասխանի հարցումներին ավելի արագ, քան 9 ու կես րոպե:
22:30 րոպե
Շարունակությունը շատ շուտով...
Մի փոքր գովազդ
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com