Кадър от филма „Нашата тайна вселена: Скритият живот на клетката“

Инвестиционният бизнес е една от най-сложните области в банковия свят, защото има не само заеми, заеми и депозити, но и ценни книжа, валути, стоки, деривати и всякакви сложности под формата на структурирани продукти.

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

В допълнение, нуждите на регулаторите, както руски, така и чуждестранни, нарастват.

За да отговорим на настоящите нужди и да поставим основата за бъдещи надстройки, ние разработихме инвестиционно бизнес ядро, базирано на Tarantool.

Малко статистики. Инвестиционният бизнес на Alfa-Bank предоставя брокерски услуги за физически и юридически лица за предоставяне на възможност за търговия на различни пазари на ценни книжа, депозитарни услуги за съхранение на ценни книжа, услуги за доверително управление за лица с частен и голям капитал, услуги за издаване на ценни книжа за други компании . Инвестиционният бизнес на Alfa-Bank включва повече от 3 хиляди котировки в секунда, които се изтеглят от различни платформи за търговия. През работния ден на пазарите се сключват над 300 хиляди сделки от името на банката или нейни клиенти. До 5 хиляди изпълнения на поръчки в секунда се случват на външни и вътрешни платформи. В същото време всички клиенти, вътрешни и външни, искат да виждат своите позиции в реално време.

праистория

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

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

Изисквания за ново решение

Бизнесът осъзна, че технологичната трансформация е жизненоважна за по-нататъшното развитие. Дадоха ни задачи:

1. Съберете всички бизнес данни в едно бързо хранилище и в един модел на данни.
2. Не трябва да губим или променяме тази информация.
3. Налага се версия на данните, тъй като във всеки един момент регулаторът може да поиска статистика за минали години.
4. Трябва не просто да донесем някакви нови, модерни СУБД, а да създадем платформа за решаване на бизнес проблеми.

В допълнение, нашите архитекти поставят свои собствени условия:

1. Новото решение трябва да е от корпоративния клас, тоест вече да е тествано в някои големи компании.
2. Режимът на работа на решението трябва да е критичен за мисията. Това означава, че трябва да присъстваме в няколко центъра за данни едновременно и спокойно да преживеем прекъсването на един център за данни.
3. Системата трябва да бъде хоризонтално мащабируема. Факт е, че всички наши настоящи системи са само вертикално мащабируеми и вече достигаме тавана поради ниския растеж на хардуерната мощност. Следователно дойде моментът, в който трябва да имаме хоризонтално мащабируема система, за да оцелеем.
4. Освен всичко друго ни казаха, че решението трябва да е евтино.

Следвахме стандартния маршрут: формулирахме изискванията и се свързахме с отдела за покупки. Оттам получихме списък с компании, които като цяло са готови да направят това за нас. Разказахме на всички за проблема и получихме оценка на решенията от шест от тях.

В банката не вярваме на ничия дума за това; обичаме да тестваме всичко сами. Затова задължително условие на конкурса ни беше преминаването на товарни тестове. Ние формулирахме задачи за тестване на натоварване и три от шест компании вече се съгласиха да внедрят прототипно решение, базирано на технологии в паметта, за своя сметка, за да го тестват.

Няма да ви казвам как тествахме всичко и колко време отне, просто ще обобщя: най-доброто представяне при тестовете за натоварване беше показано от прототипно решение, базирано на Tarantool от екипа за разработка на Mail.ru Group. Подписахме споразумение и започнахме разработката. Имаше четирима души от Mail.ru Group, а от Alfa-Bank имаше трима разработчици, трима системни анализатори, архитект на решение, собственик на продукт и Scrum master.

След това ще ви разкажа как нашата система израсна, как се разви, какво направихме и защо точно това.

дизайн

Първият въпрос, който си зададохме, беше как да получим данни от настоящите ни системи. Решихме, че HTTP е доста подходящ за нас, тъй като всички текущи системи комуникират помежду си чрез изпращане на XML или JSON през HTTP.

