Vanaf verlede jaar het ons maatskappy hackathons begin organiseer. Die eerste sulke kompetisie was baie suksesvol, ons het daaroor geskryf in . Die tweede hackathon het in Februarie 2019 plaasgevind en was nie minder suksesvol nie. Oor die doelwitte om laasgenoemde nie so lank gelede te hou nie organiseerder.
Die deelnemers het 'n taamlik interessante taak met volle vryheid gekry om 'n tegnologiestapel vir die implementering daarvan te kies. Dit was nodig om 'n besluitnemingsplatform te implementeer vir gerieflike ontplooiing van kliëntetellingfunksies wat met 'n vinnige vloei van toepassings kon werk, swaar vragte kon weerstaan, en die stelsel self was maklik skaalbaar.
Die taak is nie-triviaal en kan op baie maniere opgelos word, soos ons daarvan oortuig was tydens die demonstrasie van die finale aanbiedings van die deelnemers se projekte. Daar was 6 spanne van 5 mense by die hackathon, al die deelnemers het goeie projekte gehad, maar ons platform het geblyk die mees mededingende te wees. Ons het 'n baie interessante projek waaroor ek in hierdie artikel wil praat.
Ons oplossing is 'n platform gebaseer op bedienerlose argitektuur binne Kubernetes, wat die tyd wat dit neem om nuwe kenmerke na produksie te bring, verminder. Dit stel ontleders in staat om kode te skryf in 'n omgewing wat vir hulle gerieflik is en dit in produksie te ontplooi sonder die deelname van ingenieurs en ontwikkelaars.
Wat is telling
Tinkoff.ru, soos baie moderne maatskappye, het kliëntetelling. Puntetelling is 'n kliënt assesseringstelsel gebaseer op statistiese metodes van data-analise.
Byvoorbeeld, 'n kliënt wend ons met 'n versoek om vir hom 'n lening uit te reik, of 'n individuele entrepreneursrekening by ons oop te maak. As ons van plan is om vir hom 'n lening uit te reik, moet ons sy solvensie bepaal, en as die rekening 'n individuele entrepreneur is, moet ons seker wees dat die kliënt nie bedrieglike transaksies sal doen nie.
Die basis vir die neem van sulke besluite is wiskundige modelle wat beide die data van die toepassing self en die data van ons berging ontleed. Benewens die puntetelling, kan soortgelyke statistiese metodes ook gebruik word in die diens van die generering van individuele aanbevelings vir nuwe produkte vir ons kliënte.
Die metode van so 'n assessering kan 'n verskeidenheid insetdata aanvaar. En op 'n sekere punt kan ons 'n nuwe parameter by die insette voeg, wat, gebaseer op die resultate van analise op historiese data, die omskakelingskoers van die gebruik van die diens sal verhoog.
Ons het 'n magdom data oor kliënteverhoudings, en die volume van hierdie inligting groei voortdurend. Vir die telling om te werk, vereis dataverwerking ook reëls (of wiskundige modelle) wat jou in staat stel om vinnig te besluit wie om 'n aansoek goed te keur, wie om te weier en wie om nog 'n paar produkte aan te bied, om hul potensiële belangstelling te bepaal.
Vir die taak op hande gebruik ons reeds 'n gespesialiseerde besluitnemingstelsel , wat, gebaseer op die reëls wat deur ontleders, tegnoloë en ontwikkelaars bepaal word, besluit of 'n bepaalde bankproduk aan die kliënt goedgekeur of geweier moet word.
Daar is baie klaargemaakte oplossings op die mark, beide puntemodelle en besluitnemingstelsels self. Ons gebruik een van hierdie stelsels in ons maatskappy. Maar die besigheid groei, diversifiseer, sowel die aantal kliënte as die aantal produkte wat aangebied word, neem toe, en daarmee saam kom idees na vore oor hoe om die bestaande besluitnemingsproses te verbeter. Mense wat met die bestaande stelsel werk, het sekerlik baie idees oor hoe om dit eenvoudiger, beter, geriefliker te maak, maar soms is idees van buite nuttig. Die Nuwe Hackathon is georganiseer met die doel om goeie idees te versamel.
Taak
Die hackathon is op 23 Februarie gehou. Die deelnemers is 'n gevegstaak gebied: om 'n besluitnemingstelsel te ontwikkel wat aan 'n aantal voorwaardes moes voldoen.
Ons is vertel hoe die bestaande stelsel funksioneer en watter probleme tydens die werking daarvan ontstaan, asook watter besigheidsdoelwitte die ontwikkelde platform moet nastreef. Die stelsel moet 'n vinnige tyd-tot-mark hê vir die ontwikkeling van reëls sodat die werkskode van ontleders so vinnig as moontlik in produksie kom. En vir die inkomende vloei van aansoeke moet die besluitnemingstyd tot 'n minimum neig. Die stelsel wat ontwikkel word, moet ook kruisverkoopvermoëns hê om die kliënt die geleentheid te gee om ander maatskappyprodukte te koop as dit deur ons goedgekeur is en potensiële belangstelling van die kliënt het.
Dit is duidelik dat dit onmoontlik is om 'n gereed-vir-vrystelling-projek oornag te skryf wat beslis in produksie sal gaan, en dit is nogal moeilik om die hele stelsel te dek, so ons is gevra om ten minste 'n deel daarvan te implementeer. 'n Aantal vereistes is vasgestel waaraan die prototipe moet voldoen. Dit was moontlik om beide te probeer om al die vereistes in hul geheel te dek, en om in detail te werk aan individuele afdelings van die platform wat ontwikkel word.
Wat tegnologie betref, het alle deelnemers volkome vryheid van keuse gekry. Dit was moontlik om enige konsepte en tegnologieë te gebruik: datastroming, masjienleer, gebeurtenisverkryging, groot data en ander.
Ons oplossing
Na 'n bietjie dinkskrum het ons besluit dat 'n FaaS-oplossing ideaal sou wees om die taak te voltooi.
Vir hierdie oplossing was dit nodig om 'n geskikte bedienerlose raamwerk te vind om die reëls van die besluitnemingstelsel wat ontwikkel word, te implementeer. Aangesien Tinkoff Kubernetes aktief vir infrastruktuurbestuur gebruik, het ons gekyk na verskeie klaargemaakte oplossings wat daarop gebaseer is; ek sal jou later meer daaroor vertel.
Om die mees doeltreffende oplossing te vind, het ons gekyk na die produk wat ontwikkel word deur die oë van sy gebruikers. Die hoofgebruikers van ons stelsel is ontleders wat betrokke is by reëlontwikkeling. Die reëls moet na die bediener ontplooi word, of, soos in ons geval, in die wolk ontplooi word, vir daaropvolgende besluitneming. Vanuit 'n ontleder se perspektief lyk die werkvloei soos volg:
- Die ontleder skryf 'n skrif, reël of ML-model gebaseer op data van die pakhuis. As deel van die hackathon het ons besluit om Mongodb te gebruik, maar die keuse van databergingstelsel is nie hier belangrik nie.
- Nadat die ontwikkelde reëls op historiese data getoets is, laai die ontleder sy kode op na die administrasiepaneel.
- Om weergawes te verseker, sal alle kode na Git-bewaarplekke gaan.
- Deur die administrasiepaneel sal dit moontlik wees om die kode in die wolk te ontplooi as 'n aparte funksionele bedienerlose module.
Aanvanklike data van kliënte moet deur 'n gespesialiseerde Verrykingsdiens gaan wat ontwerp is om die aanvanklike versoek te verryk met data van die pakhuis. Dit was belangrik om hierdie diens so te implementeer dat dit met 'n enkele bewaarplek sou werk (waaruit die ontleder data neem wanneer hy reëls ontwikkel) om 'n verenigde datastruktuur te handhaaf.
Selfs voor die hackathon het ons besluit op die Serverless-raamwerk wat ons sou gebruik. Vandag is daar heelwat tegnologieë op die mark wat hierdie benadering implementeer. Die gewildste oplossings binne die Kubernetes-argitektuur is Fission, Open FaaS en Kubeless. Daar is selfs .
Nadat ons al die voor- en nadele opgeweeg het, het ons gekies . Hierdie bedienerlose raamwerk is redelik maklik om te bestuur en voldoen aan die vereistes van die taak.
Om met Fission te werk, moet jy twee basiese konsepte verstaan: funksie en omgewing. 'n Funksie is 'n stukkie kode wat geskryf is in een van die tale waarvoor daar 'n Fission-omgewing is. sluit Python, JS, Go, JVM en baie ander gewilde tale en tegnologieë in.
Fission is ook in staat om funksies uit te voer wat verdeel is in verskeie lêers, vooraf verpak in 'n argief. Die werking van Fission in 'n Kubernetes-kluster word verseker deur gespesialiseerde peule, wat deur die raamwerk self bestuur word. Om met cluster-peule te kommunikeer, moet elke funksie sy eie roete toegeken word, en waarheen jy GET-parameters of versoekliggaam kan deurgee in die geval van 'n POST-versoek.
As gevolg hiervan het ons beplan om 'n oplossing te kry wat ontleders in staat sal stel om ontwikkelde reëlskrifte te ontplooi sonder die deelname van ingenieurs en ontwikkelaars. Die beskryfde benadering skakel ook die behoefte uit vir ontwikkelaars om ontlederkode in 'n ander taal te herskryf. Byvoorbeeld, vir die huidige besluitnemingstelsel wat ons gebruik, moet ons reëls in hoogs gespesialiseerde tegnologieë en tale skryf, waarvan die omvang uiters beperk is, en daar is ook 'n sterk afhanklikheid van die toepassingsbediener, aangesien alle konsepbankreëls word in 'n enkele omgewing ontplooi. As gevolg hiervan, om nuwe reëls te implementeer, is dit nodig om die hele stelsel vry te stel.
In ons voorgestelde oplossing is dit nie nodig om reëls vry te stel nie; die kode kan maklik met die klik van 'n knoppie ontplooi word. Ook laat infrastruktuurbestuur in Kubernetes jou toe om nie aan belading en skaal te dink nie; sulke probleme word buite die boks opgelos. En die gebruik van 'n enkele datapakhuis elimineer die behoefte om intydse data met historiese data te vergelyk, wat die ontleder se werk vergemaklik.
Wat ons gekry het
Aangesien ons na die hackathon gekom het met 'n klaargemaakte oplossing (in ons fantasieë), was al wat ons moes doen om al ons gedagtes in reëls kode te omskep.
Die sleutel tot sukses by enige hackathon is voorbereiding en 'n goedgeskrewe plan. Daarom was die eerste ding wat ons gedoen het om te besluit uit watter modules ons stelselargitektuur sal bestaan en watter tegnologie ons sal gebruik.
Die argitektuur van ons projek was soos volg:
Hierdie diagram toon twee toegangspunte, die ontleder (die hoofgebruiker van ons stelsel) en die kliënt.
Die werkproses is so gestruktureer. Die ontleder ontwikkel 'n reëlfunksie en 'n dataverrykingsfunksie vir sy model, stoor sy kode in 'n Git-bewaarplek en ontplooi sy model na die wolk deur die administrateurtoepassing. Kom ons kyk na hoe die ontplooide funksie geroep sal word en neem besluite oor inkomende versoeke van kliënte:
- Die kliënt vul 'n vorm op die webwerf in en stuur sy versoek aan die kontroleerder. 'n Aansoek waaroor 'n besluit geneem moet word, kom na die stelselinvoer en word in die oorspronklike vorm in die databasis aangeteken.
- Vervolgens word die rou versoek gestuur vir verryking, indien nodig. U kan die aanvanklike versoek aanvul met data van beide eksterne dienste en vanaf die berging. Die gevolglike verrykte navraag word ook in die databasis gestoor.
- Die ontlederfunksie word geloods, wat 'n verrykte navraag as inset neem en 'n oplossing produseer, wat ook na die stoor geskryf word.
Ons het besluit om MongoDB as 'n berging in ons stelsel te gebruik as gevolg van die dokument-georiënteerde berging van data in die vorm van JSON-dokumente, aangesien die verrykingsdienste, insluitend die oorspronklike versoek, alle data deur REST-beheerders saamgevoeg het.
Ons het dus XNUMX uur gehad om die platform te implementeer. Ons het die rolle redelik suksesvol versprei; elke spanlid het sy eie verantwoordelikheidsgebied in ons projek gehad:
- Vooraanstaande administrasiepanele vir die ontleder se werk, waardeur hy reëls van die weergawebeheerstelsel van geskrewe skrifte kon aflaai, opsies vir die verryking van invoerdata kon kies en reëlskrifte aanlyn kon wysig.
- Backend admin, insluitend REST API vir die voorkant en integrasie met VCS.
- Die opstel van infrastruktuur in Google Wolk en die ontwikkeling van 'n diens om brondata te verryk.
- 'n Module vir die integrasie van die admin-toepassing met die Serverless-raamwerk vir die daaropvolgende implementering van reëls.
- Skripte van reëls vir die toets van die werkverrigting van die hele stelsel en samevoeging van analise op inkomende toepassings (besluite geneem) vir die finale demonstrasie.
Kom ons begin in orde.
Ons frontend is in Angular 7 geskryf met behulp van die bank-UI Kit. Die finale weergawe van die administrasiepaneel het soos volg gelyk:
Aangesien daar min tyd was, het ons probeer om slegs die sleutelfunksies te implementeer. Om 'n funksie in die Kubernetes-kluster te ontplooi, was dit nodig om 'n gebeurtenis te kies ('n diens waarvoor 'n reël in die wolk ontplooi moet word) en die kode van die funksie wat die besluitnemingslogika implementeer. Vir elke ontplooiing van 'n reël vir die geselekteerde diens, het ons 'n log van hierdie gebeurtenis geskryf. In die administrasiepaneel kan u logs van alle gebeurtenisse sien.
Alle funksiekode is in 'n afgeleë Git-bewaarplek gestoor, wat ook in die administrasiepaneel gestel moes word. Om die kode weer te gee, is alle funksies in verskillende takke van die bewaarplek gestoor. Die adminpaneel bied ook die vermoë om aanpassings aan geskrewe skrifte te maak, sodat jy nie net die geskrewe kode kan nagaan nie, maar ook die nodige veranderinge kan maak voordat jy 'n funksie na produksie ontplooi.
Benewens die reëlfunksies, het ons ook die vermoë geïmplementeer om die brondata geleidelik te verryk deur gebruik te maak van Verrykingsfunksies, waarvan die kode ook skrifte was waarin dit moontlik was om na die datapakhuis te gaan, derdepartydienste te bel en voorlopige berekeninge uit te voer . Om ons oplossing te demonstreer, het ons die sterreteken bereken van die kliënt wat die versoek gelaat het en sy selfoonoperateur met behulp van 'n derdeparty REST-diens bepaal.
Die agterkant van die platform is in Java geskryf en as 'n Spring Boot-toepassing geïmplementeer. Ons het aanvanklik beplan om Postgres te gebruik om administrasiedata te stoor, maar as deel van die hackathon het ons besluit om onsself tot 'n eenvoudige H2 te beperk om tyd te bespaar. Op die agterkant is integrasie met Bitbucket geïmplementeer om die navraagverrykingsfunksies en reëlskrifte weer te gee. Vir integrasie met afgeleë Git-bewaarplekke, het ons gebruik , wat 'n soort omhulsel oor CLI-opdragte is, wat jou toelaat om enige git-instruksies uit te voer met behulp van 'n gerieflike sagteware-koppelvlak. Ons het dus twee afsonderlike bewaarplekke vir verrykingsfunksies en reëls gehad, en al die skrifte is in gidse verdeel. Deur die UI was dit moontlik om die nuutste commit van 'n skrif van 'n arbitrêre tak van die bewaarplek te kies. Wanneer veranderinge aan die kode deur die administrasiepaneel gemaak word, is commits van die veranderde kode in afgeleë bewaarplekke geskep.
Om ons idee te implementeer, het ons geskikte infrastruktuur nodig gehad. Ons het besluit om ons Kubernetes-kluster in die wolk te ontplooi. Ons keuse was Google Cloud Platform. Die Fission-bedienerlose raamwerk is op 'n Kubernetes-kluster geïnstalleer, wat ons in Gcloud ontplooi het. Aanvanklik is die brondataverrykingsdiens geïmplementeer as 'n aparte Java-toepassing wat in 'n Pod binne die k8s-groep toegedraai is. Maar na 'n voorlopige demonstrasie van ons projek in die middel van die hackathon, is ons aanbeveel om die Verrykingsdiens meer buigsaam te maak om die geleentheid te bied om te kies hoe om die rou data van inkomende toepassings te verryk. En ons het geen ander keuse gehad as om die verrykingsdiens ook Bedienerloos te maak nie.
Om met Fission te werk, het ons die Fission CLI gebruik, wat bo-op die Kubernetes CLI geïnstalleer moet word. Die implementering van funksies in 'n k8s-groepering is redelik eenvoudig; jy hoef net 'n interne roete en ingang aan die funksie toe te wys om inkomende verkeer toe te laat as toegang buite die groep benodig word. Die implementering van een funksie neem gewoonlik nie meer as 10 sekondes nie.
Finale aanbieding van die projek en opsomming
Om te demonstreer hoe ons stelsel werk, het ons 'n eenvoudige vorm op 'n afgeleë bediener geplaas waar jy 'n aansoek vir een van die bank se produkte kan indien. Om te versoek, moes jy jou voorletters, geboortedatum en telefoonnommer invoer.
Data van die kliëntvorm het na die kontroleerder gegaan, wat terselfdertyd versoeke vir alle beskikbare reëls gestuur het, nadat die data voorheen volgens die gespesifiseerde voorwaardes verryk is en dit in 'n gemeenskaplike berging gestoor is. In totaal het ons drie funksies ontplooi wat besluite neem oor inkomende toepassings en 4 dataverrykingsdienste. Nadat die aansoek ingedien is, het die kliënt ons besluit ontvang:
Benewens weiering of goedkeuring, het die kliënt ook 'n lys van ander produkte ontvang, versoeke waarvoor ons parallel gestuur het. Dit is hoe ons die moontlikheid van kruisverkoop in ons platform gedemonstreer het.
Daar was 'n totaal van 3 fiktiewe bankprodukte beskikbaar:
- Krediet.
- speelding
- Verband.
Tydens die demonstrasie het ons voorbereide funksies en verrykingsskrifte vir elke diens ontplooi.
Elke reël het sy eie stel invoerdata vereis. Dus, om 'n verband goed te keur, het ons die kliënt se sterreteken bereken en dit verbind met die logika van die maankalender. Om 'n speelding goed te keur, het ons gekontroleer dat die kliënt meerderjarig geword het, en om 'n lening uit te reik, het ons 'n versoek aan 'n eksterne oop diens gestuur om die sellulêre operateur te bepaal, en 'n besluit is daaroor geneem.
Ons het probeer om ons demonstrasie interessant en interaktief te maak, almal teenwoordig kon na ons vorm gaan en die beskikbaarheid van ons fiktiewe dienste aan hulle nagaan. En heel aan die einde van die aanbieding het ons ontledings van ontvangde aansoeke getoon, wat gewys het hoeveel mense ons diens gebruik het, die aantal goedkeurings en weieringe.
Om ontleding aanlyn te versamel, het ons ook 'n oopbron BI-nutsding ontplooi en dit aan ons stooreenheid vasgeskroef. Metabase laat jou toe om skerms met ontleding te bou oor die data wat ons interesseer; jy hoef net 'n verbinding met die databasis te registreer, tabelle te kies (in ons geval, data-insamelings, aangesien ons MongoDB gebruik het), en die velde van belang vir ons spesifiseer .
Gevolglik het ons 'n goeie prototipe van 'n besluitnemingsplatform gekry, en tydens die demonstrasie kon elke luisteraar persoonlik die prestasie daarvan nagaan. 'n Interessante oplossing, 'n voltooide prototipe en 'n suksesvolle demonstrasie het ons toegelaat om te wen, ondanks sterk mededinging van ander spanne. Ek is seker dat daar ook 'n interessante artikel oor elke span se projek geskryf kan word.
Bron: will.com