Հասկանալով հաղորդագրության բրոքերներին: Սովորում ենք հաղորդագրությունների փոխանակման մեխանիզմը ActiveMQ-ի և Kafka-ի հետ: Գլուխ 1

Hello everyone!

Սկսել է թարգմանել մի փոքրիկ գիրք.
«Հասկանալով հաղորդագրությունների բրոքերներին",
հեղինակ՝ Յակուբ Քորաբ, հրատարակիչ՝ O'Reilly Media, Inc., Հրատարակման ամսաթիվ՝ հունիս 2017, ISBN՝ 9781492049296։

Գրքի ներածությունից.
"... Այս գիրքը կսովորեցնի ձեզ, թե ինչպես մտածել միջնորդավորված հաղորդագրությունների համակարգերի մասին՝ համեմատելով և հակադրելով երկու հայտնի բրոքերային տեխնոլոգիաները՝ Apache ActiveMQ և Apache Kafka: Այն կուրվագծի օգտագործման դեպքերը և զարգացման խթանները, որոնք ստիպել են իրենց ծրագրավորողներին խիստ տարբեր մոտեցումներ ցուցաբերել համակարգերի միջև միջնորդավորված հաղորդագրությունների նույն ոլորտի նկատմամբ: Մենք կանդրադառնանք այս տեխնոլոգիաներին ի սկզբանե և կնշենք դիզայնի տարբեր ընտրությունների ազդեցությունը ճանապարհին: Դուք ձեռք կբերեք խորը պատկերացում երկու ապրանքների մասին, կհասկանաք, թե ինչպես դրանք պետք է և ինչպես չպետք է օգտագործվեն, ինչպես նաև կհասկանաք, թե ինչի վրա պետք է ուշադրություն դարձնել ապագայում հաղորդագրությունների փոխանակման այլ տեխնոլոգիաներ դիտարկելիս: … »

Մինչ այժմ թարգմանված մասեր.
Գլուխ 1 Ներածություն
Գլուխ 3. Կաֆկա

Ավարտված գլուխները կտեղադրեմ այնպես, ինչպես թարգմանված են:

ԳԼՈՒԽ 1

Ներածություն

Միջհամակարգային հաղորդագրությունների փոխանակումը ՏՏ ամենաքիչ հասկացված ոլորտներից մեկն է: Որպես մշակող կամ ճարտարապետ, դուք կարող եք շատ ծանոթ լինել տարբեր շրջանակների և տվյալների բազաների: Այնուամենայնիվ, հավանական է, որ դուք միայն մի հայացք ունեք, թե ինչպես են աշխատում բրոքերների վրա հիմնված հաղորդագրությունների տեխնոլոգիաները: Եթե ​​դուք այդպես եք զգում, մի անհանգստացեք, դուք լավ ընկերությունում եք:

Մարդիկ սովորաբար շատ սահմանափակ կապ ունեն հաղորդագրությունների ենթակառուցվածքի հետ: Հաճախ նրանք միանում են վաղուց ստեղծված համակարգին, կամ ինտերնետից ներբեռնում են բաշխիչ փաթեթ, տեղադրում այն ​​PROM-ում և սկսում դրա համար կոդ գրել։ ՊՐՈՄ-ում ենթակառուցվածքը գործարկելուց հետո արդյունքները կարող են խառնվել. հաղորդագրությունները կորչում են խափանումների ժամանակ, ուղարկումները չեն աշխատում այնպես, ինչպես դուք ակնկալում եք, կամ բրոքերները կախում են ձեր արտադրողներին կամ հաղորդագրություններ չեն ուղարկում ձեր սպառողներին:

Լա՞վ ծանոթ:

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

Առանց բրոքերների աշխատանքի խորը ըմբռնման՝ մարդիկ թվացյալ ողջամիտ պնդումներ են անում իրենց հաղորդագրությունների համակարգերի վերաբերյալ, ինչպիսիք են՝

• Համակարգը երբեք չի կորցնի հաղորդագրությունները
• Հաղորդագրությունները կմշակվեն հաջորդաբար
• Սպառողների ավելացումը համակարգը կդարձնի ավելի արագ
• Հաղորդագրությունները կառաքվեն միայն մեկ անգամ