Използваме HTTP сървъра, вграден в Tarantool, защото не е необходимо да прекъсваме SSL сесиите и неговата производителност ни е достатъчна.

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

След конвертирането данните трябва да бъдат проверени за съответствие с модела, който създаваме. Дълго обсъждахме какъв да бъде моделът и на какъв език да го опишем. Избрахме Apache Avro, защото езикът е прост и има поддръжка от Tarantool. Новите версии на модела и персонализирания код могат да бъдат пуснати в експлоатация няколко пъти на ден, дори под натоварване или без, по всяко време на деня и да се адаптират към промените много бързо.

След проверката данните трябва да бъдат запазени. Правим това с помощта на vshard (имаме гео-разпръснати копия на фрагменти).

Освен това спецификата е такава, че повечето системи, които ни изпращат данни, не се интересуват дали сме ги получили или не. Ето защо въведохме опашка за ремонт от самото начало. Какво е? Ако по някаква причина даден обект не претърпи трансформация на данни или проверка, ние все още потвърждаваме получаването, но в същото време запазваме обекта в опашката за поправка. Той е последователен и се намира в основния склад за бизнес данни. Веднага написахме администраторски интерфейс за него, различни показатели и сигнали. В резултат на това не губим данни. Дори ако нещо се е променило в източника, ако моделът на данните се е променил, ние веднага ще го открием и ще можем да се адаптираме.

Сега трябва да научите как да извличате запазени данни. Внимателно анализирахме нашите системи и видяхме, че класическият стек на Java и Oracle непременно съдържа някакъв вид ORM, който преобразува данни от релационни в обектни. Така че защо веднага да не дадете обекти на системите под формата на графика? Така че с радост приехме GraphQL, който отговори на всички наши нужди. Тя ви позволява да получавате данни под формата на графики и да извличате само това, от което се нуждаете в момента. Можете дори да създавате версии на API с доста голяма гъвкавост.

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

Внедрена система за удостоверяване.

Тогава забелязахме, че няколко роли изкристализираха в нашето решение. Ролята е вид агрегатор на функции. Обикновено ролите имат различни профили на използване на оборудване:

• T-Connect: обработва входящи връзки, CPU ограничен, ниска консумация на памет, без състояние.
• IB-Core: трансформира данните, които получава чрез протокола Tarantool, т.е. работи с таблици. Той също така не съхранява състояние и е мащабируем.
• Съхранение: съхранява само данни, не използва никаква логика. Тази роля изпълнява най-простите интерфейси. Мащабируемо благодарение на vshard.

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

И така, ние създадохме запис на асинхронен транзакционен поток от данни и опашка за поправка с администраторски интерфейс. Записът е асинхронен от бизнес гледна точка: ако ни е гарантирано, че записваме данни в себе си, независимо къде, тогава ще го потвърдим. Ако не е потвърдено, значи нещо се е объркало и данните трябва да бъдат изпратени. Това е асинхронният запис.

Тестване

Още в самото начало на проекта решихме, че ще се опитаме да внедрим тестова разработка. Пишем модулни тестове в Lua, използвайки рамката tarantool/tap, и интеграционни тестове в Python, използвайки рамката pytest. В същото време ние включваме както разработчици, така и анализатори в писането на интеграционни тестове.

Как използваме разработка, управлявана от тестове?

Ако искаме някаква нова функция, първо се опитваме да напишем тест за нея. Когато открием грешка, ние се уверяваме, че първо написваме тест и едва след това го коригираме. Отначало е трудно да се работи така, има неразбиране от страна на служителите, дори саботаж: „Нека бързо да го поправим сега, да направим нещо ново и след това да го покрием с тестове.“ Само че това „по-късно“ почти никога не идва.

Затова първо трябва да се насилите да пишете тестове и да помолите другите да го направят. Повярвайте ми, тестово ориентираното развитие носи ползи дори в краткосрочен план. Ще почувствате, че животът ви е станал по-лесен. Смятаме, че 99% от кода вече е покрит от тестове. Това изглежда много, но нямаме никакви проблеми: тестовете се изпълняват при всеки комит.

