Από πέρυσι, η εταιρεία μας άρχισε να διοργανώνει hackathons. Ο πρώτος τέτοιος διαγωνισμός ήταν πολύ επιτυχημένος, γράψαμε γι 'αυτό . Το δεύτερο hackathon πραγματοποιήθηκε τον Φεβρουάριο του 2019 και δεν ήταν λιγότερο επιτυχημένο. Σχετικά με τους στόχους της κράτησης του τελευταίου όχι πολύ καιρό πριν διοργανωτής.
Στους συμμετέχοντες δόθηκε μια αρκετά ενδιαφέρουσα εργασία με απόλυτη ελευθερία στην επιλογή μιας στοίβας τεχνολογίας για την υλοποίησή της. Ήταν απαραίτητο να εφαρμοστεί μια πλατφόρμα λήψης αποφάσεων για βολική ανάπτυξη των λειτουργιών βαθμολόγησης πελατών που θα μπορούσε να λειτουργήσει με γρήγορη ροή εφαρμογών, να αντέχει σε μεγάλα φορτία και το ίδιο το σύστημα ήταν εύκολα επεκτάσιμο.
Το έργο δεν είναι τετριμμένο και μπορεί να λυθεί με πολλούς τρόπους, όπως πειστήκαμε κατά την επίδειξη των τελικών παρουσιάσεων των έργων των συμμετεχόντων. Υπήρχαν 6 ομάδες των 5 ατόμων στο hackathon, όλοι οι συμμετέχοντες είχαν καλά έργα, αλλά η πλατφόρμα μας αποδείχθηκε η πιο ανταγωνιστική. Έχουμε ένα πολύ ενδιαφέρον έργο, για το οποίο θα ήθελα να μιλήσω σε αυτό το άρθρο.
Η λύση μας είναι μια πλατφόρμα βασισμένη στην αρχιτεκτονική χωρίς διακομιστή εντός του Kubernetes, η οποία μειώνει τον χρόνο που χρειάζεται για να φέρει νέες δυνατότητες στην παραγωγή. Επιτρέπει στους αναλυτές να γράφουν κώδικα σε ένα περιβάλλον βολικό για αυτούς και να τον αναπτύσσουν στην παραγωγή χωρίς τη συμμετοχή μηχανικών και προγραμματιστών.
Τι σκοράρει
Το Tinkoff.ru, όπως και πολλές σύγχρονες εταιρείες, έχει βαθμολογία πελατών. Η βαθμολογία είναι ένα σύστημα αξιολόγησης πελατών που βασίζεται σε στατιστικές μεθόδους ανάλυσης δεδομένων.
Για παράδειγμα, ένας πελάτης απευθύνεται σε εμάς ζητώντας του να του χορηγήσει δάνειο ή να ανοίξει έναν λογαριασμό ατομικού επιχειρηματία μαζί μας. Εάν σκοπεύουμε να του χορηγήσουμε δάνειο, τότε πρέπει να αξιολογήσουμε τη φερεγγυότητά του και εάν ο λογαριασμός είναι μεμονωμένος επιχειρηματίας, τότε πρέπει να είμαστε σίγουροι ότι ο πελάτης δεν θα πραγματοποιήσει δόλιες συναλλαγές.
Η βάση για τη λήψη τέτοιων αποφάσεων είναι μαθηματικά μοντέλα που αναλύουν τόσο τα δεδομένα από την ίδια την εφαρμογή όσο και τα δεδομένα από την αποθήκευσή μας. Εκτός από τη βαθμολόγηση, παρόμοιες στατιστικές μέθοδοι μπορούν επίσης να χρησιμοποιηθούν στην υπηρεσία της δημιουργίας μεμονωμένων συστάσεων για νέα προϊόντα για τους πελάτες μας.
Η μέθοδος μιας τέτοιας αξιολόγησης μπορεί να δεχθεί μια ποικιλία δεδομένων εισόδου. Και κάποια στιγμή μπορούμε να προσθέσουμε μια νέα παράμετρο στην είσοδο, η οποία, με βάση τα αποτελέσματα της ανάλυσης σε ιστορικά δεδομένα, θα αυξήσει το ποσοστό μετατροπής χρήσης της υπηρεσίας.
Διατηρούμε πληθώρα δεδομένων σχετικά με τις σχέσεις με τους πελάτες και ο όγκος αυτών των πληροφοριών αυξάνεται συνεχώς. Για να λειτουργήσει η βαθμολόγηση, η επεξεργασία δεδομένων απαιτεί επίσης κανόνες (ή μαθηματικά μοντέλα) που σας επιτρέπουν να αποφασίζετε γρήγορα ποιος θα εγκρίνει μια αίτηση, ποιος να αρνηθεί και ποιος να προσφέρει μερικά ακόμη προϊόντα, αξιολογώντας το πιθανό ενδιαφέρον τους.
Για τη συγκεκριμένη εργασία, χρησιμοποιούμε ήδη ένα εξειδικευμένο σύστημα λήψης αποφάσεων , το οποίο, βάσει των κανόνων που θέτουν οι αναλυτές, οι τεχνολόγοι και οι προγραμματιστές, αποφασίζει εάν θα εγκρίνει ή θα αρνηθεί ένα συγκεκριμένο τραπεζικό προϊόν στον πελάτη.
Υπάρχουν πολλές έτοιμες λύσεις στην αγορά, τόσο μοντέλα βαθμολόγησης όσο και τα ίδια τα συστήματα λήψης αποφάσεων. Χρησιμοποιούμε ένα από αυτά τα συστήματα στην εταιρεία μας. Αλλά η επιχείρηση αναπτύσσεται, διαφοροποιείται, τόσο ο αριθμός των πελατών όσο και ο αριθμός των προσφερόμενων προϊόντων αυξάνονται, και μαζί με αυτό, αναδύονται ιδέες για το πώς να βελτιωθεί η υπάρχουσα διαδικασία λήψης αποφάσεων. Σίγουρα οι άνθρωποι που εργάζονται με το υπάρχον σύστημα έχουν πολλές ιδέες για το πώς να το κάνουν πιο απλό, καλύτερο, πιο βολικό, αλλά μερικές φορές οι ιδέες από το εξωτερικό είναι χρήσιμες. Το New Hackathon διοργανώθηκε με στόχο τη συλλογή υγιών ιδεών.
Εργο
Το hackathon πραγματοποιήθηκε στις 23 Φεβρουαρίου. Στους συμμετέχοντες προσφέρθηκε ένα μαχητικό καθήκον: να αναπτύξουν ένα σύστημα λήψης αποφάσεων που έπρεπε να πληροί μια σειρά από προϋποθέσεις.
Μας είπαν πώς λειτουργεί το υπάρχον σύστημα και ποιες δυσκολίες προκύπτουν κατά τη λειτουργία του, καθώς και ποιους επιχειρηματικούς στόχους πρέπει να επιδιώκει η αναπτυγμένη πλατφόρμα. Το σύστημα πρέπει να έχει γρήγορο χρόνο για την ανάπτυξη κανόνων στην αγορά, έτσι ώστε ο κώδικας εργασίας των αναλυτών να μπει στην παραγωγή όσο το δυνατόν γρηγορότερα. Και για την εισερχόμενη ροή των αιτήσεων, ο χρόνος λήψης αποφάσεων θα πρέπει να τείνει στο ελάχιστο. Επίσης, το υπό ανάπτυξη σύστημα πρέπει να έχει δυνατότητες cross-sell ώστε να δίνεται στον πελάτη η ευκαιρία να αγοράσει άλλα προϊόντα της εταιρείας, εάν αυτά είναι εγκεκριμένα από εμάς και έχουν δυνητικό ενδιαφέρον από τον πελάτη.
Είναι σαφές ότι είναι αδύνατο να γραφτεί ένα έτοιμο προς κυκλοφορία έργο από τη μια μέρα στην άλλη που σίγουρα θα βγει στην παραγωγή και είναι αρκετά δύσκολο να καλύψει ολόκληρο το σύστημα, οπότε μας ζητήθηκε να υλοποιήσουμε τουλάχιστον ένα μέρος του. Ορίστηκαν ορισμένες απαιτήσεις που πρέπει να πληροί το πρωτότυπο. Ήταν δυνατό να προσπαθήσουμε τόσο να καλύψουμε όλες τις απαιτήσεις στο σύνολό τους όσο και να εργαστούμε λεπτομερώς σε επιμέρους τμήματα της πλατφόρμας που αναπτύσσεται.
Όσον αφορά την τεχνολογία, σε όλους τους συμμετέχοντες δόθηκε απόλυτη ελευθερία επιλογής. Ήταν δυνατή η χρήση οποιωνδήποτε εννοιών και τεχνολογιών: ροή δεδομένων, μηχανική εκμάθηση, προμήθεια συμβάντων, μεγάλα δεδομένα και άλλα.
Η λύση μας
Μετά από λίγο καταιγισμό ιδεών, αποφασίσαμε ότι μια λύση FaaS θα ήταν ιδανική για την ολοκλήρωση της εργασίας.
Για αυτή τη λύση, ήταν απαραίτητο να βρεθεί ένα κατάλληλο πλαίσιο χωρίς διακομιστή για την εφαρμογή των κανόνων του συστήματος λήψης αποφάσεων που αναπτύσσεται. Δεδομένου ότι ο Tinkoff χρησιμοποιεί ενεργά το Kubernetes για τη διαχείριση της υποδομής, εξετάσαμε διάφορες έτοιμες λύσεις που βασίζονται σε αυτό· θα σας πω περισσότερα για αυτό αργότερα.
Για να βρούμε την πιο αποτελεσματική λύση, εξετάσαμε το προϊόν που αναπτύσσεται μέσα από τα μάτια των χρηστών του. Οι κύριοι χρήστες του συστήματός μας είναι αναλυτές που ασχολούνται με την ανάπτυξη κανόνων. Οι κανόνες πρέπει να αναπτυχθούν στον διακομιστή ή, όπως στην περίπτωσή μας, να αναπτυχθούν στο cloud, για μεταγενέστερη λήψη αποφάσεων. Από την οπτική γωνία ενός αναλυτή, η ροή εργασίας μοιάζει με αυτό:
- Ο αναλυτής γράφει ένα σενάριο, έναν κανόνα ή ένα μοντέλο ML που βασίζεται σε δεδομένα από την αποθήκη. Ως μέρος του hackathon, αποφασίσαμε να χρησιμοποιήσουμε το Mongodb, αλλά η επιλογή του συστήματος αποθήκευσης δεδομένων δεν είναι σημαντική εδώ.
- Αφού δοκιμάσει τους αναπτυγμένους κανόνες για τα ιστορικά δεδομένα, ο αναλυτής ανεβάζει τον κώδικά του στον πίνακα διαχείρισης.
- Για να διασφαλιστεί η έκδοση, όλος ο κώδικας θα πάει στα αποθετήρια Git.
- Μέσω του πίνακα διαχείρισης θα είναι δυνατή η ανάπτυξη του κώδικα στο cloud ως ξεχωριστή λειτουργική μονάδα χωρίς διακομιστή.
Τα αρχικά δεδομένα από πελάτες πρέπει να περάσουν από μια εξειδικευμένη υπηρεσία εμπλουτισμού που έχει σχεδιαστεί για να εμπλουτίζει το αρχικό αίτημα με δεδομένα από την αποθήκη. Ήταν σημαντικό να εφαρμοστεί αυτή η υπηρεσία με τέτοιο τρόπο ώστε να λειτουργεί με ένα ενιαίο χώρο αποθήκευσης (από τον οποίο ο αναλυτής λαμβάνει δεδομένα κατά την ανάπτυξη κανόνων) για τη διατήρηση μιας ενοποιημένης δομής δεδομένων.
Ακόμη και πριν από το hackathon, αποφασίσαμε για το πλαίσιο χωρίς διακομιστή που θα χρησιμοποιούσαμε. Σήμερα, υπάρχουν πολλές τεχνολογίες στην αγορά που εφαρμόζουν αυτήν την προσέγγιση. Οι πιο δημοφιλείς λύσεις στην αρχιτεκτονική Kubernetes είναι το Fission, το Open FaaS και το Kubeless. Υπάρχουν μάλιστα .
Αφού ζυγίσαμε όλα τα υπέρ και τα κατά, επιλέξαμε . Αυτό το πλαίσιο χωρίς διακομιστή είναι αρκετά εύκολο στη διαχείριση και πληροί τις απαιτήσεις της εργασίας.
Για να εργαστείτε με το Fission, πρέπει να κατανοήσετε δύο βασικές έννοιες: λειτουργία και περιβάλλον. Μια συνάρτηση είναι ένα κομμάτι κώδικα γραμμένο σε μία από τις γλώσσες για τις οποίες υπάρχει περιβάλλον Fission. περιλαμβάνει Python, JS, Go, JVM και πολλές άλλες δημοφιλείς γλώσσες και τεχνολογίες.
Το Fission είναι επίσης ικανό να εκτελεί λειτουργίες χωρισμένες σε πολλά αρχεία, προσυσκευασμένα σε ένα αρχείο. Η λειτουργία του Fission σε ένα σύμπλεγμα Kubernetes διασφαλίζεται από εξειδικευμένα pods, τα οποία διαχειρίζεται το ίδιο το πλαίσιο. Για να αλληλεπιδράσετε με ομάδες ομάδων συμπλέγματος, σε κάθε συνάρτηση πρέπει να εκχωρηθεί η δική της διαδρομή και στην οποία μπορείτε να μεταβιβάσετε παραμέτρους GET ή σώμα αιτήματος στην περίπτωση αιτήματος POST.
Ως αποτέλεσμα, σχεδιάσαμε να αποκτήσουμε μια λύση που θα επέτρεπε στους αναλυτές να αναπτύξουν ανεπτυγμένα σενάρια κανόνων χωρίς τη συμμετοχή μηχανικών και προγραμματιστών. Η περιγραφόμενη προσέγγιση εξαλείφει επίσης την ανάγκη για τους προγραμματιστές να ξαναγράψουν τον κώδικα του αναλυτή σε άλλη γλώσσα. Για παράδειγμα, για το τρέχον σύστημα λήψης αποφάσεων που χρησιμοποιούμε, πρέπει να γράψουμε κανόνες σε εξαιρετικά εξειδικευμένες τεχνολογίες και γλώσσες, το εύρος των οποίων είναι εξαιρετικά περιορισμένο, και υπάρχει επίσης ισχυρή εξάρτηση από τον διακομιστή εφαρμογών, καθώς όλοι οι προσχέδιο τραπεζικών κανόνων αναπτύσσονται σε ένα ενιαίο περιβάλλον. Ως αποτέλεσμα, για την ανάπτυξη νέων κανόνων είναι απαραίτητο να απελευθερωθεί ολόκληρο το σύστημα.
Στην προτεινόμενη λύση μας, δεν υπάρχει ανάγκη απελευθέρωσης κανόνων· ο κώδικας μπορεί να αναπτυχθεί εύκολα με το πάτημα ενός κουμπιού. Επίσης, η διαχείριση υποδομής στο Kubernetes σάς επιτρέπει να μην σκέφτεστε τη φόρτωση και την κλιμάκωση· τέτοια προβλήματα επιλύονται από το κουτί. Και η χρήση μιας ενιαίας αποθήκης δεδομένων εξαλείφει την ανάγκη σύγκρισης δεδομένων σε πραγματικό χρόνο με ιστορικά δεδομένα, γεγονός που απλοποιεί το έργο του αναλυτή.
Αυτό που πήραμε
Αφού ήρθαμε στο hackathon με μια έτοιμη λύση (στις φαντασιώσεις μας), το μόνο που έπρεπε να κάνουμε ήταν να μετατρέψουμε όλες τις σκέψεις μας σε γραμμές κώδικα.
Το κλειδί της επιτυχίας σε κάθε hackathon είναι η προετοιμασία και ένα καλογραμμένο σχέδιο. Επομένως, το πρώτο πράγμα που κάναμε ήταν να αποφασίσουμε από ποιες μονάδες θα αποτελείται η αρχιτεκτονική του συστήματός μας και ποιες τεχνολογίες θα χρησιμοποιούσαμε.
Η αρχιτεκτονική του έργου μας ήταν η εξής:
Αυτό το διάγραμμα δείχνει δύο σημεία εισόδου, τον αναλυτή (ο κύριος χρήστης του συστήματός μας) και τον πελάτη.
Η διαδικασία εργασίας είναι δομημένη έτσι. Ο αναλυτής αναπτύσσει μια συνάρτηση κανόνα και μια συνάρτηση εμπλουτισμού δεδομένων για το μοντέλο του, αποθηκεύει τον κώδικά του σε ένα αποθετήριο Git και αναπτύσσει το μοντέλο του στο cloud μέσω της εφαρμογής διαχειριστή. Ας εξετάσουμε πώς θα κληθεί η αναπτυγμένη συνάρτηση και ας λάβουμε αποφάσεις σχετικά με τα εισερχόμενα αιτήματα από πελάτες:
- Ο πελάτης συμπληρώνει μια φόρμα στον ιστότοπο και στέλνει το αίτημά του στον υπεύθυνο επεξεργασίας. Μια εφαρμογή για την οποία πρέπει να ληφθεί μια απόφαση έρχεται στην είσοδο του συστήματος και καταγράφεται στη βάση δεδομένων στην αρχική της μορφή.
- Στη συνέχεια, το ακατέργαστο αίτημα αποστέλλεται για εμπλουτισμό, εάν είναι απαραίτητο. Μπορείτε να συμπληρώσετε το αρχικό αίτημα με δεδομένα τόσο από εξωτερικές υπηρεσίες όσο και από το χώρο αποθήκευσης. Το εμπλουτισμένο ερώτημα που προκύπτει αποθηκεύεται επίσης στη βάση δεδομένων.
- Εκκινείται η συνάρτηση αναλυτής, η οποία λαμβάνει ως είσοδο ένα εμπλουτισμένο ερώτημα και παράγει μια λύση, η οποία επίσης εγγράφεται στο χώρο αποθήκευσης.
Αποφασίσαμε να χρησιμοποιήσουμε το MongoDB ως χώρο αποθήκευσης στο σύστημά μας λόγω της αποθήκευσης δεδομένων με βάση τα έγγραφα με τη μορφή εγγράφων JSON, καθώς οι υπηρεσίες εμπλουτισμού, συμπεριλαμβανομένου του αρχικού αιτήματος, συγκεντρώνουν όλα τα δεδομένα μέσω των ελεγκτών REST.
Έτσι, είχαμε XNUMX ώρες για να εφαρμόσουμε την πλατφόρμα. Διανείμαμε τους ρόλους με μεγάλη επιτυχία· κάθε μέλος της ομάδας είχε τη δική του περιοχή ευθύνης στο έργο μας:
- Πίνακες διαχειριστή front-end για την εργασία του αναλυτή, μέσω των οποίων μπορούσε να κατεβάσει κανόνες από το σύστημα ελέγχου έκδοσης γραπτών σεναρίων, να επιλέξει επιλογές για τον εμπλουτισμό δεδομένων εισόδου και να επεξεργαστεί σενάρια κανόνων στο διαδίκτυο.
- Διαχειριστής Backend, συμπεριλαμβανομένου του REST API για το μπροστινό μέρος και ενσωμάτωσης με VCS.
- Ρύθμιση υποδομής στο Google Cloud και ανάπτυξη υπηρεσίας για τον εμπλουτισμό των δεδομένων πηγής.
- Μια ενότητα για την ενοποίηση της εφαρμογής διαχειριστή με το πλαίσιο χωρίς διακομιστή για επακόλουθη ανάπτυξη κανόνων.
- Σενάρια κανόνων για τον έλεγχο της απόδοσης ολόκληρου του συστήματος και συνάθροιση αναλυτικών στοιχείων σε εισερχόμενες εφαρμογές (αποφάσεις που ελήφθησαν) για την τελική επίδειξη.
Ας ξεκινήσουμε με τη σειρά.
Το frontend μας γράφτηκε στο Angular 7 χρησιμοποιώντας το τραπεζικό κιτ διεπαφής χρήστη. Η τελική έκδοση του πίνακα διαχείρισης φαινόταν ως εξής:
Επειδή ο χρόνος ήταν λίγος, προσπαθήσαμε να εφαρμόσουμε μόνο τη βασική λειτουργικότητα. Για την ανάπτυξη μιας συνάρτησης σε ένα σύμπλεγμα Kubernetes, ήταν απαραίτητο να επιλέξετε ένα συμβάν (μια υπηρεσία για την οποία πρέπει να αναπτυχθεί ένας κανόνας στο cloud) και ο κωδικός της συνάρτησης που εφαρμόζει τη λογική λήψης αποφάσεων. Για κάθε ανάπτυξη ενός κανόνα για την επιλεγμένη υπηρεσία, γράψαμε ένα αρχείο καταγραφής αυτού του συμβάντος. Στον πίνακα διαχείρισης θα μπορούσατε να δείτε αρχεία καταγραφής όλων των συμβάντων.
Όλος ο κώδικας λειτουργίας αποθηκεύτηκε σε ένα απομακρυσμένο αποθετήριο Git, το οποίο έπρεπε επίσης να ρυθμιστεί στον πίνακα διαχείρισης. Για την έκδοση του κώδικα, όλες οι συναρτήσεις αποθηκεύτηκαν σε διαφορετικούς κλάδους του αποθετηρίου. Ο πίνακας διαχείρισης παρέχει επίσης τη δυνατότητα να κάνετε προσαρμογές σε γραπτά σενάρια, έτσι ώστε πριν από την ανάπτυξη μιας συνάρτησης στην παραγωγή, να μπορείτε όχι μόνο να ελέγξετε τον γραπτό κώδικα, αλλά και να κάνετε τις απαραίτητες αλλαγές.
Εκτός από τις λειτουργίες κανόνων, εφαρμόσαμε επίσης τη δυνατότητα σταδιακού εμπλουτισμού των δεδομένων πηγής χρησιμοποιώντας λειτουργίες εμπλουτισμού, ο κώδικας των οποίων ήταν επίσης σενάρια στα οποία ήταν δυνατή η μετάβαση στην αποθήκη δεδομένων, η κλήση υπηρεσιών τρίτων και η εκτέλεση προκαταρκτικών υπολογισμών . Για να δείξουμε τη λύση μας, υπολογίσαμε το ζώδιο του πελάτη που εγκατέλειψε το αίτημα και προσδιορίσαμε τον πάροχο κινητής τηλεφωνίας του χρησιμοποιώντας μια υπηρεσία REST τρίτων.
Το backend της πλατφόρμας γράφτηκε σε Java και υλοποιήθηκε ως εφαρμογή Spring Boot. Αρχικά σχεδιάζαμε να χρησιμοποιήσουμε το Postgres για την αποθήκευση δεδομένων διαχειριστή, αλλά, ως μέρος του hackathon, αποφασίσαμε να περιοριστούμε σε ένα απλό H2 για να εξοικονομήσουμε χρόνο. Στο backend, η ενοποίηση με το Bitbucket υλοποιήθηκε για την έκδοση των συναρτήσεων εμπλουτισμού ερωτημάτων και των σεναρίων κανόνων. Για ενσωμάτωση με απομακρυσμένα αποθετήρια Git, χρησιμοποιήσαμε , το οποίο είναι ένα είδος περιτυλίγματος πάνω από εντολές CLI, που σας επιτρέπει να εκτελέσετε οποιεσδήποτε οδηγίες git χρησιμοποιώντας μια βολική διεπαφή λογισμικού. Έτσι, είχαμε δύο ξεχωριστά αποθετήρια για λειτουργίες εμπλουτισμού και κανόνες, και όλα τα σενάρια χωρίστηκαν σε καταλόγους. Μέσω της διεπαφής χρήστη ήταν δυνατή η επιλογή της πιο πρόσφατης δέσμευσης ενός σεναρίου ενός αυθαίρετου κλάδου του αποθετηρίου. Κατά την πραγματοποίηση αλλαγών στον κώδικα μέσω του πίνακα διαχείρισης, δημιουργήθηκαν δεσμεύσεις του αλλαγμένου κώδικα σε απομακρυσμένα αποθετήρια.
Για να υλοποιήσουμε την ιδέα μας χρειαζόμασταν κατάλληλες υποδομές. Αποφασίσαμε να αναπτύξουμε το σύμπλεγμα Kubernetes στο σύννεφο. Η επιλογή μας ήταν η Google Cloud Platform. Το πλαίσιο χωρίς διακομιστή Fission εγκαταστάθηκε σε ένα σύμπλεγμα Kubernetes, το οποίο αναπτύξαμε στο Gcloud. Αρχικά, η υπηρεσία εμπλουτισμού δεδομένων πηγής υλοποιήθηκε ως ξεχωριστή εφαρμογή Java τυλιγμένη σε ένα Pod μέσα στο σύμπλεγμα k8s. Αλλά μετά από μια προκαταρκτική επίδειξη του έργου μας στη μέση του hackathon, μας προτάθηκε να κάνουμε την υπηρεσία Εμπλουτισμού πιο ευέλικτη για να παρέχουμε την ευκαιρία να επιλέξουμε πώς θα εμπλουτίσουμε τα πρωτογενή δεδομένα των εισερχόμενων εφαρμογών. Και δεν είχαμε άλλη επιλογή από το να κάνουμε την υπηρεσία εμπλουτισμού επίσης χωρίς διακομιστή.
Για να δουλέψουμε με το Fission, χρησιμοποιήσαμε το Fission CLI, το οποίο πρέπει να εγκατασταθεί πάνω από το Kubernetes CLI. Η ανάπτυξη συναρτήσεων σε ένα σύμπλεγμα k8s είναι αρκετά απλή· απλώς χρειάζεται να αντιστοιχίσετε μια εσωτερική διαδρομή και είσοδο στη συνάρτηση για να επιτρέψετε την εισερχόμενη κίνηση εάν απαιτείται πρόσβαση εκτός του συμπλέγματος. Η ανάπτυξη μιας λειτουργίας συνήθως δεν διαρκεί περισσότερο από 10 δευτερόλεπτα.
Τελική παρουσίαση του έργου και περίληψη
Για να δείξουμε πώς λειτουργεί το σύστημά μας, έχουμε τοποθετήσει μια απλή φόρμα σε έναν απομακρυσμένο διακομιστή όπου μπορείτε να υποβάλετε μια αίτηση για ένα από τα προϊόντα της τράπεζας. Για να ζητήσετε, έπρεπε να εισαγάγετε τα αρχικά, την ημερομηνία γέννησης και τον αριθμό τηλεφώνου σας.
Τα δεδομένα από τη φόρμα πελάτη πήγαν στον ελεγκτή, ο οποίος έστελνε ταυτόχρονα αιτήματα για όλους τους διαθέσιμους κανόνες, έχοντας προηγουμένως εμπλουτίσει τα δεδομένα σύμφωνα με τις καθορισμένες συνθήκες και τα είχε αποθηκεύσει σε κοινό χώρο αποθήκευσης. Συνολικά, αναπτύξαμε τρεις λειτουργίες που λαμβάνουν αποφάσεις για εισερχόμενες εφαρμογές και 4 υπηρεσίες εμπλουτισμού δεδομένων. Μετά την υποβολή της αίτησης, ο πελάτης έλαβε την απόφασή μας:
Εκτός από την άρνηση ή την έγκριση, ο πελάτης έλαβε επίσης μια λίστα με άλλα προϊόντα, αιτήματα για τα οποία στείλαμε παράλληλα. Έτσι αποδείξαμε τη δυνατότητα cross-sale στην πλατφόρμα μας.
Συνολικά, ήταν διαθέσιμα 3 εικονικά τραπεζικά προϊόντα:
- Πίστωση.
- παιχνίδι
- Στεγαστικών δανείων.
Κατά τη διάρκεια της επίδειξης, αναπτύξαμε προετοιμασμένες λειτουργίες και σενάρια εμπλουτισμού για κάθε υπηρεσία.
Κάθε κανόνας απαιτούσε το δικό του σύνολο δεδομένων εισόδου. Έτσι, για να εγκρίνουμε μια υποθήκη, υπολογίσαμε το ζώδιο του πελάτη και το συνδέσαμε με τη λογική του σεληνιακού ημερολογίου. Για να εγκρίνουμε ένα παιχνίδι, ελέγξαμε ότι ο πελάτης είχε συμπληρώσει την ηλικία της ενηλικίωσης και για την έκδοση δανείου, στείλαμε ένα αίτημα σε εξωτερική ανοιχτή υπηρεσία για τον προσδιορισμό του φορέα εκμετάλλευσης κινητής τηλεφωνίας και λήφθηκε σχετική απόφαση.
Προσπαθήσαμε να κάνουμε την επίδειξή μας ενδιαφέρουσα και διαδραστική, όλοι οι παρόντες μπορούσαν να πάνε στη φόρμα μας και να ελέγξουν τη διαθεσιμότητα των φανταστικών υπηρεσιών μας σε αυτούς. Και στο τέλος της παρουσίασης, δείξαμε αναλυτικά στοιχεία των αιτήσεων που ελήφθησαν, τα οποία έδειξαν πόσα άτομα χρησιμοποίησαν την υπηρεσία μας, τον αριθμό των εγκρίσεων και τις αρνήσεις.
Για τη συλλογή αναλυτικών στοιχείων στο διαδίκτυο, αναπτύξαμε επιπλέον ένα εργαλείο ανοιχτού κώδικα BI και το βίδωσε στη μονάδα αποθήκευσης μας. Το Metabase σάς επιτρέπει να δημιουργείτε οθόνες με αναλυτικά στοιχεία για τα δεδομένα που μας ενδιαφέρουν, απλά πρέπει να καταχωρίσετε μια σύνδεση με τη βάση δεδομένων, να επιλέξετε πίνακες (στην περίπτωσή μας, συλλογές δεδομένων, αφού χρησιμοποιήσαμε MongoDB) και να καθορίσετε τα πεδία που μας ενδιαφέρουν .
Ως αποτέλεσμα, αποκτήσαμε ένα καλό πρωτότυπο μιας πλατφόρμας λήψης αποφάσεων και κατά τη διάρκεια της επίδειξης, κάθε ακροατής μπορούσε να ελέγξει προσωπικά την απόδοσή της. Μια ενδιαφέρουσα λύση, ένα ολοκληρωμένο πρωτότυπο και μια επιτυχημένη επίδειξη μας επέτρεψαν να κερδίσουμε, παρά τον ισχυρό ανταγωνισμό από άλλες ομάδες. Είμαι βέβαιος ότι ένα ενδιαφέρον άρθρο μπορεί επίσης να γραφτεί για το έργο κάθε ομάδας.
Πηγή: www.habr.com