Опит в разработването на услугата Refund Tool с асинхронен API на Kafka

Какво може да принуди такава голяма компания като Lamoda, с рационализиран процес и десетки взаимосвързани услуги, да промени значително подхода си? Мотивацията може да бъде напълно различна: от законодателна до желанието за експериментиране, присъщо на всички програмисти.

Но това не означава, че не можете да разчитате на допълнителни предимства. Какво точно можете да спечелите, ако внедрите управлявания от събития API на Kafka, ще разкаже Сергей Заика (няколко). Определено ще се говори и за големи кадри и интересни открития - експериментът не може без тях.

Отказ от отговорност: Тази статия се основава на материали от срещата, която Сергей проведе през ноември 2018 г. в HighLoad++. Работата на Ламода на живо с Кафка привлече слушателите не по-малко от другите репортажи от програмата. Струва ни се, че това е чудесен пример за факта, че винаги е възможно и необходимо да се намерят съмишленици и организаторите на HighLoad ++ ще продължат да се опитват да създадат атмосфера, благоприятна за това.

Относно процеса

Lamoda е голяма платформа за електронна търговия, която има собствен център за контакти, служба за доставка (и много филиали), фото студио, огромен склад и всичко това работи със собствен софтуер. Има десетки методи на плащане, b2b партньори, които може да използват някои или всички от тези услуги и искат да знаят актуална информация за техните продукти. Освен това Lamoda работи в три държави освен Руската федерация и там всичко е малко по-различно. Като цяло вероятно има повече от сто начина за конфигуриране на нова поръчка, която трябва да бъде обработена по свой начин. Всичко това работи с помощта на десетки услуги, които понякога комуникират по неочевидни начини. Има и централна система, чиято основна отговорност са статусите на поръчките. Ние я наричаме BOB, аз работя с нея.

Инструмент за възстановяване на средства с API, управляван от събития

Думата, управлявана от събития, е доста изтъркана, малко по-нататък ще дефинираме по-подробно какво се има предвид под това. Ще започна с контекста, в който решихме да изпробваме управлявания от събития API подход в Kafka.

Във всеки магазин, в допълнение към поръчките, за които клиентите плащат, има моменти, когато магазинът е длъжен да върне пари, защото продуктът не отговаря на клиента. Това е относително кратък процес: изясняваме информацията, ако е необходимо, и превеждаме парите.

Но връщането стана по-сложно поради промени в законодателството и трябваше да внедрим отделна микроуслуга за него.

Нашата мотивация:

1. Закон FZ-54 - накратко, законът изисква докладване на данъчната служба за всяка парична транзакция, независимо дали е връщане или получаване, в сравнително кратко SLA от няколко минути. Ние, като електронна търговия, извършваме доста операции. Технически това означава нова отговорност (и следователно нова услуга) и подобрения във всички включени системи.
2. BOB сплит - вътрешен проект на компанията за освобождаване на BOB от голям брой неосновни отговорности и намаляване на цялостната му сложност.

Тази диаграма показва основните системи Lamoda. Сега повечето са повече съзвездие от 5-10 микроуслуги около свиващ се монолит. Те бавно растат, но ние се опитваме да ги направим по-малки, защото разполагането на фрагмент, избран в средата, е страшно - не можете да го оставите да падне. Принудени сме да запазим всички борси (стрелки) и обещаваме, че някоя от тях може да не е налична.

BOB също има доста борси: платежни системи, системи за доставка, системи за уведомяване и др.

Технически BOB е:

• ~150k реда код + ~100k реда тестове;
• php7.2 + Zend 1 & Symfony Components 3;
• >100 API & ~50 изходящи интеграции;
• 4 държави със собствена бизнес логика.

Внедряването на BOB е скъпо и болезнено, количеството код и задачите, които решава е такова, че никой не може да си го набие в главата изцяло. Като цяло има много причини да го опростите.

Процес на връщане

Първоначално в процеса участват две системи: BOB и Payment. Сега се появяват още две:

• Служба за фискализация, която ще се грижи за проблемите с фискализацията и комуникацията с външни услуги.
• Refund Tool, при който новите обмени просто се изваждат, за да не се надуе BOB.

Сега процесът изглежда така:

1. BOB получава заявка за възстановяване.
2. BOB говори за този инструмент за възстановяване.
3. Инструментът за възстановяване казва на Payment: „Върнете парите“.
4. Плащането връща парите.
5. Refund Tool и BOB си синхронизират статусите помежду си, защото засега и на двата им трябва. Все още не сме готови напълно да преминем към Refund Tool, тъй като BOB има UI, отчети за счетоводство и като цяло много данни, които не могат да бъдат прехвърлени толкова лесно. Трябва да седнете на два стола.
6. Заявката за фискализация отпада.

В резултат на това направихме определен автобус за събития на Кафка - автобус за събития, от който започна всичко. Ура, сега имаме една точка на провал (сарказъм).

Плюсовете и минусите са доста очевидни. Направихме автобус, което означава, че сега всички услуги зависят от него. Това опростява дизайна, но въвежда една точка на повреда в системата. Кафка ще се срине, процесът ще спре.

Какво представлява API, управляван от събития

Добър отговор на този въпрос е в доклада на Мартин Фаулър (GOTO 2017) „Многото значения на управляваната от събития архитектура“.

Накратко какво направихме:

1. Завършете всички асинхронни обмени чрез съхранение на събития. Вместо да информираме всеки заинтересован потребител за промяна на състоянието в мрежата, ние записваме събитие за промяна на състоянието в централизиран магазин и потребителите, интересуващи се от дадена тема, четат всичко, което се появява оттам.
2. Събитието в този случай е известие (уведомления), че нещо се е променило някъде. Например статусът на поръчката се е променил. Потребител, който се интересува от някои данни, придружаващи промяната на статуса, които не са включени в уведомлението, може сам да разбере статуса му.
3. Максималната опция е пълноценно извличане на събития, държавен трансфер, в което събитие съдържа цялата информация, необходима за обработка: откъде идва и в какъв статус е преминала, как точно са се променили данните и т.н. Единственият въпрос е осъществимостта и количеството информация, което можете да си позволите да съхранявате.

Като част от пускането на инструмента за възстановяване на средства използвахме третата опция. Това опростява обработката на събития, тъй като не е необходимо извличане на подробна информация, плюс това елиминира сценария, при който всяко ново събитие поражда вълна от заявки за търсене от потребители.

Инструмент за възстановяване на средства за услуга разтоварени, така че Кафка е по-скоро изпитание, отколкото необходимост. Не мисля, че ако услугата за възстановяване на средства се превърне в проект с голямо натоварване, бизнесът ще бъде щастлив.

Асинхронен обмен КАКВОТО Е

За асинхронен обмен PHP отделът обикновено използва RabbitMQ. Събрахме данните за заявката, поставихме я на опашка и потребителят на същата услуга я прочете и я изпрати (или не я изпрати). За самия API Lamoda активно използва Swagger. Ние проектираме API, описваме го в Swagger и генерираме клиентски и сървърен код. Ние също използваме леко подобрен JSON RPC 2.0.

На някои места се използват esb-шини, някой живее на activeMQ, но като цяло, RabbitMQ - стандартен.

Асинхронен обмен ДА БЪДЕ

При проектирането на обмен чрез шина за събития може да се проследи аналогия. По подобен начин описваме бъдещия обмен на данни чрез описания на структурата на събитията. Форматът yaml, трябваше да направим сами генерирането на код, генераторът създава DTO според спецификацията и учи клиенти и сървъри да работят с тях. Поколението върви на два езика - golang и php. Това поддържа библиотеките последователни. Генераторът е написан на golang, за което получи името gogi.

Извличането на събития за Кафка е типично нещо. Има решение от основната корпоративна версия на Kafka Confluent, има накади, решение от нашите "братя" в областта на домейна Zalando. Нашите мотивация да започнем с ванилия Кафка е да оставим решението безплатно, докато най-накрая решим дали ще го използваме навсякъде, и също така да си оставим място за маневриране и подобрения: искаме подкрепа за нашите JSON RPC 2.0, генератори за два езика и да видим какво още.