Но това, което обичаме най-много, е тестването на натоварването; смятаме го за най-важното и го провеждаме редовно.

Ще ви разкажа малка история за това как проведохме първия етап от тестването на натоварването на една от първите версии. Инсталирахме системата на лаптопа на разработчика, включихме натоварването и получихме 4 хиляди транзакции в секунда. Добър резултат за лаптоп. Инсталирахме го на стенд за виртуално натоварване от четири сървъра, по-слаб, отколкото в производството. Разгърнати до минимум. Пускаме го и получаваме по-лош резултат, отколкото на лаптоп в една тема. Шокиращо съдържание.

Бяхме много тъжни. Гледаме натоварването на сървъра, но се оказва, че са неактивни.

Обаждаме се на разработчиците и те ни обясняват, хората, които идват от света на Java, че Tarantool е еднонишков. Може да се използва ефективно само от едно процесорно ядро ​​под натоварване. След това разположихме максималния възможен брой инстанции на Tarantool на всеки сървър, включихме натоварването и вече получихме 14,5 хиляди транзакции в секунда.

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

В този случай паметта се използва само за обработка на входящи връзки и временни обекти.

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

И потреблението на памет нараства правопропорционално на количеството заредени данни.

Услуги

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

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

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

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

Стари системи

Не всички наши наследени системи могат да ни се обаждат през HTTP и да използват GraphQL, въпреки че поддържат протокола. Затова създадохме механизъм, който позволява данните да бъдат копирани в тези системи.

Ако нещо се промени за нас, уникалните тригери се задействат в ролята за съхранение и съобщението с промените завършва в опашката за обработка. Изпраща се до външна система с помощта на отделна роля на репликатор. Тази роля не съхранява състояние.

Нови подобрения

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

Разбрахме също, че само услугите няма да са достатъчни за нас, защото има доста тежки отчети, които трябва да се изграждат веднъж на ден, седмица, месец. Това може да отнеме много време и отчетите могат дори да блокират цикъла на събитията на Tarantool. Затова създадохме отделни роли: планировчик и изпълнител. Бегачите не съхраняват състояние. Те изпълняват тежки задачи, които не можем да изчислим в движение. А ролята на планировчика следи графика за стартиране на тези задачи, който е описан в конфигурацията. Самите задачи се съхраняват на същото място като бизнес данните. Когато дойде подходящият момент, планировчикът взема задачата, дава я на някой бегач, който я брои и запазва резултата.

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

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

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

Заключение

Започнахме със задачата да заредим данни в един модел и прекарахме три месеца в разработването му. Имахме шест системи за доставка на данни. Целият код за трансформация в един модел е около 30 хиляди реда в Lua. И по-голямата част от работата тепърва предстои. Понякога има липса на мотивация от съседни отбори и има много обстоятелства, които усложняват работата. Ако някога се сблъскате с подобна задача, тогава умножете времето, което ви се струва нормално за нейното изпълнение, по три или дори четири.

Също така не забравяйте, че съществуващите проблеми в бизнес процесите не могат да бъдат решени с помощта на нова СУБД, дори много продуктивна. Това, което искам да кажа? В началото на нашия проект създадохме впечатлението сред клиентите, че сега ще донесем нова бърза база данни и ще живеем! Процесите ще вървят по-бързо, всичко ще е наред. Всъщност технологиите не решават проблемите, които имат бизнес процесите, защото бизнес процесите са хора. И трябва да работите с хора, а не с технологии.

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

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

Няма нищо лошо в Lua. Всеки може да се научи да пише в него: Java разработчик, JavaScript разработчик, Python разработчик, front-end или back-end. Дори нашите анализатори пишат за това.

Когато говорим за факта, че нямаме SQL, това ужасява хората. „Как получавате данни без SQL? Това възможно ли е? Със сигурност. В класова система OLTP не е необходим SQL. Има алтернатива под формата на някакъв език, който веднага ви връща към документно-ориентиран изглед. Например GraphQL. И има алтернатива под формата на разпределени изчисления.

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

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