Begjin ferline jier begon ús bedriuw hackathons te organisearjen. De earste sa'n kompetysje wie tige suksesfol, wy skreaunen deroer yn . De twadde hackathon fûn plak yn febrewaris 2019 en wie net minder suksesfol. Oer de doelen fan it hâlden fan de lêste net sa lang lyn organisator.
De dielnimmers krigen in frijwat nijsgjirrige taak mei folsleine frijheid by it kiezen fan in technologystapel foar de ymplemintaasje dêrfan. It wie nedich om in beslútfoarmingplatfoarm út te fieren foar handige ynset fan funksjes fan klantscore dy't kinne wurkje mei in flugge stream fan applikaasjes, swiere loads wjerstean, en it systeem sels wie maklik skalberber.
De taak is net-triviaal en kin op in protte manieren oplost wurde, sa't wy oertsjûge wiene by de demonstraasje fan 'e definitive presintaasjes fan' e projekten fan 'e dielnimmers. Der wiene 6 teams fan 5 minsken by de hackathon, alle dielnimmers hiene goede projekten, mar ús platfoarm blykte it meast kompetitive te wêzen. Wy hawwe in tige nijsgjirrich projekt, dêr't ik graach oer prate wolle yn dit artikel.
Us oplossing is in platfoarm basearre op Serverless-arsjitektuer binnen Kubernetes, wat de tiid ferminderet dy't it nimt om nije funksjes nei produksje te bringen. It lit analisten koade skriuwe yn in omjouwing dy't har handich is en it yn produksje ynsette sûnder de dielname fan yngenieurs en ûntwikkelders.
Wat is skoare
Tinkoff.ru, lykas in protte moderne bedriuwen, hat klant skoare. Skoare is in klantevaluaasjesysteem basearre op statistyske metoaden fan gegevensanalyse.
Bygelyks, in klant wendt ús ta mei in fersyk om him in liening út te jaan, of in yndividuele ûndernimmerkonto by ús te iepenjen. As wy fan plan binne om him in liening út te jaan, dan moatte wy syn solvabiliteit beoardielje, en as it akkount in yndividuele ûndernimmer is, dan moatte wy der wis fan wêze dat de klant gjin frauduleuze transaksjes sil útfiere.
De basis foar it meitsjen fan sokke besluten binne wiskundige modellen dy't sawol de gegevens fan 'e applikaasje sels as de gegevens fan ús opslach analysearje. Neist skoare kinne ferlykbere statistyske metoaden ek brûkt wurde yn 'e tsjinst fan it generearjen fan yndividuele oanbefellings foar nije produkten foar ús kliïnten.
De metoade fan sa'n beoardieling kin in ferskaat oan ynfiergegevens akseptearje. En op in stuit kinne wy in nije parameter tafoegje oan 'e ynfier, dy't, basearre op' e resultaten fan 'e analyze op histoaryske gegevens, de konverzje taryf fan it brûken fan' e tsjinst sil ferheegje.
Wy hâlde in skat oan gegevens oer klantrelaasjes, en it folume fan dizze ynformaasje groeit konstant. Foar it skoaren om te wurkjen fereasket gegevensferwurking ek regels (as wiskundige modellen) wêrtroch jo fluch kinne beslute wa't in oanfraach goedkarre sil, wa't te wegerjen, en wa't in pear mear produkten oanbiede moatte, beoardielje har potensjele belangstelling.
Foar de opdracht brûke wy al in spesjalisearre beslútfoarmingsysteem .
D'r binne in protte ready-made oplossingen op 'e merk, sawol skoare modellen as beslútfoarming systemen sels. Wy brûke ien fan dizze systemen yn ús bedriuw. Mar it bedriuw groeit, diversifisearret, sawol it oantal kliïnten as it oantal oanbeane produkten nimt ta, en tegearre mei dit komme ideeën op oer hoe't it besteande beslútfoarmingsproses kin ferbetterje. Wis, minsken dy't wurkje mei it besteande systeem hawwe in protte ideeën oer hoe't jo it ienfâldiger, better, handiger meitsje kinne, mar soms binne ideeën fan bûten nuttich. De Nije Hackathon waard organisearre mei it doel om lûdideeën te sammeljen.
Taak
De hackathon waard hâlden op 23 febrewaris. De dielnimmers krigen in gefjochtstaak oanbean: it ûntwikkeljen fan in beslútfoarmingsysteem dat oan in oantal betingsten foldwaan moast.
Wy waarden ferteld hoe't it besteande systeem funksjonearret en hokker swierrichheden ûntsteane tidens de eksploitaasje, lykas hokker bedriuwsdoelen it ûntwikkele platfoarm moat stribjen. It systeem moat in rappe tiid-to-merk hawwe foar it ûntwikkeljen fan regels, sadat de wurkkoade fan analysten sa rap mooglik yn produksje komt. En foar de ynkommende stream fan oanfragen moat de beslútfoarmingstiid nei in minimum neigean. Ek moat it systeem dat wurdt ûntwikkele hawwe cross-sell-mooglikheden om de klant de kâns te jaan om oare bedriuwprodukten te keapjen as se troch ús goedkard binne en potinsjele belangstelling hawwe fan 'e klant.
It is dúdlik dat it ûnmooglik is om oernachtich in ree-to-release-projekt te skriuwen dat grif yn produksje sil gean, en it is frij lestich om it heule systeem te dekken, dus waarden wy frege om op syn minst in diel dêrfan út te fieren. Der binne in oantal easken steld dêr't it prototype oan foldwaan moat. It wie mooglik om te besykjen om alle easken yn har gehiel te dekken, en yn detail te wurkjen oan yndividuele dielen fan it platfoarm dat ûntwikkele waard.
Wat technology oangiet, krigen alle dielnimmers folsleine frijheid fan kar. It wie mooglik om alle konsepten en technologyen te brûken: gegevensstreaming, masine learen, event sourcing, big data en oaren.
Us oplossing
Nei in bytsje brainstorming, hawwe wy besletten dat in FaaS-oplossing ideaal wêze soe foar it foltôgjen fan de taak.
Foar dizze oplossing wie it nedich om in gaadlik Serverless ramt te finen om de regels fan it beslútfoarmingsysteem te ûntwikkeljen. Om't Tinkoff Kubernetes aktyf brûkt foar ynfrastruktuerbehear, hawwe wy ferskate klearmakke oplossingen sjoen op basis dêrfan; Ik sil jo der letter mear oer fertelle.
Om de meast effektive oplossing te finen, seagen wy nei it produkt dat waard ûntwikkele troch de eagen fan har brûkers. De wichtichste brûkers fan ús systeem binne analysten belutsen by regelûntwikkeling. De regels moatte wurde ynset op de server, of, lykas yn ús gefal, ynset yn 'e wolk, foar folgjende beslútfoarming. Fanút it perspektyf fan in analist sjocht de workflow der sa út:
- De analist skriuwt in skript, regel, of ML-model basearre op gegevens út it pakhús. As ûnderdiel fan 'e hackathon hawwe wy besletten om Mongodb te brûken, mar de kar foar gegevensopslachsysteem is hjir net wichtich.
- Nei it testen fan de ûntwikkele regels op histoaryske gegevens, uploadt de analist syn koade nei it adminpaniel.
- Om ferzjeferzje te garandearjen, sil alle koade nei Git-repositories gean.
- Troch it adminpaniel sil it mooglik wêze om de koade yn 'e wolk yn te setten as in aparte funksjonele Serverless module.
Inisjele gegevens fan kliïnten moatte troch in spesjalisearre ferrikingstsjinst passe ûntworpen om it earste fersyk te ferrykjen mei gegevens fan it pakhús. It wie wichtich om dizze tsjinst op sa'n manier út te fieren dat it soe wurkje mei in inkele repository (wêrfan de analist gegevens nimt by it ûntwikkeljen fan regels) om in unifoarme gegevensstruktuer te behâlden.
Sels foar de hackathon hawwe wy besletten oer it Serverless-ramt dat wy soene brûke. Tsjintwurdich binne d'r in protte technologyen op 'e merke dy't dizze oanpak útfiere. De populêrste oplossingen binnen de Kubernetes-arsjitektuer binne Fission, Open FaaS en Kubeless. Der binne sels .
Nei it weagjen fan alle foar- en neidielen, hawwe wy keazen . Dit Serverless kader is frij maklik te behearjen en foldocht oan de easken fan 'e taak.
Om mei Fission te wurkjen moatte jo twa basisbegripen begripe: funksje en omjouwing. In funksje is in stik koade skreaun yn ien fan 'e talen dêr't in Fission-omjouwing foar is. omfettet Python, JS, Go, JVM en in protte oare populêre talen en technologyen.
Fission is ek yn steat om funksjes út te fieren ferdield yn ferskate bestannen, foarferpakt yn in argyf. De wurking fan Fission yn in Kubernetes-kluster wurdt fersoarge troch spesjalisearre pods, dy't wurde beheard troch it ramt sels. Om ynteraksje mei kluster pods, eltse funksje moat wurde tawiisd in eigen rûte, en dêr't jo kinne trochjaan GET parameters of fersyk lichem yn it gefal fan in POST fersyk.
As gefolch hawwe wy plannen om in oplossing te krijen wêrmei analysten ûntwikkele regelskripts kinne ynsette sûnder de dielname fan yngenieurs en ûntwikkelders. De beskreaune oanpak elimineert ek de needsaak foar ûntwikkelders om analystkoade yn in oare taal te herskriuwen. Bygelyks, foar it hjoeddeiske beslútfoarmingsysteem dat wy brûke, moatte wy regels skriuwe yn heul spesjalisearre technologyen en talen, wêrfan it berik ekstreem beheind is, en d'r is ek in sterke ôfhinklikens fan 'e applikaasjetsjinner, om't alle ûntwerpbankregels wurde ynset yn ien omjouwing. As gefolch, om nije regels yn te setten, is it nedich om it heule systeem frij te litten.
Yn ús foarstelde oplossing is d'r gjin need om regels frij te litten; de koade kin maklik wurde ynset mei de klik op in knop. Ek ynfrastruktuerbehear yn Kubernetes lit jo net tinke oer lading en skaalfergrutting; sokke problemen wurde út 'e doaze oplost. En it brûken fan ien data warehouse elimineert de needsaak om te fergelykjen real-time gegevens mei histoaryske gegevens, dy't simplifies de analyst syn wurk.
Wat wy krigen
Sûnt wy kamen ta de hackathon mei in klearebare oplossing (yn ús fantasyen), alles wat wy hoege te dwaan wie omsette al ús tinzen yn rigels fan koade.
De kaai foar sukses by elke hackathon is tarieding en in goed skreaun plan. Dêrom wie it earste wat wy diene beslute út hokker modules ús systeemarsjitektuer soe bestean út en hokker technologyen wy soene brûke.
De arsjitektuer fan ús projekt wie as folget:
Dit diagram lit twa yngongspunten sjen, de analist (de haadbrûker fan ús systeem) en de kliïnt.
It wurkproses is sa opboud. De analist ûntwikkelet in regelfunksje en in gegevensferrikingsfunksje foar syn model, bewarret syn koade yn in Git-repository, en set syn model yn 'e wolk fia de administratorapplikaasje. Litte wy beskôgje hoe't de ynset funksje sil wurde neamd en besluten nimme oer ynkommende oanfragen fan kliïnten:
- De kliïnt folt in formulier yn op 'e webside en stjoert syn fersyk nei de controller. In oanfraach dêr't in beslút oer nommen wurde moat, komt by de systeemynput en wurdt yn 'e orizjinele foarm opnommen yn' e databank.
- Dêrnei wurdt it rau fersyk stjoerd foar ferriking, as it nedich is. Jo kinne it earste fersyk oanfolje mei gegevens sawol fan eksterne tsjinsten as fan 'e opslach. De resultearjende ferrike query wurdt ek opslein yn 'e databank.
- De analystfunksje wurdt lansearre, dy't in ferrike query as ynput nimt en in oplossing produsearret, dy't ek skreaun wurdt nei de opslach.
Wy besletten om MongoDB te brûken as opslach yn ús systeem fanwegen de dokumint-rjochte opslach fan gegevens yn 'e foarm fan JSON-dokuminten, om't de ferrikingstsjinsten, ynklusyf it orizjinele fersyk, alle gegevens sammele fia REST-controllers.
Dat, wy hiene XNUMX oeren om it platfoarm te ymplementearjen. Wy hawwe de rollen frij suksesfol ferdield; elk teamlid hie syn eigen ferantwurdlikensgebiet yn ús projekt:
- Front-end adminpanielen foar it wurk fan 'e analist, wêrtroch hy regels koe downloade fan it ferzjekontrôlesysteem fan skreaune skripts, opsjes selektearje foar it ferrykjen fan ynfiergegevens en online regelskripts bewurkje.
- Backend admin, ynklusyf REST API foar de foarkant en yntegraasje mei VCS.
- Ynfrastruktuer ynstelle yn Google Cloud en in tsjinst ûntwikkelje foar it ferrykjen fan boarnegegevens.
- In module foar it yntegrearjen fan de admin-applikaasje mei it Serverless-ramt foar folgjende ynset fan regels.
- Skripten fan regels foar it testen fan 'e prestaasjes fan it heule systeem en aggregaasje fan analytiken op ynkommende applikaasjes (besluten makke) foar de definitive demonstraasje.
Litte wy yn oarder begjinne.
Us frontend is skreaun yn Angular 7 mei de bank UI Kit. De definitive ferzje fan it adminpaniel seach der sa út:
Om't d'r net folle tiid wie, hawwe wy besocht allinich de kaaifunksjonaliteit út te fieren. Om in funksje yn te setten yn it Kubernetes-kluster, wie it nedich om in evenemint te selektearjen (in tsjinst wêrfoar in regel yn 'e wolk ynset wurde moat) en de koade fan 'e funksje dy't de beslútfoarmingslogika ymplementearret. Foar elke ynset fan in regel foar de selekteare tsjinst hawwe wy in logboek skreaun fan dit evenemint. Yn it adminpaniel kinne jo logs sjen fan alle eveneminten.
Alle funksjekoade waard opslein yn in Git-repository op ôfstân, dy't ek yn it adminpaniel ynsteld wurde moast. Om de koade te ferzjen, waarden alle funksjes opslein yn ferskate tûken fan it repository. It adminpaniel biedt ek de mooglikheid om oanpassingen te meitsjen oan skreaune skripts, sadat jo foardat jo in funksje ynset meitsje foar produksje, jo net allinich de skreaune koade kinne kontrolearje, mar ek de nedige wizigingen meitsje.
Neist de regelsfunksjes hawwe wy ek de mooglikheid ymplementearre om de boarnegegevens stadichoan te ferrykjen mei help fan ferrikingsfunksjes, wêrfan de koade ek skripts wie wêryn it mooglik wie om nei it datapakhûs te gean, tsjinsten fan tredden te neamen en foarriedige berekkeningen út te fieren . Om ús oplossing te demonstrearjen, hawwe wy it zodiac teken berekkene fan 'e kliïnt dy't it fersyk ferliet en syn mobile operator bepale mei in REST-tsjinst fan tredden.
De efterkant fan it platfoarm is skreaun yn Java en ymplementearre as in Spring Boot-applikaasje. Wy planden ynearsten om Postgres te brûken om admingegevens op te slaan, mar, as ûnderdiel fan 'e hackathon, besleaten wy ússels te beheinen ta in ienfâldige H2 om tiid te besparjen. Op 'e efterkant waard yntegraasje mei Bitbucket ymplementearre foar ferzje fan de query-ferrikingsfunksjes en regelskripts. Foar yntegraasje mei Git-repositories op ôfstân brûkten wy , dat is in soarte fan wrapper oer CLI-kommando's, wêrtroch jo alle git-ynstruksjes kinne útfiere mei in handige software-ynterface. Sa hienen wy twa aparte repositories foar ferrikingsfunksjes en regels, en alle skripts waarden ferdield yn mappen. Troch de UI wie it mooglik om de lêste commit te selektearjen fan in skript fan in willekeurige tûke fan it repository. By it meitsjen fan wizigingen oan 'e koade fia it adminpaniel, waarden commits fan' e feroare koade makke yn repositories op ôfstân.
Om ús idee út te fieren, hiene wy passende ynfrastruktuer nedich. Wy besletten om ús Kubernetes-kluster yn 'e wolk yn te setten. Us kar wie Google Cloud Platform. It Fission-serverleaze ramt waard ynstalleare op in Kubernetes-kluster, dat wy yn Gcloud ynset. Yn it earstoan waard de tsjinst foar boarnegegevensferriking ymplementearre as in aparte Java-applikaasje ferpakt yn in Pod binnen it k8s-kluster. Mar nei in foarriedige demonstraasje fan ús projekt yn 'e midden fan' e hackathon, waarden wy oanrikkemandearre om de Enrichment-tsjinst fleksibeler te meitsjen om de kâns te jaan om te kiezen hoe't jo de rauwe gegevens fan ynkommende applikaasjes ferrykje kinne. En wy hiene gjin oare kar as de ferrikingstsjinst ek Serverless te meitsjen.
Om mei Fission te wurkjen, brûkten wy de Fission CLI, dy't boppe op 'e Kubernetes CLI ynstalleare moat. Funksjes ynsette yn in k8s-kluster is frij ienfâldich; jo moatte gewoan in ynterne rûte en yngong tawize oan 'e funksje om ynkommende ferkear mooglik te meitsjen as tagong bûten it kluster nedich is. It ynsetten fan ien funksje nimt typysk net mear as 10 sekonden.
Finale presintaasje fan it projekt en gearfetting
Om te demonstrearjen hoe't ús systeem wurket, hawwe wy in ienfâldich formulier pleatst op in tsjinner op ôfstân wêr't jo in oanfraach kinne yntsjinje foar ien fan 'e produkten fan' e bank. Om oan te freegjen moasten jo jo inisjalen, bertedatum en telefoannûmer ynfiere.
Gegevens út it kliïntformulier gongen nei de controller, dy't tagelyk fersiken stjoerde foar alle beskikbere regels, nei't de gegevens earder ferrike hawwe neffens de oantsjutte betingsten, en bewarre se yn in mienskiplike opslach. Yn totaal hawwe wy trije funksjes ynset dy't besluten nimme oer ynkommende applikaasjes en 4 tsjinsten foar gegevensferriking. Nei it yntsjinjen fan de oanfraach krige de klant ús beslút:
Njonken wegering of goedkarring krige de kliïnt ek in list mei oare produkten, oanfragen dêr't wy parallel foar stjoerd hawwe. Dit is hoe't wy de mooglikheid hawwe fan cross-sale yn ús platfoarm oantoand.
D'r wiene yn totaal 3 fiktive bankprodukten beskikber:
- Kredyt.
- Toy
- Hypteek.
Tidens de demonstraasje hawwe wy foar elke tsjinst taret funksjes en ferrikingsskripts ynset.
Elke regel easke in eigen set ynfiergegevens. Dat, om in hypoteek goed te keuren, hawwe wy it zodiacteken fan 'e kliïnt berekkene en dit ferbûn mei de logika fan' e moannekalinder. Om in boartersguod te goedkarren, hawwe wy kontrolearre dat de kliïnt de leeftyd fan mearderheid berikt hie, en om in liening út te jaan, stjoerde wy in fersyk nei in eksterne iepen tsjinst foar it bepalen fan 'e sellulêre operator, en dêr waard in beslút oer makke.
Wy besochten ús demonstraasje ynteressant en ynteraktyf te meitsjen, elkenien oanwêzich koe nei ús formulier gean en de beskikberens fan ús fiktive tsjinsten oan har kontrolearje. En oan 'e ein fan' e presintaasje demonstrearren wy analytyk fan ûntfongen applikaasjes, dy't sjen lieten hoefolle minsken ús tsjinst brûkten, it oantal goedkarring en wegeringen.
Om analytics online te sammeljen, hawwe wy ek in iepen boarne BI-ark ynset en geschroefd it oan ús opslach ienheid. Metabase lit jo skermen bouwe mei analytyk oer de gegevens dy't ús ynteressearje; jo moatte gewoan in ferbining registrearje mei de databank, tabellen selektearje (yn ús gefal, gegevenssammelingen, om't wy MongoDB brûkten), en spesifisearje de fjilden fan belang foar ús .
As gefolch hawwe wy in goed prototype fan in beslútfoarmingplatfoarm krigen, en tidens de demonstraasje koe elke harker har prestaasjes persoanlik kontrolearje. In nijsgjirrige oplossing, in klear prototype en in suksesfolle demonstraasje lieten ús winne, nettsjinsteande sterke konkurrinsje fan oare teams. Ik bin der wis fan dat der ek in nijsgjirrich artikel kin wurde skreaun oer it projekt fan elk team.
Boarne: www.habr.com