Како да престанете да се грижите и да почнете да живеете без монолит

Сите сакаме приказни. Сакаме да седиме околу огнот и да разговараме за нашите минати победи, битки или едноставно за нашето работно искуство.

Денес е токму таков ден. И дури и ако не сте на огнот во моментов, имаме приказна за вас. Приказната за тоа како почнавме да работиме со складирање на Tarantool.

Некогаш нашата компанија имаше неколку „монолити“ и еден „таван“ за сите, кон кои полека но сигурно се приближуваа овие монолити, ограничувајќи го летот на нашата компанија, нашиот развој. И имаше јасно разбирање: еден ден силно ќе го удриме овој плафон.

Сега преовладува идеологијата за одвојување на се и секого, од опрема до деловна логика. Како резултат на тоа, ние, на пример, имаме два DC кои се практично независни на ниво на мрежа. И тогаш сè беше сосема поинаку.

Денес, постојат многу алатки и алатки за правење промени во форма на CI/CD, K8S итн. Во „монолитно“ време не ни требаа толку многу странски зборови. Доволно беше едноставно да се поправи „складирањето“ во базата на податоци.

Но, времето се движеше напред, а бројот на барања се движеше напред заедно со него, понекогаш снимајќи RPS надвор од нашите можности. Со влегувањето на земјите од ЗНД на пазарот, оптоварувањето на процесорот на базата на податоци на првиот монолит не падна под 90%, а RPS остана на ниво од 2400. И тоа не беа само мали селектори, туку големи прашања со куп проверки и ПРИКЛУЧУВАЊА кои би можеле да работат речиси за половина од податоците наспроти позадината на големите IO.

Кога на сцената почнаа да се појавуваат полноправни продажби на црниот петок - а Wildberries беше еден од првите што ги одржа во Русија - ситуацијата стана целосно тажна. На крајот на краиштата, товарот во такви денови се зголемува три пати.
О, овие „монолитни времиња“! Сигурен сум дека сте доживеале нешто слично и сè уште не можете да разберете како тоа може да ви се случи.

Што можете да направите - модата е вродена во технологијата. Пред околу 5 години, моравме да размислиме за еден од овие модови во форма на постоечка страница на .NET и MS SQL серверот, кој внимателно ја складираше целата логика на самата страница. Го чував толку внимателно што пилањето на таков монолит се покажа како долго и воопшто не лесно задоволство.
Мала дигресија.

На разни настани велам: „ако не сте виделе монолит, тогаш не сте пораснале! Ме интересира вашето мислење за ова прашање, ве молиме напишете го во коментарите.

Звук на громот

Да се ​​вратиме на нашиот „оган“. За да го дистрибуираме оптоварувањето на „монолитна“ функционалност, решивме да го поделиме системот на микроуслуги базирани на технологии со отворен код. Бидејќи, во најмала рака, тие се поевтини за размер. И имавме 100% разбирање дека ќе треба да скалираме (и тоа многу). На крајот на краиштата, веќе во тоа време беше можно да се влезе на пазарите на соседните земји, а бројот на регистрации, како и бројот на нарачки, почнаа да растат уште посилно.

Откако ги анализиравме првите кандидати за заминување од монолитот кон микросервисите, сфативме дека 80% од пишувањето во нив доаѓа од back office системи, а читањето од предната канцеларија. Пред сè, ова се однесуваше на неколку важни потсистеми за нас - кориснички податоци и систем за пресметување на крајната цена на стоката врз основа на информации за дополнителни попусти на клиентите и купони.

Вовлечен. Сега е страшно да се замисли, но покрај горенаведените потсистеми, од нашиот монолит беа отстранети и каталози на производи, корисничка количка, систем за пребарување производи, систем за филтрирање за каталози на производи и разни видови системи за препораки. За работата на секој од нив, постојат посебни класи на тесно приспособени системи, но некогаш сите тие живееле во една „куќа“.

Веднаш планиравме да префрлиме податоци за нашите клиенти во системот за распарчување. Отстранувањето на функционалноста за пресметување на крајната цена на стоката бараше добра приспособливост за читање, бидејќи создаде најголемо оптоварување на RPS и беше најтешко да се имплементира за базата на податоци (многу податоци се вклучени во процесот на пресметка).

Како резултат на тоа, дојдовме до шема која добро се вклопува со Tarantool.

Во тоа време, за работа на микросервиси, беа избрани шеми за работа со неколку центри за податоци на виртуелни и хардверски машини. Како што е прикажано на сликите, опциите за репликација на Tarantool беа применети и во режимите master-master и master-slave.

Архитектура. Опција 1. Корисничка услуга

Во моментот, има 24 фрагменти, од кои секоја има 2 примероци (по еден за секој DC), сите во режим на мајстор-мајстор.

