Ekde la pasinta jaro, nia kompanio komencis organizi hakatonojn. La unua tia konkurso estis tre sukcesa, ni skribis pri ĝi en . La dua hakatono okazis en februaro 2019 kaj estis ne malpli sukcesa. Pri la celoj teni ĉi-lastan antaŭ ne tiom longe organizanto.
La partoprenantoj ricevis sufiĉe interesan taskon kun plena libereco en elekto de teknologia stako por ĝia efektivigo. Estis necese efektivigi decidan platformon por oportuna deplojo de klientpoentadfunkcioj kiuj povis funkcii kun rapida fluo de aplikoj, elteni pezajn ŝarĝojn, kaj la sistemo mem estis facile skalebla.
La tasko estas ne bagatela kaj solveblas multmaniere, kiel ni konvinkiĝis dum la pruvo de la finaj prezentoj de la projektoj de la partoprenantoj. Estis 6 teamoj de 5 homoj ĉe la hakatono, ĉiuj partoprenantoj havis bonajn projektojn, sed nia platformo montriĝis la plej konkurenciva. Ni havas tre interesan projekton, pri kiu mi ŝatus paroli en ĉi tiu artikolo.
Nia solvo estas platformo bazita sur Senservila arkitekturo ene de Kubernetes, kiu reduktas la tempon necesan por alporti novajn funkciojn al produktado. Ĝi permesas al analizistoj skribi kodon en medio oportuna por ili kaj deploji ĝin en produktadon sen la partopreno de inĝenieroj kaj programistoj.
Kio estas poentado
Tinkoff.ru, kiel multaj modernaj kompanioj, havas klientpoentadon. Poentado estas klienta taksa sistemo bazita sur statistikaj metodoj de datuma analizo.
Ekzemple, kliento turnas nin al ni kun peto doni al li prunton, aŭ malfermi individuan entreprenistkonton ĉe ni. Se ni planas doni al li prunton, tiam ni devas taksi lian solventecon, kaj se la konto estas individua entreprenisto, tiam ni devas esti certaj, ke la kliento ne faros fraŭdajn transakciojn.
La bazo por fari tiajn decidojn estas matematikaj modeloj, kiuj analizas kaj la datumojn de la aplikaĵo mem kaj la datumojn de nia stokado. Krom poentado, similaj statistikaj metodoj ankaŭ povas esti uzataj en la servo de generado de individuaj rekomendoj por novaj produktoj por niaj klientoj.
La metodo de tia taksado povas akcepti diversajn enigajn datumojn. Kaj iam ni povas aldoni novan parametron al la enigo, kiu, surbaze de la rezultoj de analizo pri historiaj datumoj, pliigos la konvertiĝon de uzado de la servo.
Ni tenas amason da datumoj pri klientaj rilatoj, kaj la volumo de ĉi tiu informo konstante kreskas. Por ke poentado funkciu, datuma prilaborado ankaŭ postulas regulojn (aŭ matematikajn modelojn), kiuj ebligas al vi rapide decidi, kiu aprobi aplikaĵon, kiun rifuzi kaj kiu oferti kelkajn pliajn produktojn, taksante ilian eblan intereson.
Por la nuna tasko ni jam uzas specialan decidsistemon , kiu, surbaze de la reguloj fiksitaj de analizistoj, teknologoj kaj programistoj, decidas ĉu aprobi aŭ rifuzi apartan bankprodukton al la kliento.
Estas multaj pretaj solvoj sur la merkato, kaj poentmodeloj kaj decidsistemoj mem. Ni uzas unu el ĉi tiuj sistemoj en nia kompanio. Sed la komerco kreskas, diversiĝas, kaj la nombro de klientoj kaj la nombro de ofertitaj produktoj pliiĝas, kaj kune kun tio aperas ideoj pri kiel plibonigi la ekzistantan decidprocezon. Certe homoj laborantaj kun la ekzistanta sistemo havas multajn ideojn pri kiel fari ĝin pli simpla, pli bona, pli oportuna, sed foje ideoj el ekstere utilas. La Nova Hackathon estis organizita kun la celo kolekti solidajn ideojn.
Tasko
La hakatono okazis la 23-an de februaro. Al la partoprenantoj estis proponitaj bataltasko: evoluigi decidsistemon, kiu devis plenumi kelkajn kondiĉojn.
Oni diris al ni kiel funkcias la ekzistanta sistemo kaj kiaj malfacilaĵoj aperas dum ĝia funkciado, kaj ankaŭ kiajn komercajn celojn la evoluinta platformo devas persekuti. La sistemo devas havi rapidan tempo-merkatigon por disvolvi regulojn por ke la laborkodo de analizistoj eniru en produktadon kiel eble plej rapide. Kaj por la envenanta fluo de aplikoj, la decida tempo devus tendenci al minimumo. Ankaŭ, la evolua sistemo devas havi kruc-vendajn kapablojn por doni al la kliento la ŝancon aĉeti aliajn firmaajn produktojn se ili estas aprobitaj de ni kaj havas potencialan intereson de la kliento.
Estas klare, ke estas neeble verki pretan eldonan projekton dum la nokto, kiu certe eniros en produktadon, kaj estas sufiĉe malfacile kovri la tutan sistemon, do ni petis efektivigi almenaŭ parton de ĝi. Kelkaj postuloj estis establitaj ke la prototipo devas kontentigi. Eblis provi ambaŭ kovri ĉiujn postulojn en ilia tuteco, kaj labori detale pri individuaj sekcioj de la evoluanta platformo.
Pri teknologio, ĉiuj partoprenantoj ricevis plenan liberecon de elekto. Eblis uzi iujn ajn konceptojn kaj teknologiojn: datumfluo, maŝinlernado, evento-provizado, grandaj datumoj kaj aliaj.
Nia solvo
Post iom da cerbumado, ni decidis, ke FaaS-solvo estus ideala por plenumi la taskon.
Por ĉi tiu solvo, estis necese trovi taŭgan Senservila kadro por efektivigi la regulojn de la evoluanta decidsistemo. Ĉar Tinkoff aktive uzas Kubernetes por infrastruktura administrado, ni rigardis plurajn pretajn solvojn bazitajn sur ĝi; mi rakontos al vi pli pri ĝi poste.
Por trovi la plej efikan solvon, ni rigardis la produkton disvolviĝantan per la okuloj de ĝiaj uzantoj. La ĉefaj uzantoj de nia sistemo estas analizistoj implikitaj en la disvolviĝo de reguloj. La reguloj devas esti deplojitaj al la servilo, aŭ, kiel en nia kazo, deplojitaj en la nubo, por posta decido. El la perspektivo de analizisto, la laborfluo aspektas jene:
- La analizisto skribas skripton, regulon aŭ ML-modelon bazitan sur datumoj de la magazeno. Kadre de la hackathon, ni decidis uzi Mongodb, sed la elekto de datumstokado ne gravas ĉi tie.
- Post testi la evoluintajn regulojn pri historiaj datumoj, la analizisto alŝutas sian kodon al la administra panelo.
- Por certigi versionadon, la tuta kodo iros al Git-deponejoj.
- Per la administra panelo eblos disfaldi la kodon en la nubo kiel aparta funkcia Senservila modulo.
Komencaj datumoj de klientoj devas trapasi specialan Riĉigan servon dizajnitan por riĉigi la komencan peton per datumoj de la magazeno. Estis grave efektivigi ĉi tiun servon tiel, ke ĝi funkcius kun ununura deponejo (de kiu la analizisto prenas datumojn dum disvolvado de reguloj) por konservi unuigitan datumstrukturon.
Eĉ antaŭ la hakatono, ni decidis pri la Senservila kadro, kiun ni uzus. Hodiaŭ estas sufiĉe multaj teknologioj sur la merkato, kiuj efektivigas ĉi tiun aliron. La plej popularaj solvoj ene de la Kubernetes-arkitekturo estas Fission, Open FaaS kaj Kubeless. Estas eĉ .
Pesinte ĉiujn avantaĝojn kaj malavantaĝojn, ni elektis . Ĉi tiu Senservila kadro estas sufiĉe facile administrebla kaj plenumas la postulojn de la tasko.
Por labori kun Fission, vi devas kompreni du bazajn konceptojn: funkcio kaj medio. Funkcio estas kodo skribita en unu el la lingvoj por kiuj ekzistas Fission-medio. inkluzivas Python, JS, Go, JVM kaj multajn aliajn popularajn lingvojn kaj teknologiojn.
Fisio ankaŭ kapablas plenumi funkciojn dividitajn en plurajn dosierojn, antaŭpakitajn en arkivon. La funkciado de Fission en Kubernetes-areo estas certigita per specialigitaj podoj, kiuj estas administritaj de la kadro mem. Por interagi kun grapolpodoj, ĉiu funkcio devas esti asignita sian propran itineron, kaj al kiu vi povas transdoni GET-parametrojn aŭ peti korpon en la kazo de POST-peto.
Kiel rezulto, ni planis akiri solvon, kiu permesus al analizistoj disfaldi evoluintajn regulskriptojn sen partopreno de inĝenieroj kaj programistoj. La priskribita aliro ankaŭ eliminas la bezonon por programistoj reverki analizistkodon en alian lingvon. Ekzemple, por la nuna decidsistemo, kiun ni uzas, ni devas skribi regulojn en tre specialigitaj teknologioj kaj lingvoj, kies amplekso estas ekstreme limigita, kaj ankaŭ estas forta dependeco de la aplikaĵoservilo, ĉar ĉiuj skizaj bankreguloj. estas deplojitaj en ununura medio. Kiel rezulto, por deploji novajn regulojn necesas liberigi la tutan sistemon.
En nia proponita solvo, ne necesas liberigi regulojn; la kodo povas esti facile deplojita per la klako de butono. Ankaŭ, infrastruktura administrado en Kubernetes permesas vin ne pensi pri ŝarĝo kaj skalo; tiaj problemoj estas solvitaj el la skatolo. Kaj la uzo de ununura datumstokejo forigas la bezonon kompari realtempajn datumojn kun historiaj datumoj, kio simpligas la laboron de la analizisto.
Kion ni ricevis
Ĉar ni venis al la hackathon kun preta solvo (en niaj fantazioj), nur ni devis fari ĉiujn niajn pensojn en liniojn de kodo.
La ŝlosilo al sukceso ĉe ajna hakatono estas preparo kaj bone skribita plano. Tial, la unua afero, kiun ni faris, estis decidi el kiuj moduloj konsistos nia sistema arkitekturo kaj kiajn teknologiojn ni uzus.
La arkitekturo de nia projekto estis jena:
Ĉi tiu diagramo montras du enirpunktojn, la analiziston (la ĉefa uzanto de nia sistemo) kaj la kliento.
La laborprocezo estas strukturita tiel. La analizisto disvolvas regulfunkcion kaj datumriĉigan funkcion por sia modelo, stokas sian kodon en Git-deponejo, kaj deplojas sian modelon al la nubo per la administra aplikaĵo. Ni konsideru kiel la deplojita funkcio estos nomita kaj prenu decidojn pri alvenantaj petoj de klientoj:
- La kliento plenigas formularon en la retejo kaj sendas sian peton al la regilo. Apliko pri kiu decido devas esti farita venas al la sistema enigo kaj estas registrita en la datumbazo en sia originala formo.
- Poste, la kruda peto estas sendita por riĉigo, se necese. Vi povas kompletigi la komencan peton per datumoj kaj de eksteraj servoj kaj de la stokado. La rezulta riĉigita demando ankaŭ estas konservita en la datumbazo.
- La analiza funkcio estas lanĉita, kiu prenas riĉigitan demandon kiel enigaĵon kaj produktas solvon, kiu ankaŭ estas skribita al la stokado.
Ni decidis uzi MongoDB kiel stokadon en nia sistemo pro la dokument-orientita stokado de datumoj en la formo de JSON-dokumentoj, ĉar la riĉigaj servoj, inkluzive de la originala peto, kunigis ĉiujn datumojn per REST-regiloj.
Do, ni havis XNUMX horojn por efektivigi la platformon. Ni sufiĉe sukcese distribuis la rolojn; ĉiu teamano havis sian propran respondecon en nia projekto:
- Antaŭfinaj administraj paneloj por la laboro de la analizisto, per kiuj li povis elŝuti regulojn de la versio-kontrolsistemo de skribitaj skriptoj, elekti opciojn por riĉigi enigajn datumojn kaj redakti regulskriptojn interrete.
- Backend-administranto, inkluzive de REST API por la fronto kaj integriĝo kun VCS.
- Starigante infrastrukturon en Google Cloud kaj evoluigante servon por riĉigi fontajn datumojn.
- Modulo por integri la administran aplikaĵon kun la Senservila kadro por posta deplojo de reguloj.
- Skriptoj de reguloj por provi la agadon de la tuta sistemo kaj agregado de analitiko pri envenantaj aplikoj (decidoj faritaj) por la fina pruvo.
Ni komencu en ordo.
Nia fasado estis skribita en Angular 7 uzante la bankan UI Kit. La fina versio de la administra panelo aspektis jene:
Ĉar estis malmulte da tempo, ni provis efektivigi nur la ŝlosilan funkcion. Por deploji funkcion en la Kubernetes-areo, estis necese elekti eventon (servon por kiu regulo devas esti deplojita en la nubo) kaj la kodon de la funkcio, kiu efektivigas la decidan logikon. Por ĉiu deplojo de regulo por la elektita servo, ni skribis protokolon de ĉi tiu evento. En la administra panelo vi povus vidi protokolojn de ĉiuj eventoj.
Ĉiu funkciokodo estis konservita en fora Git-deponejo, kiu ankaŭ devis esti agordita en la administra panelo. Por versio de la kodo, ĉiuj funkcioj estis stokitaj en malsamaj branĉoj de la deponejo. La administra panelo ankaŭ disponigas la kapablon fari ĝustigojn al skribitaj skriptoj, tiel ke antaŭ deploji funkcion al produktado, vi povas ne nur kontroli la skribitan kodon, sed ankaŭ fari la necesajn ŝanĝojn.
Krom la regulfunkcioj, ni ankaŭ efektivigis la kapablon iom post iom riĉigi la fontajn datumojn per Riĉigaj funkcioj, kies kodo estis ankaŭ skriptoj, en kiuj eblis iri al la datumstokejo, voki triajn servojn kaj plenumi antaŭajn kalkulojn. . Por pruvi nian solvon, ni kalkulis la zodiakan signon de la kliento, kiu forlasis la peton, kaj determinis sian moveblan telefoniston uzante trian REST-servon.
La malantaŭo de la platformo estis skribita en Java kaj efektivigita kiel Spring Boot-aplikaĵo. Ni komence planis uzi Postgres por stoki administrajn datumojn, sed, kadre de la hakatono, ni decidis limigi nin al simpla H2 por ŝpari tempon. En la malantaŭo, integriĝo kun Bitbucket estis efektivigita por versioni la demandajn riĉigajn funkciojn kaj regulskriptojn. Por integriĝo kun foraj Git-deponejoj, ni uzis , kiu estas speco de envolvaĵo super CLI-komandoj, permesante al vi ekzekuti ajnajn git-instrukciojn uzante oportunan programaran interfacon. Do ni havis du apartajn deponejojn por riĉigaj funkcioj kaj reguloj, kaj ĉiuj skriptoj estis dividitaj en dosierujojn. Per la UI eblis elekti la plej novan kommit de skripto de arbitra branĉo de la deponejo. Kiam oni faris ŝanĝojn al la kodo per la administra panelo, kommits de la ŝanĝita kodo estis kreitaj en foraj deponejoj.
Por efektivigi nian ideon, ni bezonis taŭgan infrastrukturon. Ni decidis disfaldi nian Kubernetes-grupon en la nubo. Nia elekto estis Google Cloud Platform. La senservila kadro Fission estis instalita sur Kubernetes-areto, kiun ni disfaldis en Gcloud. Komence, la fonta datuma riĉiga servo estis efektivigita kiel aparta Java-aplikaĵo envolvita en Pod ene de la k8s-areto. Sed post prepara pruvo de nia projekto meze de la hakatono, ni rekomendis igi la Riĉigan servon pli fleksebla por doni la ŝancon elekti kiel riĉigi la krudajn datumojn de envenantaj aplikoj. Kaj ni ne havis alian elekton ol fari la riĉigan servon ankaŭ Senservila.
Por labori kun Fission, ni uzis la Fission CLI, kiu devas esti instalita supre de la Kubernetes CLI. Deploji funkciojn en k8s-grupon estas sufiĉe simpla; vi nur bezonas asigni internan itineron kaj eniron al la funkcio por permesi envenantan trafikon se aliro ekster la areto estas necesa. Deploji unu funkcion kutime prenas ne pli ol 10 sekundojn.
Fina prezento de la projekto kaj resumo
Por pruvi kiel funkcias nia sistemo, ni metis simplan formularon en fora servilo, kie vi povas sendi peton por unu el la produktoj de la banko. Por peti, vi devis enigi viajn inicialojn, daton de naskiĝo kaj telefonnumeron.
Datumoj de la klientoformularo iris al la regilo, kiu samtempe sendis petojn por ĉiuj disponeblaj reguloj, antaŭe riĉigis la datumojn laŭ la specifitaj kondiĉoj, kaj konservis ilin en komuna stokado. Entute, ni deplojis tri funkciojn, kiuj faras decidojn pri envenantaj aplikoj kaj 4 datumoj-riĉigaj servoj. Post sendi la peton, la kliento ricevis nian decidon:
Krom rifuzo aŭ aprobo, la kliento ankaŭ ricevis liston de aliaj produktoj, petojn por kiuj ni sendis paralele. Jen kiel ni pruvis la eblecon de kruca vendo en nia platformo.
Ekzistis totalo de 3 fikciaj bankproduktoj haveblaj:
- Kredito.
- Ludilo
- Hipoteko.
Dum la manifestacio, ni deplojis pretajn funkciojn kaj riĉigajn skriptojn por ĉiu servo.
Ĉiu regulo postulis sian propran aron de enirdatenoj. Do, por aprobi hipotekon, ni kalkulis la zodiakan signon de la kliento kaj konektis ĉi tion kun la logiko de la luna kalendaro. Por aprobi ludilon, ni kontrolis, ke la kliento atingis la plimulton de aĝo, kaj por doni prunton, ni sendis peton al ekstera malferma servo por determini la ĉelan funkciigiston, kaj decido estis farita pri ĝi.
Ni provis fari nian demonstracion interesa kaj interaga, ĉiuj ĉeestantoj povis iri al nia formularo kaj kontroli la haveblecon de niaj fikciaj servoj al ili. Kaj ĉe la fino de la prezento, ni montris analizojn de ricevitaj aplikoj, kiuj montris kiom da homoj uzis nian servon, la nombron da aproboj kaj rifuzoj.
Por kolekti analizojn interrete, ni aldone deplojis malfermfontan BI-ilon kaj ŝraŭbis ĝin al nia stoka unuo. Metabazo permesas konstrui ekranojn kun analizoj pri la datumoj, kiuj interesas nin; vi nur bezonas registri konekton al la datumbazo, elekti tabelojn (en nia kazo, datumkolektojn, ĉar ni uzis MongoDB), kaj specifi la kampojn de intereso por ni. .
Rezulte, ni akiris bonan prototipon de decida platformo, kaj dum la demonstracio ĉiu aŭskultanto povis persone kontroli ĝian agadon. Interesa solvo, finita prototipo kaj sukcesa pruvo permesis al ni venki, malgraŭ forta konkurado de aliaj teamoj. Mi certas, ke ankaŭ interesa artikolo povas esti skribita pri la projekto de ĉiu teamo.
fonto: www.habr.com