Mikhail Salosin (εφεξής – MS): - Γεια σε όλους! Με λένε μιχάλη. Εργάζομαι ως προγραμματιστής υποστήριξης στην MC2 Software και θα μιλήσω για τη χρήση του Go στο backend της εφαρμογής για κινητά Look+.
Αγαπάει κανείς εδώ το χόκεϊ;
Τότε αυτή η εφαρμογή είναι για εσάς. Είναι για Android και iOS και χρησιμοποιείται για την παρακολούθηση εκπομπών διαφόρων αθλητικών γεγονότων online και ηχογραφημένες. Η εφαρμογή περιέχει επίσης διάφορα στατιστικά στοιχεία, εκπομπές κειμένου, πίνακες για συνέδρια, τουρνουά και άλλες χρήσιμες πληροφορίες για τους θαυμαστές.
Επίσης στην εφαρμογή υπάρχει κάτι όπως στιγμές βίντεο, δηλαδή μπορείτε να παρακολουθήσετε τις πιο σημαντικές στιγμές των αγώνων (γκόλ, μάχες, σουτ κ.λπ.). Εάν δεν θέλετε να παρακολουθήσετε ολόκληρη την εκπομπή, μπορείτε να παρακολουθήσετε μόνο τις πιο ενδιαφέρουσες.
Τι χρησιμοποιήσατε στην ανάπτυξη;
Το κύριο μέρος γράφτηκε στο Go. Το API με το οποίο επικοινωνούσαν οι πελάτες κινητών ήταν γραμμένο στο Go. Στο Go γράφτηκε και υπηρεσία αποστολής ειδοποιήσεων push σε κινητά τηλέφωνα. Έπρεπε επίσης να γράψουμε το δικό μας ORM, για το οποίο θα μπορούσαμε να μιλήσουμε κάποια μέρα. Λοιπόν, μερικές μικρές υπηρεσίες γράφτηκαν στο Go: αλλαγή μεγέθους και φόρτωση εικόνων για τους συντάκτες...
Χρησιμοποιήσαμε την PostgreSQL ως βάση δεδομένων. Η διεπαφή του επεξεργαστή γράφτηκε σε Ruby on Rails χρησιμοποιώντας το στολίδι ActiveAdmin. Η εισαγωγή στατιστικών από έναν πάροχο στατιστικών είναι επίσης γραμμένη σε Ruby.
Για δοκιμές API συστήματος, χρησιμοποιήσαμε Python unittest. Το Memcached χρησιμοποιείται για τον περιορισμό των κλήσεων πληρωμής API, το "Chef" χρησιμοποιείται για τον έλεγχο της διαμόρφωσης, το Zabbix χρησιμοποιείται για τη συλλογή και την παρακολούθηση στατιστικών εσωτερικού συστήματος. Το Graylog2 είναι για συλλογή αρχείων καταγραφής, το Slate είναι τεκμηρίωση API για πελάτες.
Επιλογή πρωτοκόλλου
Το πρώτο πρόβλημα που αντιμετωπίσαμε: έπρεπε να επιλέξουμε ένα πρωτόκολλο για την αλληλεπίδραση μεταξύ του backend και των πελατών για κινητά, με βάση τα ακόλουθα σημεία...
- Η πιο σημαντική απαίτηση: τα δεδομένα για τους πελάτες πρέπει να ενημερώνονται σε πραγματικό χρόνο. Δηλαδή, όλοι όσοι παρακολουθούν αυτήν τη στιγμή την εκπομπή θα πρέπει να λαμβάνουν ενημερώσεις σχεδόν αμέσως.
- Για να απλοποιήσουμε τα πράγματα, υποθέσαμε ότι τα δεδομένα που συγχρονίζονται με τους πελάτες δεν διαγράφονται, αλλά κρύβονται χρησιμοποιώντας ειδικές σημαίες.
- Όλα τα είδη των σπάνιων αιτημάτων (όπως στατιστικά στοιχεία, συνθέσεις ομάδων, στατιστικά ομάδας) λαμβάνονται με συνηθισμένα αιτήματα GET.
- Επιπλέον, το σύστημα έπρεπε να υποστηρίζει εύκολα 100 χιλιάδες χρήστες ταυτόχρονα.
Με βάση αυτό, είχαμε δύο επιλογές πρωτοκόλλου:
- Υποδοχές Ιστού. Αλλά δεν χρειαζόμασταν κανάλια από τον πελάτη στον διακομιστή. Χρειαζόμασταν μόνο να στείλουμε ενημερώσεις από τον διακομιστή στον υπολογιστή-πελάτη, επομένως το websocket είναι μια περιττή επιλογή.
- Τα συμβάντα αποστολής διακομιστή (SSE) εμφανίστηκαν σωστά! Είναι αρκετά απλό και ουσιαστικά ικανοποιεί όλα όσα χρειαζόμαστε.
Εκδηλώσεις που απεστάλησαν από διακομιστή
Λίγα λόγια για το πώς λειτουργεί αυτό το πράγμα...
Λειτουργεί πάνω από μια σύνδεση http. Ο πελάτης στέλνει ένα αίτημα, ο διακομιστής απαντά με Content-Type: text/event-stream και δεν κλείνει τη σύνδεση με τον πελάτη, αλλά συνεχίζει να γράφει δεδομένα στη σύνδεση:
Τα δεδομένα μπορούν να αποσταλούν σε μορφή που έχει συμφωνηθεί με τους πελάτες. Στην περίπτωσή μας, το στείλαμε με αυτή τη μορφή: το όνομα της αλλαγμένης δομής (άτομο, παίκτης) στάλθηκε στο πεδίο συμβάντος και το JSON με νέα, αλλαγμένα πεδία για το πρόγραμμα αναπαραγωγής στάλθηκε στο πεδίο δεδομένων.
Τώρα ας μιλήσουμε για το πώς λειτουργεί η ίδια η αλληλεπίδραση.
- Το πρώτο πράγμα που κάνει ο πελάτης είναι να προσδιορίσει την τελευταία φορά που πραγματοποιήθηκε ο συγχρονισμός με την υπηρεσία: εξετάζει την τοπική βάση δεδομένων του και καθορίζει την ημερομηνία της τελευταίας αλλαγής που καταγράφηκε από αυτόν.
- Στέλνει ένα αίτημα με αυτήν την ημερομηνία.
- Σε απάντηση, του στέλνουμε όλες τις ενημερώσεις που έχουν συμβεί από εκείνη την ημερομηνία.
- Μετά από αυτό, συνδέεται με το ζωντανό κανάλι και δεν κλείνει μέχρι να χρειαστεί αυτές τις ενημερώσεις:
Του στέλνουμε μια λίστα αλλαγών: αν κάποιος σκοράρει, αλλάζουμε το σκορ του αγώνα, αν τραυματιστεί, στέλνεται και αυτό σε πραγματικό χρόνο. Έτσι, οι πελάτες λαμβάνουν άμεσα ενημερωμένα δεδομένα στη ροή συμβάντων αντιστοίχισης. Περιοδικά, για να καταλάβει ο πελάτης ότι ο διακομιστής δεν έχει πεθάνει, ότι δεν του συνέβη τίποτα, στέλνουμε μια χρονική σήμανση κάθε 15 δευτερόλεπτα - ώστε να γνωρίζει ότι όλα είναι εντάξει και δεν χρειάζεται να επανασυνδεθεί.
Πώς εξυπηρετείται η ζωντανή σύνδεση;
- Πρώτα απ 'όλα, δημιουργούμε ένα κανάλι στο οποίο θα λαμβάνονται ενημερώσεις προσωρινής αποθήκευσης.
- Μετά από αυτό, εγγραφούμε σε αυτό το κανάλι για να λαμβάνουμε ενημερώσεις.
- Ορίσαμε τη σωστή κεφαλίδα έτσι ώστε ο πελάτης να γνωρίζει ότι όλα είναι εντάξει.
- Στείλτε το πρώτο ping. Απλώς καταγράφουμε την τρέχουσα χρονική σήμανση σύνδεσης.
- Μετά από αυτό, διαβάζουμε από το κανάλι σε βρόχο μέχρι να κλείσει το κανάλι ενημέρωσης. Το κανάλι λαμβάνει περιοδικά είτε την τρέχουσα χρονική σήμανση είτε αλλαγές που ήδη γράφουμε για να ανοίξουμε συνδέσεις.
Το πρώτο πρόβλημα που αντιμετωπίσαμε ήταν το εξής: για κάθε σύνδεση που άνοιγε με τον πελάτη, δημιουργήσαμε ένα χρονόμετρο που χτυπούσε μία φορά κάθε 15 δευτερόλεπτα - αποδεικνύεται ότι αν είχαμε 6 χιλιάδες συνδέσεις ανοιχτές με ένα μηχάνημα (με έναν διακομιστή API), 6 δημιουργήθηκαν χιλιάδες χρονόμετρα. Αυτό οδήγησε στο μηχάνημα να μην συγκρατεί το απαιτούμενο φορτίο. Το πρόβλημα δεν ήταν τόσο προφανές σε εμάς, αλλά πήραμε μια μικρή βοήθεια και το διορθώσαμε.
Ως αποτέλεσμα, τώρα το ping μας προέρχεται από το ίδιο κανάλι από το οποίο προέρχεται η ενημέρωση.
Αντίστοιχα, υπάρχει μόνο ένας χρονοδιακόπτης που χτυπάει μία φορά κάθε 15 δευτερόλεπτα.
Υπάρχουν πολλές βοηθητικές λειτουργίες εδώ - αποστολή της κεφαλίδας, του ping και της ίδιας της δομής. Δηλαδή, το όνομα του πίνακα (άτομο, αγώνας, σεζόν) και οι πληροφορίες σχετικά με αυτήν την καταχώρηση μεταδίδονται εδώ:
Μηχανισμός αποστολής ενημερώσεων
Τώρα λίγο για το από πού προέρχονται οι αλλαγές. Έχουμε αρκετούς, συντάκτες, που παρακολουθούν την εκπομπή σε πραγματικό χρόνο. Δημιουργούν όλα τα γεγονότα: κάποιος αποβλήθηκε, κάποιος τραυματίστηκε, κάποιο είδος αντικατάστασης...
Χρησιμοποιώντας ένα CMS, τα δεδομένα εισέρχονται στη βάση δεδομένων. Μετά από αυτό, η βάση δεδομένων ειδοποιεί σχετικά τους διακομιστές API χρησιμοποιώντας τον μηχανισμό Listen/Notify. Οι διακομιστές API στέλνουν ήδη αυτές τις πληροφορίες σε πελάτες. Έτσι, ουσιαστικά έχουμε μόνο λίγους διακομιστές συνδεδεμένους στη βάση δεδομένων και δεν υπάρχει ειδικό φορτίο στη βάση δεδομένων, επειδή ο πελάτης δεν αλληλεπιδρά απευθείας με τη βάση δεδομένων με κανέναν τρόπο:
PostgreSQL: Ακούστε/Ειδοποιήστε
Ο μηχανισμός Listen/Notify στο Postgres σάς επιτρέπει να ειδοποιείτε τους συνδρομητές συμβάντων ότι κάποιο συμβάν έχει αλλάξει - κάποια εγγραφή έχει δημιουργηθεί στη βάση δεδομένων. Για να γίνει αυτό, γράψαμε μια απλή σκανδάλη και λειτουργία:
Κατά την εισαγωγή ή την αλλαγή μιας εγγραφής, καλούμε τη συνάρτηση ειδοποίησης στο κανάλι data_updates, περνώντας εκεί το όνομα του πίνακα και το αναγνωριστικό της εγγραφής που άλλαξε ή εισήχθη.
Για όλους τους πίνακες που πρέπει να συγχρονιστούν με τον πελάτη, ορίζουμε ένα έναυσμα, το οποίο, μετά την αλλαγή / ενημέρωση μιας εγγραφής, καλεί τη συνάρτηση που υποδεικνύεται στην παρακάτω διαφάνεια.
Πώς εγγράφεται το API σε αυτές τις αλλαγές;
Δημιουργείται ένας μηχανισμός Fanout - στέλνει μηνύματα στον πελάτη. Συλλέγει όλα τα κανάλια πελατών και στέλνει ενημερώσεις που έλαβε μέσω αυτών των καναλιών:
Εδώ η τυπική βιβλιοθήκη pq, που συνδέεται με τη βάση δεδομένων και λέει ότι θέλει να ακούσει το κανάλι (data_updates), ελέγχει ότι η σύνδεση είναι ανοιχτή και όλα είναι καλά. Παραλείπω τον έλεγχο σφαλμάτων για εξοικονόμηση χώρου (το μη έλεγχος είναι επικίνδυνο).
Στη συνέχεια, ρυθμίζουμε ασύγχρονα το Ticker, το οποίο θα στέλνει ένα ping κάθε 15 δευτερόλεπτα και ξεκινάμε να ακούμε το κανάλι στο οποίο εγγραφήκαμε. Εάν λάβουμε ένα ping, δημοσιεύουμε αυτό το ping. Εάν λάβουμε κάποιο είδος καταχώρισης, τότε δημοσιεύουμε αυτήν την καταχώριση σε όλους τους συνδρομητές αυτού του Fanout.
Πώς λειτουργεί το Fan-out;
Στα ρωσικά αυτό μεταφράζεται ως "διαιρέτης". Έχουμε ένα αντικείμενο που καταγράφει συνδρομητές που θέλουν να λαμβάνουν κάποιες ενημερώσεις. Και μόλις φτάσει μια ενημέρωση σε αυτό το αντικείμενο, διανέμει αυτήν την ενημέρωση σε όλους τους συνδρομητές του. Αρκετά απλό:
Πώς εφαρμόζεται στο Go:
Υπάρχει μια δομή, συγχρονίζεται χρησιμοποιώντας Mutexes. Διαθέτει ένα πεδίο που αποθηκεύει την κατάσταση σύνδεσης του Fanout με τη βάση δεδομένων, δηλαδή ακούει αυτήν τη στιγμή και θα λαμβάνει ενημερώσεις, καθώς και μια λίστα με όλα τα διαθέσιμα κανάλια - χάρτη, το κλειδί του οποίου είναι το κανάλι και η δομή με τη μορφή τιμές (ουσιαστικά δεν χρησιμοποιείται με κανέναν τρόπο).
Δύο μέθοδοι - Συνδεδεμένη και Αποσυνδεδεμένη - μας επιτρέπουν να πούμε στο Fanout ότι έχουμε σύνδεση με τη βάση, εμφανίστηκε και ότι η σύνδεση με τη βάση έχει διακοπεί. Στη δεύτερη περίπτωση, πρέπει να αποσυνδέσετε όλους τους πελάτες και να τους πείτε ότι δεν μπορούν πλέον να ακούσουν τίποτα και ότι επανασυνδέονται επειδή η σύνδεση με αυτούς έχει κλείσει.
Υπάρχει επίσης μια μέθοδος εγγραφής που προσθέτει το κανάλι στους "ακροατές":
Υπάρχει μια μέθοδος Unsubscribe, η οποία αφαιρεί το κανάλι από τους ακροατές εάν ο πελάτης αποσυνδεθεί, καθώς και μια μέθοδος Publish, η οποία σας επιτρέπει να στείλετε ένα μήνυμα σε όλους τους συνδρομητές.
Ερώτηση: – Τι μεταδίδεται μέσω αυτού του καναλιού;
ΚΥΡΙΑ: – Το μοντέλο που άλλαξε ή το ping μεταδίδεται (ουσιαστικά απλώς ένας αριθμός, ακέραιος).
ΚΥΡΙΑ: – Μπορείτε να στείλετε οτιδήποτε, να στείλετε οποιαδήποτε δομή, να το δημοσιεύσετε – απλώς μετατρέπεται σε JSON και αυτό είναι.
ΚΥΡΙΑ: – Λαμβάνουμε μια ειδοποίηση από την Postgres – περιέχει το όνομα του πίνακα και το αναγνωριστικό. Με βάση το όνομα και το αναγνωριστικό του πίνακα, λαμβάνουμε την εγγραφή που χρειαζόμαστε και, στη συνέχεια, στέλνουμε αυτήν τη δομή για δημοσίευση.
Υποδομή
Πώς φαίνεται αυτό από την άποψη της υποδομής; Έχουμε 7 διακομιστές υλικού: ένας από αυτούς είναι πλήρως αφιερωμένος στη βάση δεδομένων, ενώ οι άλλοι έξι λειτουργούν εικονικές μηχανές. Υπάρχουν 6 αντίγραφα του API: κάθε εικονική μηχανή με το API εκτελείται σε ξεχωριστό διακομιστή υλικού - αυτό είναι για λόγους αξιοπιστίας.
Έχουμε δύο frontend με εγκατεστημένο το Keepalived για βελτίωση της προσβασιμότητας, έτσι ώστε αν συμβεί κάτι, το ένα frontend μπορεί να αντικαταστήσει το άλλο. Επίσης – δύο αντίγραφα του CMS.
Υπάρχει και εισαγωγέας στατιστικών. Υπάρχει ένα DB Slave από το οποίο δημιουργούνται περιοδικά αντίγραφα ασφαλείας. Υπάρχει το Pigeon Pusher, μια εφαρμογή που στέλνει ειδοποιήσεις push στους πελάτες, καθώς και πράγματα υποδομής: Zabbix, Graylog2 και Chef.
Στην πραγματικότητα, αυτή η υποδομή είναι περιττή, γιατί 100 χιλιάδες μπορούν να εξυπηρετηθούν με λιγότερους διακομιστές. Αλλά υπήρχε σίδερο - το χρησιμοποιήσαμε (μας είπαν ότι ήταν δυνατό - γιατί όχι).
Πλεονεκτήματα του Go
Αφού δουλέψαμε σε αυτήν την εφαρμογή, προέκυψαν τέτοια προφανή πλεονεκτήματα του Go.
- Cool http βιβλιοθήκη. Με αυτό μπορείτε να δημιουργήσετε πολλά από το κουτί.
- Επιπλέον, κανάλια που μας επέτρεψαν να εφαρμόσουμε πολύ εύκολα έναν μηχανισμό αποστολής ειδοποιήσεων σε πελάτες.
- Το υπέροχο πράγμα Race ανιχνευτής μας επέτρεψε να εξαλείψουμε αρκετά κρίσιμα σφάλματα (υποδομή σταδιοποίησης). Ό,τι λειτουργεί στη σκηνή εκκινείται, μεταγλωττίζεται με το κλειδί Race. και, κατά συνέπεια, μπορούμε να κοιτάξουμε την υποδομή για να δούμε τι πιθανά προβλήματα έχουμε.
- Μινιμαλισμός και απλότητα της γλώσσας.
Αναζητούμε προγραμματιστές! Αν κάποιος θέλει, παρακαλώ.
ερωτήσεις
Ερώτηση του κοινού (εφεξής – Β): – Μου φαίνεται ότι χάσατε ένα σημαντικό σημείο σχετικά με το Fan-out. Έχω δίκιο όταν καταλαβαίνω ότι όταν στέλνετε μια απάντηση σε έναν πελάτη, αποκλείετε εάν ο πελάτης δεν θέλει να διαβάσει;
ΚΥΡΙΑ: - Όχι, δεν μπλοκάρουμε. Πρώτον, τα έχουμε όλα αυτά πίσω από το nginx, δηλαδή δεν υπάρχουν προβλήματα με αργούς πελάτες. Δεύτερον, ο πελάτης έχει ένα κανάλι με buffer - στην πραγματικότητα, μπορούμε να βάλουμε έως και εκατό ενημερώσεις εκεί... Αν δεν μπορούμε να γράψουμε στο κανάλι, τότε το διαγράφει. Αν δούμε ότι το κανάλι είναι μπλοκαρισμένο, τότε απλά θα κλείσουμε το κανάλι και αυτό είναι όλο - ο πελάτης θα επανασυνδεθεί εάν παρουσιαστεί κάποιο πρόβλημα. Επομένως, κατ 'αρχήν, δεν υπάρχει κανένας αποκλεισμός εδώ.
ΣΤΟ: – Δεν θα μπορούσε να είναι δυνατή η άμεση αποστολή μιας εγγραφής στο Listen/Notify και όχι ένας πίνακας αναγνωριστικών;
ΚΥΡΙΑ: – Το Listen/Notify έχει όριο 8 χιλιάδων byte στην προφόρτωση που στέλνει. Κατ' αρχήν, θα ήταν δυνατή η αποστολή αν είχαμε να κάνουμε με μικρό όγκο δεδομένων, αλλά μου φαίνεται ότι αυτός ο τρόπος [όπως το κάνουμε] είναι απλώς πιο αξιόπιστος. Οι περιορισμοί βρίσκονται στην ίδια την Postgres.
ΣΤΟ: – Λαμβάνουν οι πελάτες ενημερώσεις για αγώνες που δεν τους ενδιαφέρουν;
ΚΥΡΙΑ: - Γενικά ναι. Κατά κανόνα, γίνονται 2-3 αγώνες παράλληλα, και μάλιστα σπάνια. Αν κάποιος πελάτης παρακολουθεί κάτι, τότε συνήθως παρακολουθεί τον αγώνα που βρίσκεται σε εξέλιξη. Στη συνέχεια, ο πελάτης έχει μια τοπική βάση δεδομένων στην οποία αθροίζονται όλες αυτές οι ενημερώσεις, και ακόμη και χωρίς σύνδεση στο Διαδίκτυο, ο πελάτης μπορεί να δει όλες τις προηγούμενες αντιστοιχίσεις για τις οποίες έχει ενημερώσεις. Ουσιαστικά, συγχρονίζουμε τη βάση δεδομένων μας στον διακομιστή με την τοπική βάση δεδομένων του πελάτη, ώστε να μπορεί να εργάζεται εκτός σύνδεσης.
ΣΤΟ: – Γιατί φτιάξατε το δικό σας ORM;
Alexey (ένας από τους προγραμματιστές του Look+): – Εκείνη την εποχή (ήταν πριν από ένα χρόνο) υπήρχαν λιγότερα ORM από τώρα, που είναι αρκετά. Το αγαπημένο μου πράγμα για τα περισσότερα ORM εκεί έξω είναι ότι τα περισσότερα από αυτά τρέχουν σε κενές διεπαφές. Δηλαδή, οι μέθοδοι σε αυτά τα ORM είναι έτοιμες να αναλάβουν οτιδήποτε: μια δομή, έναν δείκτη δομής, έναν αριθμό, κάτι εντελώς άσχετο...
Το ORM μας δημιουργεί δομές με βάση το μοντέλο δεδομένων. Εγώ ο ίδιος. Και επομένως όλες οι μέθοδοι είναι συγκεκριμένες, δεν χρησιμοποιούν ανάκλαση, κλπ. Δέχονται δομές και περιμένουν να χρησιμοποιήσουν αυτές τις δομές που έρχονται.
ΣΤΟ: – Πόσα άτομα συμμετείχαν;
ΚΥΡΙΑ: – Στο αρχικό στάδιο συμμετείχαν δύο άτομα. Ξεκινήσαμε κάπου τον Ιούνιο, και τον Αύγουστο ήταν έτοιμο το κύριο μέρος (η πρώτη έκδοση). Υπήρχε μια κυκλοφορία τον Σεπτέμβριο.
ΣΤΟ: – Όπου περιγράφετε SSE, δεν χρησιμοποιείτε timeout. Γιατί αυτό?
ΚΥΡΙΑ: – Για να είμαι ειλικρινής, το SSE εξακολουθεί να είναι ένα πρωτόκολλο html5: το πρότυπο SSE έχει σχεδιαστεί για να επικοινωνεί με προγράμματα περιήγησης, από όσο καταλαβαίνω. Έχει πρόσθετες λειτουργίες, ώστε τα προγράμματα περιήγησης να μπορούν να επανασυνδεθούν (και ούτω καθεξής), αλλά δεν τα χρειαζόμαστε, επειδή είχαμε πελάτες που μπορούσαν να εφαρμόσουν οποιαδήποτε λογική για τη σύνδεση και τη λήψη πληροφοριών. Δεν φτιάξαμε SSE, αλλά κάτι παρόμοιο με SSE. Αυτό δεν είναι το ίδιο το πρωτόκολλο.
Δεν υπήρχε ανάγκη. Από όσο καταλαβαίνω, οι πελάτες εφάρμοσαν τον μηχανισμό σύνδεσης σχεδόν από την αρχή. Δεν τους ένοιαζε πραγματικά.
ΣΤΟ: – Τι πρόσθετα βοηθητικά προγράμματα χρησιμοποιήσατε;
ΚΥΡΙΑ: – Χρησιμοποιήσαμε πιο ενεργά το govat και το golint για να κάνουμε το στυλ ενοποιημένο, καθώς και το gofmt. Δεν χρησιμοποιήθηκε τίποτα άλλο.
ΣΤΟ: – Τι χρησιμοποιήσατε για τον εντοπισμό σφαλμάτων;
ΚΥΡΙΑ: – Ο εντοπισμός σφαλμάτων πραγματοποιήθηκε σε μεγάλο βαθμό με τη χρήση δοκιμών. Δεν χρησιμοποιήσαμε πρόγραμμα εντοπισμού σφαλμάτων ή GOP.
ΣΤΟ: – Μπορείτε να επιστρέψετε τη διαφάνεια όπου υλοποιείται η λειτουργία Δημοσίευση; Σας μπερδεύουν τα ονόματα μεταβλητών με ένα γράμμα;
ΚΥΡΙΑ: - Οχι. Έχουν ένα αρκετά «στενό» εύρος ορατότητας. Δεν χρησιμοποιούνται πουθενά αλλού εκτός από εδώ (εκτός από τα εσωτερικά αυτής της κατηγορίας) και είναι πολύ συμπαγές - χρειάζεται μόνο 7 γραμμές.
ΣΤΟ: – Κατά κάποιο τρόπο δεν είναι ακόμα διαισθητικό…
ΚΥΡΙΑ: - Όχι, όχι, αυτός είναι πραγματικός κωδικός! Δεν είναι θέμα στυλ. Είναι απλώς μια τόσο χρηστική, πολύ μικρή τάξη - μόνο 3 πεδία μέσα στην τάξη...
ΚΥΡΙΑ: – Σε γενικές γραμμές, όλα τα δεδομένα που συγχρονίζονται με τους πελάτες (αγώνες σεζόν, παίκτες) δεν αλλάζουν. Σε γενικές γραμμές, αν κάνουμε ένα άλλο άθλημα στο οποίο πρέπει να αλλάξουμε τον αγώνα, απλά θα λάβουμε υπόψη τα πάντα στη νέα έκδοση του πελάτη και οι παλιές εκδόσεις του πελάτη θα αποκλειστούν.
ΣΤΟ: – Υπάρχουν πακέτα διαχείρισης εξαρτήσεων από τρίτους;
ΚΥΡΙΑ: – Χρησιμοποιήσαμε το go dep.
ΣΤΟ: – Υπήρχε κάτι για το βίντεο στο θέμα της αναφοράς, αλλά δεν υπήρχε τίποτα στην αναφορά για το βίντεο.
ΚΥΡΙΑ: – Όχι, δεν έχω τίποτα στο θέμα για το βίντεο. Ονομάζεται "Look+" - αυτό είναι το όνομα της εφαρμογής.
ΣΤΟ: – Είπατε ότι μεταδίδεται σε πελάτες;..
ΚΥΡΙΑ: – Δεν ασχοληθήκαμε με τη ροή βίντεο. Αυτό έγινε εξ ολοκλήρου από τη Megafon. Ναι, δεν είπα ότι η εφαρμογή ήταν MegaFon.
ΚΥΡΙΑ: – Μετάβαση – για αποστολή όλων των δεδομένων – για το σκορ, για τα γεγονότα αγώνων, τα στατιστικά... Το Go είναι ολόκληρο το backend για την εφαρμογή. Ο πελάτης πρέπει να ξέρει από κάπου ποιο σύνδεσμο να χρησιμοποιήσει για τον παίκτη, ώστε ο χρήστης να μπορεί να παρακολουθήσει τον αγώνα. Έχουμε συνδέσμους για βίντεο και ροές που έχουν προετοιμαστεί.
Μερικές διαφημίσεις 🙂
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).
Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά
Πηγή: www.habr.com