Иронично е, че дори в такъв щастлив случай, когато има подобен бизнес на Zalando, който е създал подобно решение, ние не можем да го използваме ефективно.

Архитектурно, при стартиране, моделът е следният: ние четем директно от Kafka, но пишем само през шина за събития. В Kafka има много готови неща за четене: брокери, балансьори и е горе-долу готов за хоризонтално мащабиране, исках да го запазя. Рекордът е, че искахме да преминем през един Gateway, известен още като Events-bus, и ето защо.

Събития-авт

Или автобус за събития. Това е просто http шлюз без състояние, който изпълнява няколко важни роли:

• Произвеждане на валидиране - проверете дали събитията отговарят на нашата спецификация.
• Мастер система по събития, тоест това е основната и единствена система в компанията, която отговаря на въпроса кои събития с какви структури се считат за валидни. Валидирането е само типове данни и enums за строга спецификация на съдържанието.
• хеш функция за шардинг - структурата на съобщението Kafka е ключ-стойност и с помощта на хеша на ключа се изчислява къде да се постави.

Защо

Работим в голяма компания с рационализиран процес. Защо да променя нещо? Това е експерименти очакваме да получим няколко предимства.

1:n+1 обмен (един към много)

С Kafka е много лесно да свържете нови потребители към API.

Да приемем, че имате директория, която трябва да се поддържа актуална в няколко системи едновременно (и в някои нови). Преди това изобретихме пакет, който внедрява set-API, и адресът на потребителите беше докладван на главната система. Сега главната система изпраща актуализации на темата и всеки, който се интересува, чете. Появи се нова система - подписаха я по темата. Да, също пакет, но по-прост.

В случай на refund-tool, който е част от BOB, за нас е удобно да ги поддържаме синхронизирани чрез Kafka. Плащането казва, че парите са върнати: BOB, RT разбраха за това, промениха статусите си, службата за фискализация разбра за това и издаде чек.

Имаме планове да направим единна услуга за известия, която да уведомява клиента за новостите по неговата поръчка/връщане. Сега тази отговорност е разпределена между системите. За нас ще бъде достатъчно да научим услугата за известия да улавя подходяща информация от Kafka и да отговаря на нея (и да деактивираме тези известия в други системи). Няма да са необходими нови директни обмени.

Управлявани от данни

Информацията между системите става прозрачна - без значение какво „кърваво предприятие“ имате и без значение колко голямо е вашето изоставане. Lamoda има отдел за анализ на данни, който събира данни от системи и ги поставя във форма за многократна употреба, както за бизнеса, така и за интелигентни системи. Kafka ви позволява бързо да им предоставите много данни и да поддържате този информационен поток актуален.

Дневник на репликация

Съобщенията не изчезват, след като бъдат прочетени, както в RabbitMQ. Когато дадено събитие съдържа достатъчно информация за обработка, имаме история на последните промени в обекта и, ако желаем, възможност за прилагане на тези промени.

Периодът на съхранение на регистрационния файл за репликация зависи от интензивността на писане в тази тема, Kafka ви позволява гъвкаво да задавате ограничения за времето за съхранение и обема на данните. За интензивни теми е важно всички потребители да имат време да прочетат информацията, преди тя да изчезне, дори в случай на краткотрайна неработоспособност. Обикновено е възможно да се съхраняват данни за единици дни, което е напълно достатъчно за опора.

Освен това, малко преразказ на документацията, за тези, които не са запознати с Кафка (снимката също е от документацията)

В AMQP има опашки: ние пишем съобщения на опашката за потребителя. По правило една система обработва една опашка с една и съща бизнес логика. Ако трябва да уведомите няколко системи, можете да научите приложението да пише в няколко опашки или да настроите обмен с механизъм за разклоняване, който ги клонира.