На врвот на базата на податоци се апликациите кои пристапуваат до репликите на базата на податоци. Апликациите работат со Tarantool преку нашата сопствена библиотека, која го имплементира интерфејсот за двигател Tarantool Go. Таа ги гледа сите реплики и може да работи со мајсторот за да чита и пишува. Во суштина, тој го имплементира моделот на множество реплика, кој додава логика за избор на реплики, повторување на обидите, прекинувач и ограничување на брзината.

Во овој случај, можно е да се конфигурира политиката за избор на реплика во контекст на фрагменти. На пример, roundrobin.

Архитектура. Опција 2. Услуга за пресметување на крајниот трошок на стоката

Пред неколку месеци најголем дел од барањата за пресметување на крајниот трошок на стоката отидоа во нова услуга, која во принцип работи без бази на податоци, но пред извесно време сè беше обработено 100% од сервис со Tarantool под капакот.

Базата на податоци за услуги се состои од 4 мајстори во кои синхронизаторот собира податоци, и секој од овие мајстори за репликација дистрибуира податоци на реплики само за читање. Секој мајстор има приближно 15 такви реплики.

Или во првата или во втората шема, ако еден DC е недостапен, апликацијата може да прима податоци во втората.

Вреди да се напомене дека репликацијата во Tarantool е прилично флексибилна и може да се конфигурира при извршување. Во други системи, се појавија тешкотии. На пример, менувањето на параметрите max_wal_senders и max_replication_slots во PostgreSQL бара рестартирање на волшебникот, што во некои случаи може да доведе до прекинување на врските помеѓу апликацијата и DBMS.

Барај и ќе најдеш!

Зошто не го направивме тоа „како нормални луѓе“, туку избравме нетипичен начин? Зависи од тоа што се смета за нормално. Многумина генерално прават кластер од Монго и го шират низ три гео-дистрибуирани DC.

Во тоа време веќе имавме два проекта на Редис. Првиот беше кеш, а вториот беше постојано складирање за не премногу критични податоци. Беше доста тешко со него, делумно и по наша вина. Понекогаш доста големи томови беа во клучот, а од време на време страницата се влошуваше. Овој систем го користевме во верзијата master-slave. И имаше многу случаи кога нешто се случи со мајсторот и репликацијата се расипа.

Односно, Редис е добар за задачи без државјанство, а не за државнички. Во принцип, дозволуваше решавање на повеќето проблеми, но само ако тие беа решенија со клучна вредност со пар индекси. Но Редис во тоа време беше доста тажен со упорност и реплицирање. Покрај тоа, имаше поплаки за перформансите.

Размислувавме за MySQL и PostgreSQL. Но, првиот некако не ни се најде, а вториот е прилично софистициран производ сам по себе и би било несоодветно да се градат едноставни услуги на него.
Пробавме RIAK, Cassandra, дури и база на податоци за графикони. Сите овие се прилично ниши решенија кои не беа погодни за улогата на општа универзална алатка за создавање услуги.

На крајот се населивме на Тарантул.

Се свртевме кон него кога беше во верзија 1.6. Нас нè интересираше симбиозата на клучот-вредноста и функционалноста на релациската база на податоци. Има секундарни индекси, трансакции и празни места, тоа се како табели, но не се едноставни, можете да складирате различни броеви на колони во нив. Но, убиствената карактеристика на Tarantool беа секундарните индекси во комбинација со клучната вредност и трансакциската состојба.

Одговорната заедница што зборува руски, подготвена да помогне во разговорот, исто така одигра улога. Активно го користевме ова и живееме директно во разговорот. И не заборавајте за пристојно упорно без очигледни грешки и грешки. Ако ја погледнете нашата историја со Tarantool, имавме многу болки и неуспеси со репликацијата, но никогаш не изгубивме податоци поради негова вина!

Имплементацијата започна грубо

Во тоа време, нашиот главен стек за развој беше .NET, на кој немаше конектор за Tarantool. Веднаш почнавме да правиме нешто во Го. Добро функционираше и со Луа. Главниот проблем во тоа време беше со дебагирањето: во .NET сè е одлично со ова, но после тоа беше тешко да се фрлам во светот на вградената Луа, кога немате дебагирање освен логови. Покрај тоа, поради некоја причина репликацијата периодично се распаѓаше, па морав да истражувам во структурата на моторот Tarantool. Разговорот помогна со ова, а во помала мера и документацијата понекогаш ја разгледувавме шифрата. Во тоа време документацијата беше така-така.

Така, во текот на неколку месеци, успеав да се вратам наоколу и да добијам пристојни резултати од работата со Tarantool. Собравме референтни случувања во git кои помогнаа во формирањето на нови микросервиси. На пример, кога се појави задача: да се создаде друга микросервис, развивачот го погледна изворниот код на референтното решение во складиштето и не требаше повеќе од една недела да се создаде нов.

