Што би можело да натера една толку голема компанија како Ламода, со рационализиран процес и десетици меѓусебно поврзани услуги, значително да го промени својот пристап? Мотивацијата може да биде сосема поинаква: од законодавна до желба за експериментирање својствена за сите програмери.
Но, тоа не значи дека не можете да сметате на дополнителни придобивки. Сергеј Заика ќе ви каже што точно можете да победите ако го имплементирате API-то управувано од настани на Кафка (). Дефинитивно ќе се зборува и за големи снимки и интересни откритија - експериментот не може без нив.
Одрекување: Оваа статија се заснова на материјали од состанокот што Сергеј го одржа во ноември 2018 година на HighLoad++. Искуството во живо на Ламода за работа со Кафка привлече слушатели не помалку од другите извештаи од распоредот. Сметаме дека ова е одличен пример за фактот дека секогаш можете и треба да најдете истомисленици, а организаторите на HighLoad++ ќе продолжат да се обидуваат да создадат атмосфера погодна за тоа.
За процесот
Ламода е голема платформа за е-трговија која има сопствен контакт центар, услуга за испорака (и многу филијали), фото студио, огромен магацин и сето тоа работи на сопствен софтвер. Постојат десетици начини на плаќање, b2b партнери кои можеби користат некои или сите од овие услуги и сакаат да знаат ажурирани информации за нивните производи. Покрај тоа, Ламода работи во три земји покрај Руската Федерација и таму се е малку поинаку. Севкупно, веројатно има повеќе од сто начини за конфигурирање на нова нарачка, која мора да се обработи на свој начин. Сето ова функционира со помош на десетици услуги кои понекогаш комуницираат на неочигледни начини. Постои и централен систем чија главна одговорност се статусите на нарачките. Ја викаме БОБ, работам со неа.
Алатка за рефундирање со API управувано од настани
Зборот „управувано од настани“ е прилично измислен; малку понатаму ќе дефинираме подетално што се подразбира под ова. Ќе започнам со контекстот во кој решивме да го испробаме API-пристапот воден од настани во Кафка.
Во која било продавница, покрај нарачките за кои клиентите плаќаат, има моменти кога продавницата се бара да врати пари бидејќи производот не му одговарал на купувачот. Ова е релативно краток процес: ги разјаснуваме информациите, доколку е потребно, и ги префрламе парите.
Но, враќањето стана покомплицирано поради промените во законодавството и моравме да спроведеме посебна микросервис за тоа.
Нашата мотивација:
- Закон ФЗ-54 - накратко, законот бара известување до даночната служба за секоја монетарна трансакција, било да е тоа враќање или сметкопотврда, во рок од прилично краток SLA од неколку минути. Ние како компанија за е-трговија извршуваме доста операции. Технички, ова значи нова одговорност (а со тоа и нова услуга) и подобрувања во сите вклучени системи.
- БОБ Сплит е внатрешен проект на компанијата за ослободување на BOB од голем број несуштински одговорности и намалување на неговата севкупна сложеност.
Овој дијаграм ги прикажува главните системи Ламода. Сега повеќето од нив се повеќе соѕвездие од 5-10 микроуслуги околу монолит што се намалува. Тие полека растат, но ние се обидуваме да ги направиме помали, бидејќи распоредувањето на фрагментот избран во средината е страшно - не можеме да дозволиме да падне. Принудени сме да ги резервираме сите размени (стрелки) и да го земеме предвид фактот дека која било од нив може да испадне дека е недостапна.
БОБ, исто така, има доста размени: системи за плаќање, системи за испорака, системи за известување итн.
Технички БОБ е:
- ~150k линии код + ~100k линии тестови;
- php7.2 + Zend 1 & Symfony Components 3;
- >100 API и ~50 излезни интеграции;
- 4 земји со сопствена деловна логика.
Распоредувањето на BOB е скапо и болно, количината на код и проблеми што ги решава е таква што никој не може да го стави сето тоа во своите глави. Во принцип, постојат многу причини да се поедностави.
Процес на враќање
Првично, два системи се вклучени во процесот: BOB и Payment. Сега се појавуваат уште две:
- Служба за фискализација, која ќе се грижи за проблемите со фискализацијата и комуникацијата со надворешните служби.
- Алатка за рефундирање, која едноставно содржи нови размени за да не се надува BOB.
Сега процесот изгледа вака:
- БОБ добива барање за враќање на парите.
- БОБ зборува за оваа алатка за рефундирање.
- Алатката за рефундирање му кажува на Payment: „Врати ги парите“.
- Плаќањето ги враќа парите.
- Алатката за рефундирање и BOB ги синхронизираат статусите еден со друг, бидејќи засега и на двајцата им треба. Сè уште не сме подготвени целосно да се префрлиме на Алатката за рефундирање, бидејќи BOB има интерфејс, извештаи за сметководство и воопшто многу податоци што не можат да се пренесат толку лесно. Треба да седите на две столчиња.
- Барањето за фискализација заминува.
Како резултат на тоа, направивме еден вид автобус на настани на Кафка - настан-автобус, на кој започна сè. Ура, сега имаме единствена точка на неуспех (сарказам).
Добрите и лошите страни се прилично очигледни. Направивме автобус, што значи дека сега од него зависат сите услуги. Ова го поедноставува дизајнот, но воведува единствена точка на дефект во системот. Кафка ќе падне, процесот ќе престане.
Што е API управувано од настани
Добар одговор на ова прашање е во извештајот на Мартин Фаулер (GOTO 2017) .
Накратко што направивме:
- Завршете ги сите асинхрони размени преку складирање настани. Наместо да го информираме секој заинтересиран потрошувач за промена на статусот преку мрежата, ние пишуваме настан за промена на статусот во централизирано складирање, а потрошувачите заинтересирани за темата читаат сè што се појавува оттаму.
- Настанот во овој случај е известување (известувања) дека нешто се сменило некаде. На пример, статусот на нарачката е променет. Потрошувачот кој е заинтересиран за некои податоци кои ја придружуваат промената на статусот, а кои не се вклучени во известувањето, може самиот да го дознае неговиот статус.
- Максималната опција е полноправно извори на настани, државен трансфер, во кој настан ги содржи сите информации потребни за обработка: од каде дошле и во каков статус отишле, како точно се промениле податоците итн. Единственото прашање е изводливоста и количината на информации што можете да си дозволите да ги складирате.
Како дел од лансирањето на Алатката за рефундирање, ја искористивме третата опција. Оваа поедноставена обработка на настани бидејќи немаше потреба да се извлекуваат детални информации, плус го елиминираше сценариото каде што секој нов настан генерира излив на појаснувања за добивање барања од потрошувачите.
Услуга за алатка за враќање пари не е вчитан, така што Кафка има повеќе вкус на перото отколку потреба. Не мислам дека ако услугата за рефундирање стане проект со голем товар, бизнисот би бил среќен.
Асинхронизирана размена КАКО ШТО Е
За асинхрони размени, одделот PHP обично користи RabbitMQ. Ги собравме податоците за барањето, ги ставивме во редица, а потрошувачот на истата услуга го прочита и го испрати (или не го испрати). За самиот API, Lamoda активно користи Swagger. Дизајнираме API, го опишуваме во Swagger и генерираме код за клиент и сервер. Ние користиме и малку подобрен JSON RPC 2.0.
Во некои места се користат автобуси ESB, некои живеат на activeMQ, но, генерално, RabbitMQ - стандард.
Асинхронизирана размена TO BE
При дизајнирање размена преку настани-автобус, може да се следи аналогија. Слично ја опишуваме идната размена на податоци преку описи на структурата на настани. Форматот yaml, моравме сами да го направиме генерирањето код, генераторот создава DTOs според спецификацијата и ги учи клиентите и серверите да работат со нив. Генерацијата оди на два јазика - голанг и php. Ова помага библиотеките да бидат конзистентни. Генераторот е напишан со голанг, поради што го добил името гоги.
Изворот на настани на Кафка е типична работа. Постои решение од главната претпријатие верзија на Kafka Confluent, постои , решение од нашите домени браќа Заландо. Нашиот мотивација за почеток со ванила Кафка - ова значи да го оставиме решението бесплатно додека конечно не одлучиме дали ќе го користиме насекаде, а исто така да си оставиме простор за маневрирање и подобрувања: сакаме поддршка за нашите JSON RPC 2.0, генератори за два јазика и да видиме што друго.
Иронично е што и во таков среќен случај, кога има приближно сличен бизнис, Заландо, кој направи приближно слично решение, не можеме ефективно да го искористиме.
Архитектонскиот модел при лансирањето е следниов: читаме директно од Кафка, но пишуваме само преку настани-автобус. Во Кафка има многу спремни за читање: брокери, балансери, а повеќе или помалку е подготвен за хоризонтално скалирање, сакав да го задржам ова. Сакавме да го завршиме снимањето преку еден Gateway aka Events-bus, и еве зошто.
Настани-автобус
Или автобус за настани. Ова е едноставно http портал без државјанство, кој презема неколку важни улоги:
- Производство на валидација — проверуваме дали настаните ги исполнуваат нашите спецификации.
- Главниот систем на настани, односно ова е главниот и единствен систем во компанијата кој одговара на прашањето кои настани со кои структури се сметаат за валидни. Валидацијата едноставно вклучува типови на податоци и збирки за строго да се специфицира содржината.
- Хеш функција за делење - структурата на пораките на Кафка е клуч-вредност и со помош на хашот на клучот се пресметува каде да се стави.
Зошто
Работиме во голема компанија со рационализиран процес. Зошто да смените нешто? Ова е експеримент, и очекуваме да добиеме неколку придобивки.
1:n+1 размена (еден до многу)
Кафка многу го олеснува поврзувањето на новите потрошувачи со API.
Да речеме дека имате директориум што треба да го ажурирате во неколку системи одеднаш (и во некои нови). Претходно, измисливме пакет што имплементираше set-API, а главниот систем беше информиран за адресите на потрошувачите. Сега главниот систем испраќа ажурирања на темата и секој што е заинтересиран ја чита. Се појави нов систем - го потпишавме за темата. Да, исто така во пакет, но поедноставно.
Во случај на алатка за враќање пари, што е парче BOB, ни е погодно да ги одржуваме синхронизирани преку Кафка. Плаќањето вели дека парите се вратени: БОБ, РТ дознале за ова, го смениле статусот, Службата за фискализација дознала за ова и издала чек.
Имаме планови да создадеме унифицирана услуга за известувања која ќе го извести клиентот за новостите во врска со неговата нарачка/враќање. Сега оваа одговорност е распространета помеѓу системите. Ќе ни биде доволно да ја научиме службата за известувања да фати релевантни информации од Кафка и да одговори на нив (и да ги оневозможи овие известувања во други системи). Нема да бидат потребни нови директни размени.
Водени од податоци
Информациите помеѓу системите стануваат транспарентни - без разлика какво „крваво претпријатие“ имате и без разлика колку е густо вашето заостаток. Ламода има оддел за анализа на податоци што собира податоци од системи и ги става во форма за повеќекратна употреба, и за деловни и за интелигентни системи. Кафка ви овозможува брзо да им дадете многу податоци и да го ажурирате тој проток на информации.
Дневник за репликација
Пораките не исчезнуваат по читањето, како во RabbitMQ. Кога некој настан содржи доволно информации за обработка, имаме историја на неодамнешни промени на објектот и, ако сакате, можност да ги примениме овие промени.
Периодот на складирање на дневникот за репликација зависи од интензитетот на пишување на оваа тема; Кафка ви овозможува флексибилно да поставите ограничувања на времето за складирање и обемот на податоци. За интензивни теми, важно е сите потрошувачи да имаат време да ги прочитаат информациите пред да исчезнат, дури и во случај на краткорочна нефункционалност. Обично е можно да се складираат податоци за единици денови, што е сосема доволно за поддршка.
Следно, мало прераскажување на документацијата, за оние кои не се запознаени со Кафка (и сликата е од документацијата)
AMQP има редици: пишуваме пораки до редица за потрошувачот. Типично, една редица се обработува од еден систем со иста деловна логика. Ако треба да известите неколку системи, можете да ја научите апликацијата да пишува на неколку редици или да конфигурира размена со механизмот fanout, кој самиот ги клонира.
Кафка има слична апстракција тема, во кои пишувате пораки, но тие не исчезнуваат по читањето. Стандардно, кога ќе се поврзете на Кафка, ги добивате сите пораки и имате опција да зачувате таму каде што сте застанале. Односно, читате последователно, не можете да ја означите пораката како прочитана, туку да го зачувате идентификацијата од која потоа можете да продолжите со читање. Идентификаторот на кој се населивте се нарекува офсет, а механизмот е отстапување.
Според тоа, може да се имплементира различна логика. На пример, имаме БОБ во 4 случаи за различни земји - Ламода е во Русија, Казахстан, Украина, Белорусија. Бидејќи тие се распоредени одделно, тие имаат малку различни конфигурации и своја деловна логика. Во пораката посочуваме за која земја се однесува. Секој БОБ потрошувач во секоја земја чита со различен groupId и ако пораката не важи за нив, тие ја прескокнуваат, т.е. веднаш врши офсет +1. Ако истата тема ја чита нашата Платежна служба, тогаш тоа го прави со посебна група и затоа поместувањата не се вкрстуваат.
Барања за настанот:
- Комплетност на податоците. Би сакал настанот да има доволно податоци за да може да се обработи.
- Интегритет Ние ја делегираме на Events-bus потврдата дека настанот е конзистентен и дека може да го обработи.
- Редоследот е важен. Во случај на враќање, принудени сме да работиме со историјата. Кај известувањата нарачката не е важна, ако се хомогени известувања, мејлот ќе биде ист без разлика која нарачка стигнала прва. Во случај на враќање на средствата, постои јасен процес; ако го промениме редоследот, ќе се појават исклучоци, повратот нема да се креира или обработува - ќе завршиме во различен статус.
- Конзистентност. Имаме продавница и сега создаваме настани наместо API. Потребен ни е начин за брзо и евтино пренесување на информации за нови настани и промени на постоечките до нашите услуги. Ова се постигнува преку заедничка спецификација во посебно git складиште и генератори на код. Затоа, клиентите и серверите во различни услуги се координирани.
Кафка во Ламода
Имаме три инсталации на Кафка:
- Дневници;
- Истражување и развој;
- Настани-автобус.
Денес зборуваме само за последната точка. На настани-автобус немаме многу големи инсталации - 3 брокери (сервери) и само 27 теми. Како по правило, една тема е еден процес. Но, ова е суптилна точка, и ние ќе ја допреме сега.
Погоре е графикот на rps. Процесот на рефундирање е означен со тиркизна линија (да, онаа на оската X), а розовата линија е процес на ажурирање на содржината.
Каталогот Ламода содржи милиони производи, а податоците се ажурираат постојано. Некои колекции излегуваат од мода, се пуштаат нови да ги заменат, а во каталогот постојано се појавуваат нови модели. Се обидуваме да предвидиме што ќе биде интересно за нашите клиенти утре, па постојано купуваме нови работи, ги фотографираме и ја ажурираме витрината.
Пинк врвовите се ажурирања на производи, односно промени во производите. Се гледа дека момците се сликале, се сликале, па пак! — вчитав пакет настани.
Случаи за употреба на Lamoda Events
Ја користиме конструираната архитектура за следните операции:
- Следење на статусот на враќање: Повик за акција и следење статус од сите вклучени системи. Плаќање, статуси, фискализација, известувања. Овде го тестиравме пристапот, направивме алатки, ги собравме сите грешки, напишавме документација и им кажавме на нашите колеги како да го користат.
- Ажурирање на картички на производи: конфигурација, мета-податоци, карактеристики. Еден систем чита (кој прикажува), а неколку пишуваат.
- Е-пошта, притисни и смс: нарачката е собрана, нарачката пристигнала, враќањето е прифатено итн., ги има многу.
- Залиха, обновување на магацин — квантитативно ажурирање на артиклите, само бројки: пристигнување во магацин, враќање. Неопходно е сите системи поврзани со резервирање стоки да работат со најактуелните податоци. Во моментов, системот за ажурирање на акциите е доста сложен; Кафка ќе го поедностави.
- Анализа на податоци (Оддел за истражување и развој), ML алатки, аналитика, статистика. Сакаме информациите да бидат транспарентни - Кафка е добро прилагоден за ова.
Сега е поинтересниот дел за големите нерамнини и интересни откритија што се случија во изминатите шест месеци.
Проблеми со дизајнот
Да речеме дека сакаме да направиме нова работа - на пример, да го пренесеме целиот процес на испорака на Кафка. Сега дел од процесот е имплементиран во Обработка на нарачки во BOB. Постои статусен модел зад преносот на нарачката до услугата за испорака, движењето во средно складиште итн. Има цел монолит, дури два, плус еден куп API посветени на испорака. Тие знаат многу повеќе за испораката.
Се чини дека овие се слични области, но Обработката на нарачките во БОБ и Системот за испорака имаат различни статуси. На пример, некои курирски услуги не испраќаат посредни статуси, туку само конечни: „испорачани“ или „изгубени“. Други, напротив, детално известуваат за движењето на стоката. Секој има свои правила за валидација: за некои, е-поштата е валидна, што значи дека ќе биде обработена; за други не важи, но нарачката сепак ќе се обработи бидејќи има телефонски број за контакт, а некој ќе каже дека таква нарачка воопшто нема да се обработи.
Поток на податоци
Во случајот со Кафка, се поставува прашањето за организирање на протокот на податоци. Оваа задача вклучува избор на стратегија заснована на неколку точки; ајде да ги разгледаме сите.
Во една тема или во различни?
Имаме спецификација за настан. Во БОБ пишуваме дека треба да се достави таква или таква нарачка и наведуваме: бројот на нарачката, неговиот состав, некои SKU и бар кодови итн. Кога стоката ќе пристигне во магацинот, испораката ќе може да добие статуси, временски печати и се што е потребно. Но, тогаш сакаме да добиваме ажурирања за овие податоци во BOB. Имаме обратен процес на примање податоци од испораката. Дали е ова истиот настан? Или ова е посебна размена која заслужува своја тема?
Најверојатно, тие ќе бидат многу слични, а искушението да се направи една тема не е неосновано, бидејќи посебна тема значи посебни потрошувачи, посебни конфигурации, посебна генерација на сето ова. Но, не е факт.
Ново поле или нов настан?
Но, ако ги користите истите настани, тогаш се појавува друг проблем. На пример, не сите системи за испорака можат да генерираат вид на DTO што може да го генерира BOB. Им го испраќаме идентификаторот, но тие не го зачувуваат затоа што не им треба, а од гледна точка на започнување на процесот на настан-автобус, ова поле е потребно.
Ако воведеме правило за настан-магистрала дека ова поле е потребно, тогаш сме принудени да поставиме дополнителни правила за валидација во BOB или во управувачот за почетни настани. Валидацијата почнува да се шири низ целата услуга - ова не е многу погодно.
Друг проблем е искушението за постепен развој. Ни кажуваат дека нешто треба да се додаде на настанот, а можеби, ако размислиме, требало да биде посебен настан. Но, во нашата шема, посебен настан е посебна тема. Посебна тема е целиот процес што го опишав погоре. Програмерот е во искушение едноставно да додаде друго поле во шемата JSON и да ја регенерира.
Во случај на рефундирање, стигнавме на настанот на настани за половина година. Имавме еден мета-настан наречен ажурирање на рефундирање, кој имаше поле за тип што опишува што всушност е ова ажурирање. Поради ова, имавме „прекрасни“ прекинувачи со валидатори кои ни кажаа како да го потврдиме овој настан со овој тип.
Верзија за настан
За да ги потврдите пораките во Кафка можете да користите , но беше неопходно веднаш да се положи на неа и да се користи Confluent. Во нашиот случај, мора да бидеме внимателни со верзии. Не секогаш ќе може да се препрочитуваат пораките од дневникот за репликација бидејќи моделот „замина“. Во основа, излегува дека се градат верзии така што моделот е компатибилен наназад: на пример, направете поле привремено опционално. Ако разликите се премногу силни, почнуваме да пишуваме во нова тема, а клиентите ги префрламе кога ќе завршат со читање на старата.
Загарантиран редослед на читање на партиции
Темите внатре во Кафка се поделени на партиции. Ова не е многу важно додека дизајнираме ентитети и размени, но важно е кога одлучуваме како да го конзумираме и размериме.
Во вообичаениот случај, пишуваш една тема во Кафка. Стандардно, се користи една партиција и сите пораки во оваа тема одат на неа. И потрошувачот последователно ги чита овие пораки последователно. Да речеме дека сега треба да го прошириме системот така што пораките ќе ги читаат два различни потрошувачи. Ако, на пример, испраќате СМС, тогаш можете да му кажете на Кафка да направи дополнителна партиција и Кафка ќе почне да ги дели пораките на два дела - половина овде, половина овде.
Како Кафка ги дели? Секоја порака има тело (во кое складираме JSON) и клуч. Можете да прикачите хаш-функција на ова копче, што ќе определи во која партиција ќе влезе пораката.
Во нашиот случај со рефундирање, ова е важно, ако земеме две партиции, тогаш постои шанса паралелен потрошувач да го обработи вториот настан пред првиот и да има проблеми. Функцијата за хаш гарантира дека пораките со истиот клуч завршуваат во истата партиција.
Настани наспроти команди
Ова е уште еден проблем со кој наидовме. Настанот е одреден настан: велиме дека нешто се случило некаде (нешто_се случило), на пример, ставка е откажана или се случи рефундирање. Ако некој ги слуша овие настани, тогаш според „откажана ставка“, ќе се создаде субјектот за враќање на средствата, а „се случи рефундирање“ ќе биде напишано некаде во поставките.
Но, обично, кога дизајнирате настани, не сакате да ги пишувате залудно - се потпирате на фактот дека некој ќе ги прочита. Постои големо искушение да се напише не нешто_се случило (артика_откажана, рефунд_вратена), туку нешто_треба_да_се_изведе. На пример, предметот е подготвен да се врати.
Од една страна, сугерира како ќе се користи настанот. Од друга страна, многу помалку звучи како обично име на настан. Освен тоа, не е далеку од тука до командата do_something. Но, немате гаранција дека некој го прочитал овој настан; и ако го прочиташ, тогаш го читаш успешно; и ако си го прочитал успешно, тогаш си направил нешто, и тоа нешто било успешно. Во моментот кога некој настан станува do_something, повратните информации стануваат неопходни и тоа е проблем.
Во асинхрона размена во RabbitMQ, кога ќе ја прочиташ пораката, оди на http, имаш одговор - барем дека пораката е примена. Кога му пишуваш на Кафка, има порака што си ја напишал на Кафка, но не знаеш ништо за тоа како е обработена.
Затоа, во нашиот случај, моравме да воведеме настан за одговор и да поставиме мониторинг, така што ако се испраќаат толку многу настани, по такво и такво време да пристигнат ист број на настани за одговор. Ако тоа не се случи, тогаш се чини дека нешто тргнало наопаку. На пример, ако го испративме настанот „item_ready_to_refund“, очекуваме дека ќе се создаде рефундирање, парите ќе му бидат вратени на клиентот, а настанот „money_refunded“ ќе ни биде испратен. Но, тоа не е сигурно, затоа е потребен мониторинг.
Нијанси
Има прилично очигледен проблем: ако читате од тема последователно, и имате некоја лоша порака, потрошувачот ќе падне, а вие нема да одите понатаму. Ти треба запрете ги сите потрошувачи, посветете дополнително офсет за да продолжите со читање.
Знаевме за тоа, сметавме на тоа, а сепак се случи. И ова се случи затоа што настанот беше валиден од гледна точка на настани-автобус, настанот беше валиден од гледна точка на валидаторот на апликацијата, но не беше валиден од гледна точка на PostgreSQL, бидејќи во нашиот еден систем MySQL со UNSIGNED INT, а во ново напишаното системот имаше PostgreSQL само со INT. Неговата големина е малку помала, а ИД не одговараше. Симфони умре со исклучок. Ние, се разбира, го фативме исклучокот затоа што се потпиравме на него и требаше да го извршиме ова поместување, но пред тоа сакавме да го зголемиме бројачот на проблемот, бидејќи пораката беше неуспешно обработена. Бројачите во овој проект се исто така во базата на податоци, а Symfony веќе ја затвори комуникацијата со базата на податоци, а вториот исклучок го уби целиот процес без шанса да се изврши офсет.
Службата лежеше некое време - за среќа, кај Кафка ова не е толку лошо, бидејќи пораките остануваат. Кога работата е обновена, можете да завршите со читање. Удобно е.
Кафка има способност да постави произволно поместување преку алатки. Но, за да го направите ова, треба да ги запрете сите потрошувачи - во нашиот случај, подгответе посебно издание во кое нема да има потрошувачи, прераспоредувања. Потоа во Кафка можете да го префрлите поместувањето преку алатките, и пораката ќе помине.
Друга нијанса - дневник за репликација vs rdkafka.so - е поврзана со спецификите на нашиот проект. Ние користиме PHP, а во PHP, по правило, сите библиотеки комуницираат со Кафка преку складиштето rdkafka.so, а потоа има некој вид обвивка. Можеби ова се наши лични тешкотии, но се покажа дека едноставно препрочитување на дел од она што веќе сме го прочитале не е толку лесно. Во принцип, имаше софтверски проблеми.
Враќајќи се на спецификите за работа со партиции, тоа е напишано право во документацијата потрошувачи >= партиции на тема. Но, дознав за ова многу подоцна отколку што би сакал. Ако сакате да се скалирате и да имате два потрошувачи, потребни ви се најмалку две партиции. Односно, ако сте имале една партиција во која се собрале 20 илјади пораки, а сте направиле нова, бројот на пораки нема наскоро да се изедначи. Затоа, за да имате два паралелни потрошувачи, треба да се занимавате со партиции.
Мониторинг
Мислам дека начинот на кој го следиме ќе биде уште појасно какви проблеми има во постоечкиот пристап.
На пример, пресметуваме колку производи во базата на податоци неодамна го промениле својот статус и, соодветно, настаните требало да се случат врз основа на овие промени, и го испраќаме овој број до нашиот систем за следење. Потоа од Кафка ја добиваме втората бројка, колку настани се всушност снимени. Очигледно, разликата помеѓу овие два броја секогаш треба да биде нула.
Дополнително, треба да следите како работи производителот, дали настаните-автобус добивале пораки и како работи потрошувачот. На пример, во графиконите подолу, Алатката за враќање на средствата работи добро, но BOB очигледно има некои проблеми (сини врвови).
Веќе спомнав доцнење во потрошувачките групи. Грубо кажано, ова е бројот на непрочитани пораки. Генерално, нашите потрошувачи работат брзо, така што доцнењето е обично 0, но понекогаш може да има краткорочен врв. Кафка може да го направи ова надвор од кутијата, но треба да поставите одреден интервал.
Има проект што ќе ви даде повеќе информации за Кафка. Едноставно го користи API-то на групата потрошувачи за да даде статус за тоа како работи оваа група. Покрај OK и Failed, има и предупредување, а можете да дознаете дека вашите потрошувачи не можат да се справат со темпото на производство - немаат време да го лекторираат напишаното. Системот е доста паметен и лесен за користење.
Вака изгледа одговорот на API. Еве ја групата bob-live-fifa, партиција refund.update.v1, статус ОК, заостанување 0 - последното финално офсет такво и такво.
Мониторинг updated_at SLA (заглавен) Веќе спомнав. На пример, производот е сменет во статус дека е подготвен за враќање. Го инсталираме Cron, кој вели дека ако за 5 минути овој објект не отишол на рефундирање (многу брзо враќаме пари преку платните системи), тогаш нешто дефинитивно тргна наопаку, и ова е дефинитивно случај за поддршка. Затоа, едноставно го земаме Cron, кој чита такви работи, и ако тие се поголеми од 0, тогаш испраќа предупредување.
Да резимираме, користењето настани е погодно кога:
- информациите им се потребни на неколку системи;
- резултатот од обработката не е важен;
- има малку настани или мали настани.
Се чини дека статијата има многу специфична тема - асинхрон API на Кафка, но во врска со тоа би сакал да препорачам многу работи одеднаш.
Прво, следно треба да почекаме до ноември; во април ќе има верзија на Санкт Петербург, а во јуни ќе зборуваме за високи оптоварувања во Новосибирск.
Второ, авторот на извештајот, Сергеј Заика, е член на Програмскиот комитет на нашата нова конференција за управување со знаење . Конференцијата е еднодневна, ќе се одржи на 26 април, но нејзината програма е многу интензивна.
И тоа ќе биде во мај и (со вклучен DevOpsConf) - исто така можете да ја предложите вашата тема таму, да зборувате за вашето искуство и да се жалите на вашите полнети шишарки.
Извор: www.habr.com