Кафка има подобна абстракция тема, в който пишете съобщения, но те не изчезват след прочитане. По подразбиране, когато се свържете с Kafka, получавате всички съобщения и имате опцията да запазите там, където сте спрели. Тоест, четете последователно, не можете да маркирате съобщението като прочетено, но да запазите id, от който можете да продължите да четете по-късно. Идентификационният номер, на който сте спрели, се нарича отместване (отместване), а механизмът се нарича отместване на ангажимент.

Съответно може да се приложи различна логика. Например, имаме BOB в 4 инстанции за различни държави - Lamoda е в Русия, Казахстан, Украйна, Беларус. Тъй като те се разполагат отделно, те имат малко свои собствени конфигурации и собствена бизнес логика. В съобщението посочваме за коя държава се отнася. Всеки потребител на BOB във всяка държава чете с различен groupId и ако съобщението не се отнася за него, го пропускат, т.е. незабавно ангажирайте отместване +1. Ако една и съща тема се чете от нашата Платежна услуга, тя прави това с отделна група и следователно компенсациите не се пресичат.

Изисквания за събитието:

• Пълнота на данните. Бих искал събитието да има достатъчно данни, за да може да бъде обработено.

• Почтеност. Делегираме на Events-bus проверката дали събитието е последователно и дали може да се справи с него.
• Редът е важен. В случай на връщане сме принудени да работим с историята. При известията поръчката не е важна, ако са хомогенни известия, имейлът ще бъде един и същ, независимо коя поръчка е пристигнала първа. В случай на възстановяване на средства има ясен процес; ако променим поръчката, ще възникнат изключения, възстановяването няма да бъде създадено или обработено - ще се окажем в различен статус.
• Последователност. Имаме магазин и сега създаваме събития вместо API. Имаме нужда от начин за бързо и евтино предаване на информация за нови събития и промени в съществуващи към нашите услуги. Това се постига чрез обща спецификация в отделно git хранилище и генератори на код. Следователно клиентите и сървърите в различни услуги са координирани.

Кафка в Ламода

Имаме три инсталации на Kafka:

1. трупи;
2. R&D;
3. Събития-авт.

Днес говорим само за последната точка. В event-bus нямаме много големи инсталации - 3 брокера (сървъри) и само 27 теми. По правило една тема е един процес. Но това е тънък момент и сега ще се докоснем до него.

По-горе е диаграмата на rps. Процесът на възстановяване на средства е маркиран с тюркоазена линия (да, тази по оста x), а розов е процесът на актуализиране на съдържанието.

Каталогът на Lamoda съдържа милиони продукти, като данните се актуализират през цялото време. Някои колекции излизат от мода, на тяхно място се пускат нови, в каталога постоянно се появяват нови модели. Опитваме се да предвидим от какво ще се интересуват нашите клиенти утре, затова непрекъснато купуваме нови неща, снимаме ги и актуализираме витрината.

Розовите пикове са продуктови актуализации, т.е. продуктови промени. Вижда се, че момчетата снимаха, снимаха и пак! — зареди пакет от събития.

Случаи на използване на Lamoda Events

Ние използваме изградената архитектура за следните операции:

• Проследяване на статуса на връщане: призив за действие и проследяване на състоянието от всички включени системи. Плащане, статуси, фискализация, известия. Тук тествахме подхода, направихме инструменти, събрахме всички грешки, написахме документация и казахме на колегите как да я използват.
• Актуализация на продуктови карти: конфигурация, метаданни, характеристики. Една система чете (която показва), а няколко пишат.
• Имейл, push и sms: поръчката е сглобена, поръчката е пристигнала, връщането е прието и т.н., има много от тях.
• Складова наличност, обновяване на склада — количествена актуализация на артикулите, само номера: пристигане в склада, връщане. Необходимо е всички системи, свързани с резервирането на стоки, да работят с най-актуалните данни. В момента системата за актуализиране на запасите е доста сложна; Kafka ще я опрости.
• Анализ на данни (R&D отдел), ML инструменти, анализи, статистика. Искаме информацията да е прозрачна - Кафка е много подходящ за това.

