Шта би могло натерати тако велику компанију као што је Ламода, са поједностављеним процесом и десетинама међусобно повезаних услуга, да значајно промени свој приступ? Мотивација може бити потпуно различита: од законодавне до жеље за експериментисањем својствене свим програмерима.
Али то не значи да не можете рачунати на додатне погодности. Сергеј Заика ће вам рећи шта тачно можете да освојите ако примените АПИ вођен догађајима на Кафки (). Такође ће свакако бити речи о великим снимцима и занимљивим открићима - експеримент не може без њих.
Одрицање одговорности: Овај чланак је заснован на материјалима са састанка који је Сергеј одржао у новембру 2018. на ХигхЛоад++. Ламодино живо искуство рада са Кафком привукло је слушаоце ништа мање од осталих извештаја на распореду. Сматрамо да је ово одличан пример чињенице да увек можете и треба да нађете истомишљенике, а организатори ХигхЛоад++-а ће наставити да се труде да створе атмосферу погодну за то.
О процесу
Ламода је велика платформа за е-трговину која има свој контакт центар, услугу доставе (и много филијала), фото студио, огромно складиште, а све то ради на сопственом софтверу. Постоји на десетине начина плаћања, б2б партнера који могу користити неке или све ове услуге и желе да знају најновије информације о својим производима. Поред тога, Ламода послује у три земље поред Руске Федерације и тамо је све мало другачије. Укупно, вероватно постоји више од стотину начина за конфигурисање новог налога, који се мора обрадити на свој начин. Све ово функционише уз помоћ десетина сервиса који понекад комуницирају на неочигледне начине. Постоји и централни систем чија су главна одговорност статуси наруџби. Зовемо је БОБ, ја радим са њом.
Алатка за рефундирање са АПИ-јем вођеним догађајима
Реч вођени догађајима је прилично шашава; мало даље ћемо детаљније дефинисати шта се под тим подразумева. Почећу од контекста у којем смо одлучили да испробамо АПИ приступ вођен догађајима у Кафки.
У свакој продавници, поред поруџбина које купци плаћају, постоје тренуци када је продавница у обавези да врати новац јер производ није одговарао купцу. Ово је релативно кратак процес: појашњавамо информације, ако је потребно, и преносимо новац.
Али повратак је постао компликованији због промена у законодавству и морали смо да имплементирамо засебан микросервис за њега.
Наша мотивација:
- Закон ФЗ-54 - укратко, закон налаже да се пореска управа извештава о свакој новчаној трансакцији, било да се ради о поврату или признаници, у прилично кратком СЛА од неколико минута. Ми, као компанија за е-трговину, обављамо доста послова. Технички, ово значи нову одговорност (а самим тим и нову услугу) и побољшања у свим укљученим системима.
- БОБ сплит је интерни пројекат компаније како би се БОБ ослободио великог броја неосновних одговорности и смањила његова укупна сложеност.
Овај дијаграм приказује главне Ламода системе. Сада их је већина више констелација од 5-10 микросервиса око монолита који се смањује. Они полако расту, али ми покушавамо да их смањимо, јер је постављање фрагмента одабраног у средини застрашујуће - не можемо дозволити да падне. Приморани смо да резервишемо све размене (стрелице) и да узмемо у обзир чињеницу да се било која од њих може показати недоступном.
БОБ такође има доста размена: системи плаћања, системи испоруке, системи обавештења итд.
Технички БОБ је:
- ~150к редова кода + ~100к редова тестова;
- пхп7.2 + Зенд 1 & Симфони Цомпонентс 3;
- >100 АПИ-ја & ~50 излазних интеграција;
- 4 земље са сопственом пословном логиком.
Примена БОБ-а је скупа и болна, количина кода и проблема које решава је толика да нико не може све то да убаци у своју главу. Генерално, постоји много разлога да се то поједностави.
Процес повратка
У почетку су у процес укључена два система: БОБ и Паимент. Сада се појављују још две:
- Служба за фискализацију, која ће се бавити проблемима фискализације и комуникације са екстерним службама.
- Алат за рефундирање, који једноставно садржи нове размене како не би надувао БОБ.
Сада процес изгледа овако:
- БОБ прима захтев за повраћај средстава.
- БОБ говори о овом алату за рефундирање.
- Алатка за рефундирање каже Плаћању: „Врати новац“.
- Плаћање враћа новац.
- Алат за рефундирање и БОБ синхронизују статусе један са другим, јер им је за сада потребан обојици. Још увек нисмо спремни да у потпуности пређемо на Рефунд Тоол, пошто БОБ има УИ, извештаје за рачуноводство и уопште много података који се не могу тако лако пренети. Морате седети на две столице.
- Захтев за фискализацију одлази.
Као резултат тога, направили смо неку врсту аутобуса за догађаје на Кафки - евент-бус, на коме је све почело. Ура, сада имамо једну тачку неуспеха (сарказам).
Предности и недостаци су прилично очигледни. Направили смо аутобус, што значи да сада све услуге зависе од њега. Ово поједностављује дизајн, али уводи једну тачку квара у систем. Кафка ће се срушити, процес ће стати.
Шта је АПИ вођен догађајима
Добар одговор на ово питање налази се у извештају Мартина Фаулера (ГОТО 2017) .
Укратко шта смо урадили:
- Замотајте све асинхроне размене преко складиштење догађаја. Уместо да сваког заинтересованог потрошача обавестимо о промени статуса преко мреже, ми напишемо догађај о промени статуса у централизовано складиште, а потрошачи заинтересовани за тему читају све што се одатле појави.
- Догађај у овом случају је обавештење (Обавештења) да се негде нешто променило. На пример, статус поруџбине се променио. Потрошач који је заинтересован за неке податке уз промену статуса који нису укључени у обавештење може сам сазнати њен статус.
- Максимална опција је потпуни извор догађаја, државни трансфер, у којем догађају се налазе све информације неопходне за обраду: одакле су дошли и у који статус су отишли, како су се тачно подаци променили итд. Питање је само изводљивост и количина информација коју можете себи приуштити да ускладиштите.
Као део покретања алата за рефундирање, користили смо трећу опцију. Ово је поједноставило обраду догађаја јер није било потребе за извлачењем детаљних информација, плус елиминисало је сценарио где сваки нови догађај генерише налет захтева за добијање појашњења од потрошача.
Сервис алата за рефундирање није учитано, тако да је Кафка више укус пера него потреба. Не мислим да би посао био срећан ако би услуга рефундирања постала пројекат великог оптерећења.
Асинхронизована размена КАО ЈЕСТЕ
За асинхроне размене, ПХП одељење обично користи РаббитМК. Прикупили смо податке за захтев, ставили га у ред, а потрошач исте услуге је прочитао и послао (или није послао). За сам АПИ, Ламода активно користи Сваггер. Дизајнирамо АПИ, описујемо га у Сваггер-у и генеришемо клијентски и серверски код. Такође користимо мало побољшани ЈСОН РПЦ 2.0.
На неким местима се користе ЕСБ аутобуси, неки живе на активном МК-у, али, генерално, РаббитМК - стандард.
Асинхронизована размена ТО БЕ
Приликом пројектовања размене преко сабирнице догађаја, може се пратити аналогија. На сличан начин описујемо будућу размену података кроз описе структуре догађаја. иамл формат, морали смо сами да урадимо генерисање кода, генератор креира ДТО-ове према спецификацији и учи клијенте и сервере да раде са њима. Генерација иде на два језика - голанг и пхп. Ово помаже да библиотеке буду доследне. Генератор је написан голангом, због чега је и добио име гоги.
Извор догађаја код Кафке је типична ствар. Постоји решење из главне пословне верзије Кафка Цонфлуента, постоји , решење из нашег домена браће Заландо. Наше мотивација да се почне са ванили Кафка - то значи да оставимо решење слободним док коначно не одлучимо да ли ћемо га користити свуда, а такође и себи оставити простор за маневар и побољшања: желимо подршку за наше ЈСОН РПЦ 2.0, генератори за два језика и да видимо шта још.
Иронично је да чак и у овако срећном случају, када постоји отприлике сличан посао, Заландо, који је направио отприлике слично решење, не можемо га ефикасно искористити.
Архитектонски образац при лансирању је следећи: читамо директно из Кафке, али пишемо само преко догађаја-буса. У Кафки има много тога спремног за читање: брокери, балансери, и више-мање је спреман за хоризонтално скалирање, желео сам да задржим ово. Желели смо да завршимо снимање преко једног Гатеваи-а званог Евентс-бус, и ево зашто.
Догађаји-бус
Или аутобус за догађаје. Ово је једноставно хттп гатеваи без држављанства, који преузима неколико важних улога:
- Продуцинг Валидатион — проверавамо да ли догађаји испуњавају наше спецификације.
- Мастер систем догађаја, односно ово је главни и једини систем у компанији који одговара на питање који догађаји са којим структурама се сматрају валидним. Валидација једноставно укључује типове података и енуме за стриктно специфицирање садржаја.
- Хеш функција за шардовање – структура Кафка поруке је кључ/вредност и помоћу хеш кључа се израчунава где да се стави.
Zašto
Радимо у великој компанији са поједностављеним процесом. Зашто било шта мењати? Ово је експеримент, и очекујемо да ћемо имати неколико предности.
1:н+1 размене (један према више)
Кафка олакшава повезивање нових потрошача са АПИ-јем.
Рецимо да имате директоријум који треба да одржавате у току у неколико система одједном (и у неким новим). Раније смо измислили пакет који је имплементирао сет-АПИ, а главни систем је био обавештен о адресама потрошача. Сада главни систем шаље ажурирања теме, а сви заинтересовани је читају. Појавио се нови систем - пријавили смо га за тему. Да, такође у пакету, али једноставније.
У случају алата за рефундирање, који је део БОБ-а, згодно нам је да их синхронизујемо преко Кафке. Уплата каже да је новац враћен: БОБ, РТ су сазнали за ово, променили статусе, Служба за фискализацију је то сазнала и издала чек.
Имамо планове да направимо јединствену услугу обавештења која би обавештавала клијента о новостима у вези са његовом поруџбином/повратима. Сада је ова одговорност распоређена између система. Биће нам довољно да научимо Службу за обавештења да ухвати релевантне информације од Кафке и одговори на њих (и онемогући ова обавештења у другим системима). Неће бити потребне нове директне размене.
На основу података
Информације између система постају транспарентне - без обзира на то какво „крваво предузеће“ имате и колико год да је ваш заостатак пун. Ламода има одељење за аналитику података које прикупља податке из система и ставља их у форму за вишекратну употребу, како за пословне тако и за интелигентне системе. Кафка вам омогућава да им брзо дате много података и да тај ток информација одржавате ажурним.
Дневник репликације
Поруке не нестају након читања, као у РаббитМК. Када догађај садржи довољно информација за обраду, имамо историју недавних промена на објекту и, по жељи, могућност примене ових промена.
Период складиштења дневника репликације зависи од интензитета писања на ову тему; Кафка вам омогућава да флексибилно поставите ограничења за време складиштења и обим података. За интензивне теме важно је да сви потрошачи имају времена да прочитају информацију пре него што она нестане, чак и у случају краткотрајне неисправности. Обично је могуће чувати податке за јединице дана, што је сасвим довољно за подршку.
Следеће, мало препричавање документације, за оне који нису упознати са Кафком (слика је такође из документације)
АМКП има редове: ми пишемо поруке у ред за потрошача. Типично, један ред обрађује један систем са истом пословном логиком. Ако треба да обавестите неколико система, можете научити апликацију да пише у неколико редова или да конфигурише размену помоћу механизма фаноут, који их сам клонира.
Кафка има сличну апстракцију тема, у које пишете поруке, али оне не нестају након читања. Подразумевано, када се повежете са Кафком, примате све поруке и имате опцију да сачувате где сте стали. То јест, читате узастопно, не можете да означите поруку као прочитану, али сачувате ИД са којег можете да наставите са читањем. Ид на који сте се определили се зове офсет, а механизам је померање урезивања.
Сходно томе, може се применити другачија логика. На пример, имамо БОБ у 4 случаја за различите земље - Ламода је у Русији, Казахстану, Украјини, Белорусији. Пошто су распоређени одвојено, имају мало другачије конфигурације и сопствену пословну логику. У поруци назначавамо на коју се државу односи. Сваки БОБ потрошач у свакој земљи чита са различитим гроупИд-ом, а ако се порука не односи на њих, они је прескачу, тј. одмах урезује офсет +1. Ако исту тему чита наша Служба за плаћање, онда то чини са посебном групом, па се одступања не укрштају.
Захтеви за догађај:
- Потпуност података. Волео бих да догађај има довољно података да се може обрадити.
- Интегритет Делегирамо Евентс-бусу верификацију да је догађај конзистентан и да може да га обради.
- Редослед је важан. У случају повратка, принуђени смо да радимо са историјом. Код обавештења редослед није битан, ако се ради о хомогеним обавештењима, мејл ће бити исти без обзира која је наруџба прва стигла. У случају повраћаја средстава, постоји јасан процес; ако променимо редослед, појавиће се изузеци, повраћај неће бити креиран или обрађен – завршићемо у другом статусу.
- Доследност. Имамо продавницу и сада креирамо догађаје уместо АПИ-ја. Потребан нам је начин да брзо и јефтино пренесемо информације о новим догађајима и променама у постојећим нашим услугама. Ово се постиже заједничком спецификацијом у посебном гит спремишту и генераторима кода. Стога су клијенти и сервери у различитим сервисима усклађени.
Кафка у Ламоди
Имамо три Кафкине инсталације:
- Дневници;
- Р&Д;
- Догађаји-бус.
Данас говоримо само о последњој тачки. На евент-бусу немамо баш велике инсталације - 3 брокера (сервера) и само 27 тема. По правилу, једна тема је један процес. Али ово је суптилна тачка и сада ћемо је се дотакнути.
Изнад је графикон броја обртаја. Процес повраћаја средстава је означен тиркизном линијом (да, оном на Кс оси), а ружичаста линија је процес ажурирања садржаја.
Ламода каталог садржи милионе производа, а подаци се стално ажурирају. Неке колекције излазе из моде, нове се пуштају да их замене, а нови модели се стално појављују у каталогу. Трудимо се да предвидимо шта ће сутра бити интересантно нашим купцима, па стално купујемо нове ствари, фотографишемо их и ажурирамо витрину.
Пинк врхови су ажурирања производа, односно промене у производима. Види се да су се момци сликали, сликали, па опет! — учитао је пакет догађаја.
Случајеви коришћења Ламода Евентс
Конструисану архитектуру користимо за следеће операције:
- Праћење статуса повратка: позив на акцију и праћење статуса из свих укључених система. Плаћање, статуси, фискализација, обавештења. Овде смо тестирали приступ, направили алате, прикупили све грешке, написали документацију и рекли колегама како да је користе.
- Ажурирање картица производа: конфигурација, мета-подаци, карактеристике. Један систем чита (који се приказује), а неколико пише.
- Емаил, пусх и смс: наруџбина је сакупљена, поруџбина је стигла, враћање је прихваћено итд., има их доста.
- Залиха, обнова магацина — квантитативно ажурирање артикала, само бројеви: долазак у складиште, повратак. Неопходно је да сви системи повезани са резервисањем робе раде са најновијим подацима. Тренутно је систем ажурирања залиха прилично сложен; Кафка ће га поједноставити.
- Анализа података (одсек за истраживање и развој), МЛ алати, аналитика, статистика. Желимо да информације буду транспарентне - Кафка је за то добро прилагођен.
Сада занимљивији део о великим ударцима и занимљивим открићима до којих је дошло у протеклих шест месеци.
Проблеми са дизајном
Рецимо да желимо да урадимо нову ствар - на пример, да пребацимо цео процес испоруке на Кафку. Сада је део процеса имплементиран у Обради налога у БОБ-у. Постоји статусни модел који стоји иза преноса наруџбине у службу доставе, кретања у међускладиште и тако даље. Постоји читав монолит, чак два, плус гомила АПИ-ја посвећених испоруци. Они знају много више о испоруци.
Чини се да су то сличне области, али Обрада наруџбине у БОБ-у и Систем испоруке имају различите статусе. На пример, неке курирске службе не шаљу посредне статусе, већ само коначне: „испоручено“ или „изгубљено“. Други, напротив, веома детаљно извештавају о кретању робе. Свако има своја правила валидације: за неке је е-пошта важећа, што значи да ће бити обрађена; за друге не важи, али ће наруџбина ипак бити обрађена јер постоји телефон за контакт, а неко ће рећи да таква наруџба неће бити обрађена уопште.
Ток података
У случају Кафке поставља се питање организовања тока података. Овај задатак укључује избор стратегије на основу неколико тачака; хајде да их прођемо кроз све.
У једној теми или у различитим?
Имамо спецификацију догађаја. У БОБ-у пишемо да је потребно доставити ту и такву наруџбу и назначити: број наруџбе, њен састав, неке СКУ-ове и бар кодове итд. Када роба стигне у складиште, испорука ће моћи да добије статусе, временске ознаке и све што је потребно. Али онда желимо да примамо ажурирања ових података у БОБ-у. Имамо обрнути процес пријема података од испоруке. Да ли је ово исти догађај? Или је ово посебна размена која заслужује своју тему?
Највероватније ће бити веома слични, а искушење да се направи једна тема није неосновано, јер посебна тема значи одвојене потрошаче, одвојене конфигурације, одвојену генерацију свега овога. Али није чињеница.
Ново поље или нови догађај?
Али ако користите исте догађаје, онда настаје још један проблем. На пример, не могу сви системи испоруке да генеришу врсту ДТО-а коју БОБ може да генерише. Шаљемо им ИД, али га они не чувају јер им није потребан, а са становишта покретања процеса сабирнице догађаја, ово поље је обавезно.
Ако уведемо правило за сабирницу догађаја да је ово поље обавезно, онда смо приморани да поставимо додатна правила валидације у БОБ-у или у почетном руковаоцу догађаја. Валидација почиње да се шири кроз услугу - то није баш згодно.
Други проблем је искушење инкременталног развоја. Речено нам је да догађају треба нешто додати, а можда је, ако размислимо, требало да буде посебан догађај. Али у нашој шеми, посебан догађај је посебна тема. Посебна тема је цео процес који сам горе описао. Програмер је у искушењу да једноставно дода још једно поље у ЈСОН шему и поново га генерише.
У случају рефундирања, стигли смо до догађаја за пола године. Имали смо један мета-догађај под називом ажурирање рефундирања, који је имао поље типа које описује шта је ово ажурирање заправо било. Због тога смо имали „дивне“ прекидаче са валидаторима који су нам рекли како да потврдимо овај догађај са овим типом.
Верзија догађаја
Да бисте потврдили поруке у Кафки, можете користити , али је било потребно одмах положити на њега и користити Цонфлуент. У нашем случају, морамо бити пажљиви са верзијама. Неће увек бити могуће поново прочитати поруке из дневника репликације јер је модел „остао“. У суштини, испада да се праве верзије тако да је модел компатибилан уназад: на пример, учините поље привремено опционим. Ако су разлике превелике, почињемо да пишемо у новој теми, а клијенте преносимо када заврше читање старе.
Гарантован редослед читања партиција
Теме унутар Кафке подељене су на партиције. Ово није веома важно док дизајнирамо ентитете и размене, али је важно када одлучујемо како да га конзумирамо и скалирамо.
У уобичајеном случају напишете једну тему у Кафки. Подразумевано се користи једна партиција и све поруке у овој теми иду на њу. И потрошач сходно томе чита ове поруке узастопно. Рецимо да сада треба да проширимо систем тако да поруке читају два различита потрошача. Ако, на пример, шаљете СМС, онда можете рећи Кафки да направи додатну партицију, а Кафка ће почети да дели поруке на два дела - пола овде, пола овде.
Како их Кафка дели? Свака порука има тело (у коме чувамо ЈСОН) и кључ. Овом кључу можете приложити хеш функцију, која ће одредити у коју партицију ће порука ићи.
У нашем случају са рефундирањем, ово је важно, ако узмемо две партиције, онда постоји шанса да ће паралелни потрошач обрадити други догађај пре првог и доћи ће до проблема. Хеш функција осигурава да поруке са истим кључем заврше на истој партицији.
Догађаји наспрам команди
Ово је још један проблем на који смо наишли. Догађај је одређени догађај: кажемо да се негде нешто догодило (нешто_се догодило), на пример, ставка је отказана или је дошло до повраћаја новца. Ако неко слуша ове догађаје, онда ће према „ставка отказана“ бити креиран ентитет за повраћај, а „поврат се десио“ биће записан негде у подешавањима.
Али обично, када дизајнирате догађаје, не желите да их пишете узалуд - ослањате се на чињеницу да ће их неко прочитати. Постоји велико искушење да напишете не нешто_се догодило (ставка_отказано, рефундирано_повратно), већ нешто_треба_да се_уради. На пример, предмет је спреман за враћање.
С једне стране, то сугерише како ће се догађај користити. С друге стране, звучи много мање као уобичајено име догађаја. Осим тога, није далеко одавде до команде до_сометхинг. Али немате гаранцију да је неко прочитао овај догађај; и ако га прочиташ, онда си га успешно прочитао; а ако сте га успешно прочитали, онда сте нешто урадили, и то нешто је било успешно. Оног тренутка када догађај постане уради нешто, повратна информација постаје неопходна, а то је проблем.
У асинхроној размени у РаббитМК-у, када прочитате поруку, идите на хттп, имате одговор - барем да је порука примљена. Када пишете Кафки, постоји порука коју сте написали Кафки, али не знате ништа о томе како је она обрађена.
Због тога смо у нашем случају морали да уведемо догађај одговора и подесимо праћење тако да ако се пошаље толико догађаја, после тог и тог времена треба да стигне исти број догађаја одговора. Ако се то не догоди, онда изгледа да је нешто пошло наопако. На пример, ако смо послали догађај „итем_реади_то_рефунд“, очекујемо да ће бити креиран повраћај средстава, новац ће бити враћен клијенту, а догађај „монеи_рефундед“ ће бити послат нама. Али то није сигурно, па је потребно праћење.
Нуанце
Постоји прилично очигледан проблем: ако читате из теме узастопно, а имате неку лошу поруку, потрошач ће пасти, а ви нећете ићи даље. Потребан вам је зауставити све потрошаче, урезујте даље да бисте наставили са читањем.
Знали смо за то, рачунали смо на то, а ипак се догодило. А ово се десило зато што је догађај био валидан са становишта сабирнице догађаја, догађај је био валидан са становишта валидатора апликације, али није био валидан са становишта ПостгреСКЛ-а, јер у нашем једном систему МиСКЛ са УНСИГНЕД ИНТ, а у новонаписаном систем је имао ПостгреСКЛ само са ИНТ. Његова величина је мало мања, а Ид није одговарао. Симфони је умро са изузетком. Наравно, ухватили смо изузетак јер смо се ослањали на њега, и хтели смо да урезујемо овај офсет, али смо пре тога желели да повећамо бројач проблема, пошто је порука неуспешно обрађена. Бројачи у овом пројекту су такође у бази података, а Симфони је већ затворио комуникацију са базом података, а други изузетак је убио цео процес без шансе да изврши офсет.
Сервис је залегао неко време - на срећу, код Кафке ово није тако лоше, јер поруке остају. Када се рад врати, можете их завршити са читањем. То је удобно.
Кафка има могућност да подеси произвољан помак помоћу алата. Али да бисте то урадили, морате зауставити све потрошаче - у нашем случају, припремите посебно издање у којем неће бити потрошача, прераспоређивања. Тада у Кафки можете померити помак кроз алате и порука ће проћи.
Још једна нијанса - дневник репликације вс рдкафка.со - везано је за специфичности нашег пројекта. Користимо ПХП, а у ПХП-у, по правилу, све библиотеке комуницирају са Кафком преко рдкафка.со спремишта, а онда постоји нека врста омотача. Можда су то наше личне потешкоће, али показало се да једноставно поновно читање дела онога што смо већ прочитали није тако лако. Генерално, било је проблема са софтвером.
Враћајући се на специфичности рада са партицијама, написано је право у документацији потрошачи >= партиције тема. Али сазнао сам за ово много касније него што сам желео. Ако желите да скалирате и имате два потрошача, потребне су вам најмање две партиције. Односно, ако сте имали једну партицију у којој се накупило 20 хиљада порука, а направили сте нову, број порука се неће ускоро изједначити. Дакле, да бисте имали два паралелна потрошача, морате се бавити партицијама.
Праћење
Мислим да ће начин на који будемо пратили бити још јаснији који проблеми постоје у постојећем приступу.
На пример, израчунавамо колико је производа у бази података недавно променило статус и, сходно томе, требало је да се догађају на основу ових промена и тај број шаљемо нашем систему за праћење. Затим од Кафке добијамо други број, колико је догађаја заиста забележено. Очигледно, разлика између ова два броја увек треба да буде нула.
Поред тога, потребно је да пратите како ради произвођач, да ли је сабирница догађаја примила поруке и како се понаша потрошач. На пример, на графиконима у наставку, алатка за рефундирање ради добро, али БОБ очигледно има неких проблема (плави врхови).
Већ сам поменуо заостајање групе потрошача. Грубо говорећи, ово је број непрочитаних порука. Генерално, наши потрошачи раде брзо, тако да је кашњење обично 0, али понекад може доћи до краткотрајног врхунца. Кафка то може да уради ван оквира, али морате да подесите одређени интервал.
Постоји пројекат који ће вам дати више информација о Кафки. Једноставно користи АПИ групе потрошача да би дао статус како се ова група ради. Поред ОК и Фаилед, постоји и упозорење, а можете сазнати да ваши потрошачи не могу да се носе са темпом производње – немају времена да лекторишу написано. Систем је прилично паметан и једноставан за коришћење.
Овако изгледа АПИ одговор. Овде је група боб-ливе-фифа, партиција рефунд.упдате.в1, статус ОК, лаг 0 - последњи коначни офсет такав и такав.
Праћење упдатед_ат СЛА (заглавио) већ сам поменуо. На пример, производ је промењен у статус да је спреман за враћање. Инсталирамо Црон, који каже да ако овај објекат није отишао на повраћај у року од 5 минута (врло брзо враћамо новац преко платних система), онда је нешто дефинитивно пошло наопако и ово је свакако случај за подршку. Стога једноставно узимамо Црон, који чита такве ствари, а ако су веће од 0, онда шаље упозорење.
Да резимирамо, коришћење догађаја је згодно када:
- информације су потребне за неколико система;
- резултат обраде није важан;
- има мало догађаја или малих догађаја.
Чини се да чланак има врло специфичну тему - асинхрони АПИ на Кафки, али у вези са тим бих желео да препоручим много ствари одједном.
Прво, следеће треба да сачекамо новембар, у априлу ће бити верзија из Санкт Петербурга, ау јуну ћемо причати о великим оптерећењима у Новосибирску.
Друго, аутор извештаја, Сергеј Заика, члан је Програмског одбора наше нове конференције о управљању знањем . Конференција је једнодневна, одржаће се 26. априла, али је њен програм веома интензиван.
А биће у мају и (са укљученим ДевОпсЦонф-ом) - тамо такође можете предложити своју тему, причати о свом искуству и жалити се на своје пуњене чуњеве.
Извор: ввв.хабр.цом