Ցավոք սրտի, այս հայտարարություններից մի քանիսը հիմնված են ենթադրությունների վրա, որոնք կիրառվում են միայն որոշակի հանգամանքներում, մինչդեռ մյուսները պարզապես չեն համապատասխանում իրականությանը:

Այս գիրքը կսովորեցնի ձեզ, թե ինչպես տրամաբանել միջնորդավորված հաղորդագրությունների համակարգերի մասին՝ համեմատելով և հակադրելով երկու հայտնի բրոքերային տեխնոլոգիաները՝ Apache ActiveMQ և Apache Kafka: Այն կուրվագծի օգտագործման դեպքերը և զարգացման խթանները, որոնք ստիպել են իրենց ծրագրավորողներին շատ տարբեր մոտեցումներ ցուցաբերել համակարգերի միջև միջնորդավորված հաղորդագրությունների նույն ոլորտի նկատմամբ: Մենք ի սկզբանե կանդրադառնանք այս տեխնոլոգիաներին և կնշենք դիզայնի տարբեր ընտրությունների ազդեցությունը ճանապարհին: Դուք ձեռք կբերեք խորը պատկերացում երկու ապրանքների մասին, հասկանալու, թե ինչպես դրանք պետք է և ինչպես չպետք է օգտագործվեն, և կհասկանաք, թե ինչի վրա պետք է ուշադրություն դարձնել ապագայում հաղորդագրությունների փոխանակման այլ տեխնոլոգիաներ դիտարկելիս:

Նախքան սկսելը, եկեք անցնենք հիմունքներին:

Ինչ է հաղորդագրությունների համակարգը և ինչու է այն անհրաժեշտ

Որպեսզի երկու հավելվածները միմյանց հետ շփվեն, նրանք նախ պետք է սահմանեն ինտերֆեյս: Այս ինտերֆեյսի սահմանումը ներառում է տրանսպորտի կամ արձանագրության ընտրություն, ինչպիսիք են HTTP, MQTT կամ SMTP, և հաղորդագրությունների ձևաչափերի բանակցությունները, որոնք համակարգերը կփոխանակեն: Սա կարող է լինել խիստ գործընթաց, ինչպիսին է XML սխեմայի սահմանումը հաղորդագրության համար ծանրաբեռնվածության ծախսերի պահանջներով, կամ կարող է լինել շատ ավելի քիչ պաշտոնական, ինչպես, օրինակ, երկու մշակողների միջև համաձայնություն, որ HTTP հարցումի որոշ մասը կպարունակի հաճախորդի նույնացուցիչ:

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

Հաղորդագրությունների համակարգերը սովորաբար ներառում են միջնորդ երկու համակարգերի միջև, որոնք փոխազդում են՝ հետագայում ուղարկողին ստացողից կամ ստացողներից բաժանելու (առանձնացնելու) համար: Այս դեպքում հաղորդագրությունների համակարգը թույլ է տալիս ուղարկողին ուղարկել հաղորդագրություն՝ չիմանալով, թե որտեղ է գտնվում ստացողը, արդյոք նա ակտիվ է, թե դրանցից քանիսն է:

Եկեք նայենք մի քանի անալոգիաների տեսակի խնդիրների համար, որոնք լուծում է հաղորդագրությունների համակարգը և ներկայացնենք մի քանի հիմնական տերմիններ:

Կետ առ կետ

Ալեքսանդրան գնում է փոստ՝ Ադամին փաթեթ ուղարկելու։ Նա մոտենում է պատուհանին և ծանրոցը հանձնում աշխատակցին: Աշխատակիցը վերցնում է փաթեթը և Ալեքսանդրային տալիս կտրոն։ Փաթեթն ուղարկելիս Ադամը տանը լինելու կարիք չունի: Ալեքսանդրան վստահ է, որ փաթեթը ապագայում ինչ-որ պահի կառաքվի Ադամին և կարող է շարունակել զբաղվել իր գործով: Ավելի ուշ, ինչ-որ պահի, Ադամը փաթեթ է ստանում։