Сега по-интересната част за пълнените неравности и интересни открития, които се случиха за шест месеца.

Проблеми с дизайна

Да кажем, че искаме да направим нещо ново – например да прехвърлим целия процес на доставка на Kafka. Сега част от процеса е внедрена в обработка на поръчки в BOB. Зад прехвърлянето на поръчката към службата за доставка, преместването в междинния склад и т.н., има модел на статус. Има цял монолит, дори два, плюс куп API, посветени на доставката. Те знаят много повече за доставката.

Изглежда, че това са подобни области, но обработката на поръчки в BOB и системата за доставка имат различни статуси. Например, някои куриерски услуги не изпращат междинни статуси, а само крайните: „доставено“ или „загубено“. Други, напротив, докладват много подробно за движението на стоките. Всеки има свои собствени правила за проверка: за някои имейлът е валиден, което означава, че ще бъде обработен; за други не важи, но поръчката все пак ще бъде обработена, защото има телефон за връзка, и някой ще каже, че такава поръчка изобщо няма да бъде обработена.

Поток от данни

В случая с Кафка възниква въпросът за организирането на потока от данни. Тази задача е свързана с избора на стратегия по няколко точки, нека да ги разгледаме всички.

В една тема или в различни?

Имаме спецификация на събитието. В BOB пишем, че трябва да се достави такава и такава поръчка и посочваме: номера на поръчката, нейния състав, някои SKU и баркодове и др. Когато стоките пристигнат в склада, доставката ще може да получи статуси, времеви марки и всичко необходимо. Но след това искаме да получаваме актуализации на тези данни в BOB. Имаме обратен процес на получаване на данни от доставката. Това същото събитие ли е? Или това е отделна борса, която си заслужава отделна тема?

Най-вероятно те ще бъдат много сходни и изкушението да се направи една тема не е неоснователно, защото отделна тема означава отделни потребители, отделни конфигурации, отделно генериране на всичко това. Но не е факт.

Ново поле или ново събитие?

Но ако използвате същите събития, тогава възниква друг проблем. Например, не всички системи за доставка могат да генерират DTO, който може да генерира BOB. Изпращаме им id, но те не ги записват, защото не им трябват и от гледна точка на стартиране на процеса на event-bus това поле е задължително.

Ако въведем правило за шина за събития, че това поле е задължително, тогава сме принудени да зададем допълнителни правила за валидиране в BOB или в манипулатора на стартови събития. Валидирането започва да се разпространява в цялата услуга - това не е много удобно.

Друг проблем е изкушението за постепенно развитие. Казват ни, че трябва да добавим нещо към събитието и може би, ако помислим внимателно, това трябва да е отделно събитие. Но в нашата схема отделно събитие е отделна тема. Отделна тема е целият процес, който описах по-горе. Разработчикът се изкушава просто да добави още едно поле към JSON схемата и да го генерира отново.

В случай на възстановяване на средства, ние пристигнахме на събитието след половин година. Имахме едно мета събитие, наречено актуализация за възстановяване, което имаше поле за тип, описващо какво всъщност представлява тази актуализация. От това имахме „красиви“ превключватели с валидатори, които казваха как да валидираме това събитие с този тип.

Версии на събития

За да потвърдите съобщения в Kafka, можете да използвате Avro, но беше необходимо веднага да легна върху него и да използвам Confluent. В нашия случай трябва да внимаваме с версиите. Не винаги ще е възможно да се препрочитат съобщения от регистрационния файл на репликация, защото моделът е "напуснал". По принцип се оказва, че се изграждат версии, така че моделът да е обратно съвместим: например, направете поле временно незадължително. Ако разликите са твърде големи, започваме да пишем в нова тема, а клиентите се трансплантират, когато прочетат старата.

Гаранция за поръчка за четене на дялове

Темите в Кафка са разделени на дялове. Това не е много важно, докато проектираме обекти и борси, но е важно, когато решаваме как да го консумираме и мащабираме.

