Еј Хабр!
Ве потсетуваме дека следејќи ја книгата за објавивме исто толку интересно дело за библиотеката .
Засега, заедницата само ги учи границите на оваа моќна алатка. Така, неодамна беше објавена статија со чиј превод би сакале да ве запознаеме. Од сопственото искуство, авторот кажува како да се претвори Кафка струи во дистрибуирано складирање податоци. Уживајте во читањето!
Апачи библиотека се користи ширум светот во претпријатија за дистрибуирана обработка на поток на врвот на Apache Kafka. Еден од недоволно ценетите аспекти на оваа рамка е тоа што ви овозможува да складирате локална состојба произведена врз основа на обработка на нишки.
Во оваа статија, ќе ви кажам како нашата компанија успеа профитабилно да ја искористи оваа можност при развивање на производ за безбедност на апликациите во облак. Користејќи го Кафка Стримс, создадовме заеднички државни микроуслуги, од кои секоја служи како толерантен на грешки и високо достапен извор на веродостојни информации за состојбата на објектите во системот. За нас ова е чекор напред и во однос на сигурноста и леснотијата на поддршката.
Доколку ве интересира алтернативен пристап кој ви овозможува да користите единствена централна база на податоци за поддршка на формалната состојба на вашите објекти, прочитајте ја, ќе биде интересно...
Зошто мислевме дека е време да го промениме начинот на кој работиме со заедничка држава
Требаше да ја одржуваме состојбата на различни објекти врз основа на извештаите на агентите (на пример: дали локацијата беше нападната)? Пред да мигрираме во Кафка Стримс, честопати се потпиравме на единствена централна база на податоци (+ API на услугата) за управување со државата. Овој пристап има свои недостатоци: одржувањето на конзистентноста и синхронизацијата станува вистински предизвик. Базата на податоци може да стане тесно грло или да заврши во неа и страдаат од непредвидливост.
Слика 1: Типично сценарио со поделена состојба видено пред транзицијата кон
Кафка и Кафка струи: агентите ги комуницираат своите ставови преку API, ажурираната состојба се пресметува преку централна база на податоци
Запознајте го Kafka Streams, што го олеснува создавањето на заеднички државни микроуслуги
Пред околу една година, решивме внимателно да ги разгледаме нашите заеднички државни сценарија за да ги решиме овие прашања. Веднаш решивме да го пробаме Kafka Streams - знаеме колку е скалабилен, многу достапен и толерантен на грешки и колку е богата неговата функционалност за стриминг (трансформации, вклучително и државни). Само она што ни требаше, а да не зборуваме колку е зрел и сигурен системот за пораки во Кафка.
Секој од државните микроуслуги што ги создадовме беше изграден на врвот на примерот на Kafka Streams со прилично едноставна топологија. Се состоеше од 1) извор 2) процесор со постојан склад за клучеви 3) мијалник:
Слика 2: Стандардната топологија на нашите стриминг инстанци за државни микроуслуги. Забележете дека тука има и складиште кое содржи метаподатоци за планирање.
Во овој нов пристап, агентите составуваат пораки кои се внесуваат во изворната тема, а потрошувачите - да речеме, услуга за известување по пошта - ја примаат пресметаната споделена состојба преку мијалникот (излезна тема).
Слика 3: Нов пример на проток на задачи за сценарио со споделени микросервиси: 1) агентот генерира порака што пристигнува до изворната тема на Кафка; 2) микросервис со споделена состојба (со користење на Кафка струи) го обработува и ја запишува пресметаната состојба до крајната тема на Кафка; по што 3) потрошувачите ја прифаќаат новата состојба
Еј, оваа вградена продавница за клучеви е всушност многу корисна!
Како што беше споменато погоре, нашата топологија на заедничка состојба содржи складиште за клучна вредност. Најдовме неколку опции за користење, а две од нив се опишани подолу.
Опција бр. 1: Користете продавница за клучеви со вредност за пресметки
Нашата прва продавница за клучеви со вредност ги содржеше помошните податоци што ни беа потребни за пресметките. На пример, во некои случаи споделената состојба беше одредена со принципот на „мнозински гласови“. Складиштето може да ги чува сите најнови извештаи на агенти за статусот на некој објект. Потоа, кога ќе добиевме нов извештај од еден или друг агент, можевме да го зачуваме, да добиеме извештаи од сите други агенти за состојбата на истиот објект од складирање и да ја повториме пресметката.
Слика 4 подолу покажува како складирањето клучеви/вредности го изложивме на методот на обработка на процесорот за да може потоа да се обработи новата порака.
Илустрација 4: Отвораме пристап до продавницата за клучна вредност за методот за обработка на процесорот (по ова, секоја скрипта што работи со споделена состојба мора да го имплементира методот doProcess)
Опција бр. 2: Создавање CRUD API на врвот на Кафка Стримс
Откако го воспоставивме нашиот основен тек на задачи, почнавме да се обидуваме да напишеме RESTful CRUD API за нашите заеднички државни микроуслуги. Сакавме да можеме да ја вратиме состојбата на некои или сите објекти, како и да ја поставиме или отстраниме состојбата на некој објект (корисно за поддршка на задниот дел).
За да ги поддржиме сите Get State API, секогаш кога ни требаше повторно да ја пресметаме состојбата за време на обработката, долго време го складиравме во вградена продавница за клучеви. Во овој случај, станува прилично едноставно да се имплементира такво API со користење на единствен пример на Кафка стримови, како што е прикажано на списокот подолу:
Слика 5: Користење на вградената продавница за вредности на клучеви за да се добие претходно пресметаната состојба на објектот
Ажурирањето на состојбата на објектот преку API е исто така лесно за спроведување. Во основа, сè што треба да направите е да создадете продуцент на Кафка и да го искористите за да направите плоча што ја содржи новата состојба. Ова осигурува дека сите пораки генерирани преку API ќе бидат обработени на ист начин како оние добиени од други производители (на пр. агенти).
Слика 6: Можете да ја поставите состојбата на објектот користејќи го продуцентот Кафка
Мала компликација: Кафка има многу партиции
Следно, сакавме да го дистрибуираме оптоварувањето на обработката и да ја подобриме достапноста со обезбедување на кластер на заеднички микроуслуги по сценарио. Поставувањето беше брзо: штом ги конфигуриравме сите примероци да работат под истиот ID на апликацијата (и истите сервери за подигање), речиси сè друго беше направено автоматски. Исто така, наведовме дека секоја изворна тема ќе се состои од неколку партиции, така што на секој пример може да му се додели подмножество од такви партиции.
Исто така, ќе напоменам дека вообичаена практика е да се направи резервна копија од државната продавница, така што, на пример, во случај на закрепнување по неуспех, да ја пренесете оваа копија на друг примерок. За секоја државна продавница во Kafka Streams, се креира реплицирана тема со дневник за промени (кој ги следи локалните ажурирања). Така, Кафка постојано ја поддржува државната продавница. Затоа, во случај на дефект на еден или друг пример на Kafka Streams, државната продавница може брзо да се врати на друг примерок, каде што ќе одат соодветните партиции. Нашите тестови покажаа дека тоа се прави за неколку секунди, дури и ако има милиони записи во продавницата.
Преминувајќи од единствена микросервис со споделена состојба во кластер на микроуслуги, станува помалку тривијално да се имплементира Get State API. Во новата ситуација, државната продавница на секоја микросервис содржи само дел од целокупната слика (оние објекти чии клучеви беа мапирани на одредена партиција). Моравме да одредиме кој пример ја содржи состојбата на објектот што ни треба, и го направивме тоа врз основа на метаподатоците на низата, како што е прикажано подолу:
Слика 7: Користејќи метаподатоци за пренос, одредуваме од која инстанца да ја побараме состојбата на саканиот објект; сличен пристап беше користен со GET ALL API
Клучни наоди
Државните продавници во Kafka Streams можат да послужат како де факто дистрибуирана база на податоци,
- постојано се реплицира во Кафка
- CRUD API лесно може да се изгради на врвот на таков систем
- Ракувањето со повеќе партиции е малку покомплицирано
- Исто така, можно е да се додадат една или повеќе државни складишта во топологијата за стриминг за складирање на помошни податоци. Оваа опција може да се користи за:
- Долгорочно складирање на податоци потребни за пресметки при обработка на стрим
- Долгорочно складирање на податоци што може да бидат корисни следниот пат кога ќе се обезбеди примерот за стриминг
- многу повеќе...
Овие и други предности го прават Kafka Streams добро прилагоден за одржување на глобалната состојба во дистрибуиран систем како нашиот. Kafka Streams се покажа како многу доверлив во производството (не доживеавме практично никакво губење на пораките од неговото распоредување), и уверени сме дека неговите способности ќе се прошират и повеќе од тоа!
Извор: www.habr.com