Սա հաղորդագրությունների մոդելի օրինակ է կետ առ կետ. Փոստային բաժանմունքն այստեղ գործում է որպես փաթեթների բաշխման մեխանիզմ՝ ապահովելով, որ յուրաքանչյուր փաթեթ առաքվի մեկ անգամ: Փոստի օգտագործումը տարանջատում է ծանրոցն ուղարկելու ակտը ծանրոցների առաքումից:
Դասական հաղորդագրությունների համակարգերում կետ առ կետ մոդելն իրականացվում է միջոցով հերթեր. Հերթը գործում է որպես FIFO (առաջին ներս, առաջին դուրս) բուֆեր, որին կարող են բաժանորդագրվել մեկ կամ մի քանի սպառողներ: Յուրաքանչյուր հաղորդագրություն առաքվում է միայն բաժանորդագրված սպառողներից մեկը. Հերթերը սովորաբար փորձում են արդարացիորեն բաժանել հաղորդագրությունները սպառողների միջև: Միայն մեկ սպառող կստանա այս հաղորդագրությունը:

Հերթերի նկատմամբ կիրառվում է «դիմացկուն» տերմինը։ Հուսալիություն ծառայողական հատկություն է, որը երաշխավորում է, որ հաղորդագրությունների համակարգը կպահպանի հաղորդագրությունները ակտիվ բաժանորդների բացակայության դեպքում, մինչև սպառողը բաժանորդագրվի հաղորդագրությունների առաքման հերթին:

Հուսալիությունը հաճախ շփոթվում է համառություն և, չնայած երկու տերմինները փոխարինելի են, նրանք կատարում են տարբեր գործառույթներ: Համառությունը որոշում է, թե արդյոք հաղորդագրությունը գրվում է հաղորդագրությունների համակարգի կողմից ինչ-որ պահեստում այն ​​ստանալու և սպառողին ուղարկելու միջև ընկած ժամանակահատվածում: Հերթին ուղարկված հաղորդագրությունները կարող են լինել կամ չլինել մշտական:
Կետ առ կետ հաղորդագրություններն օգտագործվում են, երբ օգտագործման դեպքը պահանջում է մեկ գործողություն հաղորդագրության վրա: Օրինակները ներառում են դրամական միջոցներ հաշվին մուտքագրելը կամ առաքման պատվերի կատարումը: Մենք ավելի ուշ կքննարկենք, թե ինչու հաղորդագրությունների համակարգն ինքնին ի վիճակի չէ ապահովել մեկանգամյա առաքում, և ինչու հերթերը լավագույն դեպքում կարող են ապահովել առաքման երաշխիք: գոնե մեկ անգամ.

Հրատարակիչ-բաժանորդ

Գաբրիելլան հավաքում է կոնֆերանսի համարը: Մինչ նա միացված է համաժողովին, նա լսում է այն ամենը, ինչ ասում է բանախոսը, ինչպես նաև զանգի մնացած մասնակիցներին: Երբ նա սևանում է, նա բաց է թողնում ասվածը: Երբ նորից միանում է, նա շարունակում է լսել, թե ինչ են ասում:

Սա հաղորդագրությունների մոդելի օրինակ է հրապարակել-բաժանորդագրվել. Կոնֆերանսի զանգը գործում է որպես հեռարձակման մեխանիզմ: Խոսողին չի հետաքրքրում, թե քանի մարդ է ներկա պահին զանգահարում. համակարգը երաշխավորում է, որ ցանկացած ոք, ով ներկայումս միացված է, կլսի, թե ինչ է ասվում:
Դասական հաղորդագրությունների համակարգերում հրապարակել-բաժանորդագրվել հաղորդագրությունների մոդելն իրականացվում է միջոցով թեմաներ. Թեման ապահովում է հեռարձակման նույն մեթոդը, ինչ կոնֆերանսի մեխանիզմը: Երբ հաղորդագրություն է տեղադրվում թեմայում, այն տարածվում է բոլոր բաժանորդագրված օգտվողների համար.