В нормалния случай пишете една тема на Кафка. По подразбиране се използва един дял и всички съобщения от тази тема попадат в него. И потребителят чете тези съобщения последователно, съответно. Да речем, че сега трябва да разширим системата, така че съобщенията да се четат от два различни потребителя. Ако например изпратите SMS, тогава можете да кажете на Kafka да направи допълнително разделение и Kafka ще започне да разлага съобщенията на две части - половината там, половината там.

Как ги разделя Кафка? Всяко съобщение има тяло (в което съхраняваме JSON) и ключ. Можете да прикачите хеш функция към този ключ, която ще определи в кой дял ще влезе съобщението.

В нашия случай с възстановяване на средства, това е важно, ако вземем две части, тогава има шанс паралелният потребител да обработи второто събитие преди първото и ще има проблеми. Функцията за хеширане гарантира, че съобщенията с един и същ ключ завършват в един и същи дял.

Събития срещу команди

Това е друг проблем, който срещнахме. Събитието е определено събитие: казваме, че нещо се е случило някъде (something_happened), например даден артикул е бил отменен или е настъпило възстановяване на сумата. Ако някой прослуша тези събития, тогава според „отменен артикул“ ще бъде създаден субектът за възстановяване и някъде в настройките ще бъде написано „възстановяване на средства“.

Но обикновено, когато проектирате събития, не искате да ги пишете напразно - залагате, че някой ще ги прочете. Голямо е изкушението да не напишете нещо_се е случило (артикул_отменен, възстановена_рефундация), а нещо_трябва_да_се_направи. Например артикулът е готов за връщане.

От една страна подсказва как ще се използва събитието. От друга страна, това е много по-малко като нормално име на събитие. Освен това оттук не е далеч от командата do_something. Но нямате гаранция, че някой е прочел това събитие; и ако чете, значи чете успешно; и ако е чел успешно, значи е направил нещо и това нещо е било успешно. В момента, в който едно събитие стане do_something, обратната връзка става необходима и това е проблемът.

При асинхронен обмен в RabbitMQ, когато прочетете съобщението, отидете на http, имате отговор - поне че съобщението е получено. Когато пишете на Кафка, има съобщение, което сте написали на Кафка, но не знаете нищо за това как е обработено.

Следователно в нашия случай трябваше да въведем събитие за отговор и да настроим мониторинг, така че ако са изпратени толкова много събития, след такова и такова време да пристигнат същия брой събития за отговор. Ако това не се случи, значи нещо изглежда се е объркало. Например, ако сме изпратили събитието „item_ready_to_refund“, очакваме, че ще бъде създадено възстановяване, парите ще бъдат върнати на клиента и събитието „money_refunded“ ще бъде изпратено до нас. Но това не е сигурно, така че е необходимо наблюдение.

нюанси

Има доста очевиден проблем: ако четете от една тема последователно и имате някакво лошо послание, потребителят ще падне и няма да стигнете по-нататък. имате нужда спрете всички потребители, ангажирайте компенсиране по-нататък, за да продължите да четете.

Знаехме за това, разчитахме на това и въпреки това се случи. И това се случи, защото събитието беше валидно от гледна точка на event-bus, събитието беше валидно от гледна точка на валидатора на приложението, но не беше валидно от гледна точка на PostgreSQL, защото в нашата система MySQL с UNSIGNED INT системата имаше PostgreSQL само с INT. Размерът му е малко по-малък и идентификаторът не пасва. Symfony умря с изключение. Ние, разбира се, хванахме изключението, защото разчитахме на него и щяхме да извършим това отместване, но преди това искахме да увеличим брояча на проблемите, тъй като съобщението беше обработено неуспешно. Броячите в този проект също са в базата данни и Symfony вече затвори комуникацията с базата данни и второто изключение уби целия процес без шанс да извърши компенсиране.

За известно време услугата легна - за щастие, с Кафка това не е толкова страшно, защото съобщенията остават. Когато работата бъде възстановена, те могат да бъдат прочетени. Удобно е.