Ова беа посебни времиња. Конвенционално, тогаш можете да отидете кај администраторот на следната маса и да прашате: „Дајте ми виртуелна машина“. Околу триесет минути подоцна автомобилот веќе беше со вас. Сами се поврзавте, инсталиравте се, а сообраќајот ви беше испратен.

Денес ова повеќе нема да работи: треба да додадете мониторинг и најавување на услугата, да ја покриете функционалноста со тестови, да нарачате виртуелна машина или испорака до Kuber итн. Во принцип, вака ќе биде подобро, иако ќе потрае подолго и ќе биде попроблематично.

Раздели па владеј. Што е работата со Луа?

Имаше сериозна дилема: некои тимови не можеа со сигурност да ги применат промените на услугата со многу логика во Луа. Ова често беше придружено со неработење на услугата.

Односно, програмерите подготвуваат некаква промена. Tarantool започнува со миграција, но репликата е сè уште со старата шифра; Некој DDL или нешто друго пристигнува таму преку репликација, а кодот едноставно се распаѓа затоа што не се зема предвид. Како резултат на тоа, постапката за ажурирање на администраторите беше поставена на лист А4: запрете ја репликацијата, ажурирајте го ова, вклучете репликација, исклучете овде, ажурирајте таму. Кошмар!

Како резултат на тоа, сега најчесто се обидуваме да не направиме ништо во Луа. Само користете iproto (бинарен протокол за интеракција со серверот), и тоа е тоа. Можеби ова е недостаток на знаење кај програмерите, но од оваа гледна точка системот е сложен.

Не секогаш слепо го следиме ова сценарио. Денес немаме црно-бело: или сè е во Луа, или сè е во Го. Веќе разбираме како можеме да ги комбинираме за да не завршиме со проблеми со миграцијата подоцна.

Каде е сега Tarantool?
Tarantool се користи во услугата за пресметување на крајната цена на стоката земајќи ги предвид купоните за попуст, познат и како „Промотор“. Како што реков претходно, тој сега оди во пензија: го заменува нова каталошка услуга со однапред пресметани цени, но пред шест месеци сите пресметки беа направени во Промотизер. Претходно, половина од неговата логика беше напишана на Луа. Пред две години, услугата беше претворена во складиште, а логиката беше препишана во Го, бидејќи механиката на попустите беше малку променета и на услугата недостасуваа перформанси.

Една од најкритичните услуги е корисничкиот профил. Односно, сите корисници на Wildberries се складирани во Tarantool, а има околу 50 милиони од нив.
Според RPS, Promoter некогаш бил лидер, достигнувајќи 6 илјади барања. Во еден момент имавме 50-60 примероци. Сега лидер во RPS се корисничките профили, околу 12 илјади Оваа услуга користи прилагодено споделување, поделено со опсег на кориснички идентификатори. Сервисот опслужува повеќе од 20 машини, но ова е премногу, планираме да ги намалиме доделените ресурси, бидејќи капацитетот од 4-5 машини е доволен.

Сесиската услуга е нашата прва услуга на vshard и Cartridge. Поставувањето на vshard и ажурирањето на кертриџот бараше одреден напор од нас, но на крајот сè успеа.

Услугата за прикажување различни банери на веб-страницата и во мобилната апликација беше една од првите што беше објавена директно на Tarantool. Оваа услуга е забележлива по тоа што е стара 6-7 години, сè уште е во функција и никогаш не била рестартирана. Користена е мастер-мајстор репликација. Ништо никогаш не се скрши.

Има пример за користење на Tarantool за брза референтна функционалност во магацински систем за брза двојна проверка на информациите во некои случаи. Се обидовме да користиме Redis за ова, но податоците во меморијата заземаа повеќе простор од Tarantool.

Со Tarantool работат и услугите на листа на чекање, претплати на клиенти, моментално модерни приказни и одложени стоки. Последната услуга во меморијата зафаќа околу 120 GB. Ова е најсеопфатната услуга од горенаведеното.

Заклучок

Благодарение на секундарните индекси во комбинација со клучната вредност и трансакциската способност, Tarantool е добро прилагоден за архитектури базирани на микроуслуги. Сепак, наидовме на потешкотии при објавувањето на промените на услугите со многу логика во Луа - услугите често престанаа да работат. Не можевме да го надминеме ова и со текот на времето дојдовме до различни комбинации на Луа и Гоу: знаеме каде да користиме еден јазик, а каде друг.

Што друго да се прочита на темата

• Создавање апликација со големо оптоварување од нула користејќи Tarantool habr.com/ru/company/mailru/blog/510440
• Избор на доверлив лидер во кертриџот Tarantool habr.com/ru/company/mailru/blog/513912
• Телеграмски канал Tarantool со вести за производот t.me/tarantool_news
• Разговарајте за Tarantool во разговорот во заедницата t.me/tarantoolru

Извор: www.habr.com