Хеј Хабр!
Подсећамо да пратећи књигу о објавили смо подједнако занимљив рад о библиотеци .
За сада, заједница само учи границе овог моћног алата. Дакле, недавно је објављен чланак са чијим преводом желимо да вас упознамо. Из сопственог искуства, аутор говори како Кафка Стреамс претворити у дистрибуирано складиште података. Уживај у читању!
Апацхе библиотека користи се широм света у предузећима за дистрибуирану обраду тока на врху Апацхе Кафке. Један од недовољно цењених аспеката овог оквира је то што вам омогућава да складиштите локално стање произведено на основу обраде нити.
У овом чланку ћу вам рећи како је наша компанија успела да исплативо искористи ову прилику приликом развоја производа за безбедност апликација у облаку. Користећи Кафка Стреамс, креирали смо микросервисе дељених стања, од којих сваки служи као отпоран на грешке и високо доступан извор поузданих информација о стању објеката у систему. За нас је ово корак напред иу погледу поузданости и лакоће подршке.
Ако сте заинтересовани за алтернативни приступ који вам омогућава да користите јединствену централну базу података за подршку формалног стања ваших објеката, прочитајте је, биће занимљиво...
Зашто смо мислили да је време да променимо начин на који радимо са заједничким стањем
Требали смо да одржавамо стање различитих објеката на основу извештаја агената (на пример: да ли је сајт нападнут)? Пре преласка на Кафка Стреамс, често смо се ослањали на јединствену централну базу података (+ сервисни АПИ) за управљање стањем. Овај приступ има своје недостатке: одржавање доследности и синхронизације постаје прави изазов. База података може постати уско грло или завршити у њој и пате од непредвидљивости.
Слика 1: Типичан сценарио подељеног стања виђен пре преласка на
Кафка и Кафка токови: агенти саопштавају своје ставове преко АПИ-ја, ажурирано стање се израчунава преко централне базе података
Упознајте Кафка Стреамс, што олакшава креирање микросервиса дељених стања
Пре отприлике годину дана, одлучили смо да пажљиво погледамо наше заједничке сценарије стања како бисмо решили ова питања. Одмах смо одлучили да испробамо Кафка Стреамс - знамо колико је скалабилан, високо доступан и толерантан на грешке, какву богату функционалност стриминга има (трансформације, укључујући и оне са стањем). Баш оно што нам је требало, а да не спомињемо колико је систем за размену порука постао зрео и поуздан у Кафки.
Сваки од микросервиса са стањем које смо креирали изграђен је на врху Кафка Стреамс инстанце са прилично једноставном топологијом. Састојао се од 1) извора 2) процесора са сталним складиштем кључ/вредност 3) синкронизације:
Слика 2: Подразумевана топологија наших стриминг инстанци за микросервисе са статусом. Имајте на уму да овде такође постоји спремиште које садржи метаподатке о планирању.
У овом новом приступу, агенти састављају поруке које се уносе у изворну тему, а потрошачи—рецимо, услуга обавештења путем поште—примају израчунато дељено стање кроз пријемник (излазна тема).
Слика 3: Нови пример тока задатка за сценарио са дељеним микросервисима: 1) агент генерише поруку која стиже у изворну тему Кафке; 2) микросервис са дељеним стањем (користећи Кафка Стреамс) га обрађује и уписује израчунато стање у завршну тему Кафке; након чега 3) потрошачи прихватају ново стање
Хеј, ова уграђена продавница кључ-вредност је заправо веома корисна!
Као што је горе поменуто, наша топологија дељеног стања садржи складиште кључ/вредност. Пронашли смо неколико опција за његово коришћење, а две од њих су описане у наставку.
Опција #1: Користите складиште кључ/вредност за прорачуне
Наше прво складиште кључ/вредност садржало је помоћне податке који су нам били потребни за прорачуне. На пример, у неким случајевима заједничко стање је одређивано по принципу „већине гласова“. Репозиторијум би могао да садржи све најновије извештаје агента о статусу неког објекта. Затим, када добијемо нови извештај од једног или другог агента, могли бисмо да га сачувамо, да преузмемо извештаје од свих осталих агената о стању истог објекта из складишта и поновимо прорачун.
Слика 4 испод показује како смо изложили складиште кључ/вредност методу обраде процесора да би се нова порука потом могла обрадити.
Илустрација 4: Отварамо приступ складишту кључ/вредност за метод обраде процесора (након тога, свака скрипта која ради са дељеним стањем мора да имплементира метод doProcess)
Опција #2: Креирање ЦРУД АПИ-ја на врху Кафка стримова
Након што смо успоставили наш основни ток задатака, почели смо да покушавамо да напишемо РЕСТфул ЦРУД АПИ за наше микросервисе дељеног стања. Желели смо да будемо у могућности да преузмемо стање неких или свих објеката, као и да поставимо или уклонимо стање објекта (корисно за подршку у позадини).
Да бисмо подржали све АПИ-је Гет Стате, кад год смо морали да поново израчунамо стање током обраде, чували смо га у уграђеном складишту кључ/вредност дуго времена. У овом случају, постаје прилично једноставно имплементирати такав АПИ користећи једну инстанцу Кафка Стреамс-а, као што је приказано на листи испод:
Слика 5: Коришћење уграђеног складишта кључ/вредност за добијање унапред израчунатог стања објекта
Ажурирање стања објекта преко АПИ-ја је такође лако имплементирати. У суштини, све што треба да урадите је да креирате Кафка продуцента и да га користите да направите запис који садржи ново стање. Ово осигурава да ће све поруке генерисане преко АПИ-ја бити обрађене на исти начин као и оне примљене од других произвођача (нпр. агената).
Слика 6: Можете подесити стање објекта помоћу Кафка произвођача
Мала компликација: Кафка има много партиција
Затим смо желели да распоредимо оптерећење обраде и побољшамо доступност обезбеђивањем кластера микроуслуга дељеног стања по сценарију. Подешавање је било лако: када смо конфигурисали све инстанце да се покрећу под истим ИД-ом апликације (и истим боотстрап серверима), скоро све остало је урађено аутоматски. Такође смо прецизирали да ће се свака изворна тема састојати од неколико партиција, тако да се свакој инстанци може доделити подскуп таквих партиција.
Напоменућу и да је уобичајена пракса да се направи резервна копија државне продавнице тако да, на пример, у случају опоравка након квара, ову копију пренесете на другу инстанцу. За сваку државну продавницу у Кафка Стреамс-у креира се реплицирана тема са евиденцијом промена (који прати локална ажурирања). Дакле, Кафка стално подржава државну продавницу. Стога, у случају квара једне или друге Кафка Стреамс инстанце, складиште стања може се брзо вратити на другу инстанцу, где ће ићи одговарајуће партиције. Наши тестови су показали да се то ради за неколико секунди, чак и ако постоје милиони записа у продавници.
Преласком са једне микроуслуге са дељеним стањем на кластер микроуслуга, постаје мање тривијално имплементирати Гет Стате АПИ. У новој ситуацији, складиште стања сваког микросервиса садржи само део укупне слике (оне објекте чији су кључеви мапирани на одређену партицију). Морали смо да одредимо која инстанца садржи стање објекта који нам је потребан, и то смо урадили на основу метаподатака нити, као што је приказано у наставку:
Слика 7: Користећи метаподатке тока, одређујемо из које инстанце да поставимо упит за стање жељеног објекта; сличан приступ је коришћен са ГЕТ АЛЛ АПИ-јем
Главни налази
Државне продавнице у Кафка Стреамс-у могу послужити као де фацто дистрибуирана база података,
- стално реплициран у Кафки
- ЦРУД АПИ се лако може изградити на врху таквог система
- Руковање са више партиција је мало компликованије
- Такође је могуће додати једно или више складишта стања у топологију стриминга за складиштење помоћних података. Ова опција се може користити за:
- Дуготрајно складиштење података потребних за прорачуне током обраде тока
- Дуготрајно складиштење података који могу бити корисни следећи пут када се инстанца за стримовање обезбеди
- много више...
Ове и друге предности чине Кафка Стреамс погодним за одржавање глобалне државе у дистрибуираном систему као што је наш. Кафка Стреамс се показао веома поузданим у продукцији (немамо скоро никаквих губитака порука откако смо га применили), и уверени смо да се његове могућности неће ту зауставити!
Извор: ввв.хабр.цом