Թեմաներ սովորաբար անվստահելի (անհուսալի). Ինչպես ունկնդիրը, որը չի կարող լսել, թե ինչ է ասվում կոնֆերանսի ժամանակ, երբ ունկնդիրն անցանց է լինում, թեմայի բաժանորդները բաց են թողնում ցանկացած հաղորդագրություն, որն ուղարկվում է, երբ նրանք անցանց են: Այդ իսկ պատճառով կարելի է ասել, որ գագաթները ապահովում են առաքման երաշխիք։ ոչ ավելի, քան մեկ անգամ յուրաքանչյուր սպառողի համար:

Հրապարակել-Բաժանորդագրվել հաղորդագրությունները սովորաբար օգտագործվում են, երբ հաղորդագրությունները տեղեկատվական բնույթ են կրում, և մեկ հաղորդագրության կորուստն առանձնապես նշանակալի չէ: Օրինակ, թեման կարող է վայրկյանում մեկ անգամ փոխանցել ջերմաստիճանի ընթերցումներ մի խումբ սենսորներից: Համակարգը, որը հետաքրքրված է ընթացիկ ջերմաստիճանով և որը բաժանորդագրված է թեմային, չի անհանգստանա, եթե հաղորդագրություն բաց թողնի. շուտով մեկ ուրիշը կգա:

հիբրիդային մոդելներ

Խանութի կայքը պատվերի հաղորդագրությունները դնում է «հաղորդագրությունների հերթում»: Այդ հաղորդագրությունների հիմնական սպառողը գործադիր համակարգն է։ Բացի այդ, աուդիտի համակարգը պետք է ունենա այս պատվերի հաղորդագրությունների պատճենները՝ հետագայում հետևելու համար: Երկու համակարգերն էլ չեն կարող բաց թողնել հաղորդագրությունները, նույնիսկ եթե համակարգերն իրենք որոշ ժամանակ անհասանելի են: Կայքը չպետք է տեղյակ լինի այլ համակարգերի մասին:

Օգտագործման դեպքերը հաճախ պահանջում են հրապարակել-բաժանորդագրվել և կետ առ կետ հաղորդագրությունների մոդելների խառնուրդ, օրինակ, երբ մի քանի համակարգերի կարիք ունեն հաղորդագրության պատճենը, և հաղորդագրության կորուստը կանխելու համար պահանջվում է և՛ հուսալիություն, և՛ հաստատակամություն:

Այս դեպքերում պահանջվում է նպատակակետ (ընդհանուր տերմին՝ հերթերի և թեմաների համար), որը հաղորդագրությունները հիմնականում բաշխում է թեմայի նման, այնպես որ յուրաքանչյուր հաղորդագրություն ուղարկվում է առանձին համակարգ, որը հետաքրքրված է այդ հաղորդագրություններով, բայց նաև, որտեղ յուրաքանչյուր համակարգ կարող է սահմանել մի քանի սպառող։ որոնք ստանում են մուտքային հաղորդագրություններ, որն ավելի շուտ հերթ է հիշեցնում։ Ընթերցանության տեսակն այս դեպքում − է մեկ անգամ յուրաքանչյուր շահագրգիռ կողմի համար. Այս հիբրիդային ուղղությունները հաճախ պահանջում են երկարակեցություն, որպեսզի սպառողի անջատման դեպքում հաղորդագրությունները, որոնք ուղարկվում են այդ պահին, ընդունվում են, երբ սպառողը նորից միանում է:

Հիբրիդային մոդելները նոր չեն և կարող են կիրառվել հաղորդագրությունների համակարգերի մեծ մասի համար, ներառյալ ActiveMQ-ն (վիրտուալ կամ կոմպոզիտային ուղղություններով, որոնք միավորում են թեմաներն ու հերթերը), և Kafka-ն (ուղղակիորեն, որպես նպատակակետի դիզայնի հիմնական հատկություն):

Այժմ, երբ մենք ունենք որոշ հիմնական տերմինաբանություն և հասկանում ենք, թե ինչի համար կարող է օգտակար լինել հաղորդագրությունների համակարգը, եկեք մանրամասն քննարկենք:

Թարգմանությունը կատարված է. tele.gg/middle_java

Հաջորդ թարգմանված մասը. Գլուխ 3. Կաֆկա

Շարունակելի…

Source: www.habr.com