Kafka има способността да зададе произволно отместване чрез инструменти. Но за да направите това, трябва да спрете всички потребители - в нашия случай, подгответе отделно издание, в което няма да има потребители, пренасочвания. Тогава Кафка може да измести отместването чрез инструменти и съобщението ще премине.

Друг нюанс - регистрационен файл за репликация срещу rdkafka.so - свързани със спецификата на нашия проект. Имаме PHP, а в PHP по правило всички библиотеки комуникират с Kafka чрез хранилището rdkafka.so и след това има някакъв вид обвивка. Може би това са наши лични трудности, но се оказа, че просто препрочитането на вече прочетеното не е толкова лесно. Като цяло имаше софтуерни проблеми.

Връщайки се към особеностите на работа с дялове, точно в документацията пише потребители >= дялове на теми. Но разбрах за това много по-късно, отколкото бих искал. Ако искате да мащабирате и да имате два консуматора, имате нужда от поне два дяла. Тоест, ако сте имали един дял, в който са се натрупали 20 хиляди съобщения и сте направили нов, броят на съобщенията няма да се изравни скоро. Следователно, за да имате два паралелни консуматора, трябва да се справите с дялове.

мониторинг

Мисля, че по начина, по който го наблюдаваме, ще стане още по-ясно какви проблеми има в съществуващия подход.

Например, ние преброяваме колко продукта в базата данни наскоро са променили статуса си и съответно трябва да са се случили събития при тези промени и изпращаме това число на нашата система за наблюдение. Тогава от Кафка получаваме второто число, колко събития всъщност са регистрирани. Очевидно разликата между тези две числа винаги трябва да е нула.

Освен това трябва да наблюдавате как се справя производителят, дали автобусът за събития е получил съобщения и как се справя потребителят. Например, в диаграмите по-долу, Refund Tool се справя добре, но BOB очевидно има някои проблеми (сини пикове).

Вече споменах изоставането на потребителската група. Грубо казано, това е броят на непрочетените съобщения. Като цяло нашите потребители работят бързо, така че забавянето обикновено е 0, но понякога може да има краткосрочен пик. Kafka може да направи това извън кутията, но трябва да зададете определен интервал.

Има проект ровя, което ще ви даде повече информация за Кафка. Той просто дава статуса чрез API на потребителската група, както прави тази група. В допълнение към OK и Failed там има предупреждение и можете да разберете, че вашите потребители не могат да се справят с темпото на производство - те нямат време да коригират написаното. Системата е доста умна и лесна за използване.

Ето как изглежда отговорът на API. Тук групата bob-live-fifa, дял refund.update.v1, OK състояние, лаг 0 е последното крайно отместване такова и такова.

мониторинг updated_at SLA (заседнал) Вече споменах. Например артикулът е преминал в състояние, че е готов за връщане. Настроихме Cron, който казва, че ако този обект не бъде върнат за възстановяване след 5 минути (ние връщаме пари чрез платежни системи много бързо), тогава нещо определено се е объркало и това определено е случай за поддръжка. Затова просто вземаме Cron, който чете такива неща и ако са по-големи от 0, тогава изпраща предупреждение.

За да обобщим, използването на събития е удобно, когато:

• информацията е необходима на няколко системи;
• резултатът от обработката не е важен;
• малко или никакви събития.

Изглежда, че статията има много специфична тема - асинхронен API на Kafka, но във връзка с нея бих искал веднага да препоръчам много неща.
Първо, следващо HighLoad ++ но трябва да изчакате до ноември, през април ще има неговата версия в Санкт Петербург, а през юни ще говорим за високи натоварвания в Новосибирск.
Второ, авторът на доклада Сергей Заика е член на програмния комитет на нашата нова конференция за управление на знанието KnowledgeConf. Конференцията е еднодневна, ще се проведе на 26 април, но програмата й е много наситена.
И през май ще бъде PHP Русия и RIT++ (с DevOpsConf като част) - там можете също да предложите вашата тема, да говорите за опита си и да се оплачете от вашите пълнени неравности.

Източник: www.habr.com