Γειά σου! Ονομάζομαι Vadim Madison, ηγούμαι της ανάπτυξης της πλατφόρμας συστήματος Avito. Το πώς εμείς στην εταιρεία μεταβαίνουμε από μια μονολιθική αρχιτεκτονική σε μια microservice έχει ειπωθεί πολλές φορές. Ήρθε η ώρα να μοιραστούμε πώς μεταμορφώσαμε την υποδομή μας για να αξιοποιήσουμε στο έπακρο τις μικροϋπηρεσίες και να μην χαθούμε σε αυτές. Πώς μας βοηθάει το PaaS εδώ, πώς απλοποιήσαμε την ανάπτυξη και μειώσαμε τη δημιουργία μιας microservice σε ένα κλικ - διαβάστε παρακάτω. Δεν έχουν εφαρμοστεί πλήρως όλα όσα γράφω παρακάτω στο Avito, μέρος του είναι το πώς αναπτύσσουμε την πλατφόρμα μας.

(Και στο τέλος αυτού του άρθρου, θα μιλήσω για την ευκαιρία να φτάσω σε ένα τριήμερο σεμινάριο από έναν ειδικό στην αρχιτεκτονική microservice, τον Chris Richardson).

Πώς φτάσαμε στις μικροϋπηρεσίες

Η Avito είναι μία από τις μεγαλύτερες αγγελίες στον κόσμο, δημοσιεύει περισσότερες από 15 εκατομμύρια νέες διαφημίσεις την ημέρα. Το backend μας δέχεται περισσότερα από 20 χιλιάδες αιτήματα ανά δευτερόλεπτο. Τώρα έχουμε αρκετές εκατοντάδες μικροϋπηρεσίες.

Κατασκευάζουμε μια αρχιτεκτονική microservice για περισσότερο από ένα χρόνο. Πώς ακριβώς - οι συνάδελφοί μας αναλυτικά είπα στην ενότητα μας στο RIT++ 2017. Στο CodeFest 2017 (βλ βίντεο), ο Sergey Orlov και ο Mikhail Prokopchuk εξήγησαν λεπτομερώς γιατί χρειαζόμασταν καθόλου τη μετάβαση στις μικροϋπηρεσίες και τι ρόλο έπαιξε η Kubernetes εδώ. Λοιπόν, τώρα κάνουμε τα πάντα για να ελαχιστοποιήσουμε το κόστος κλιμάκωσης που είναι εγγενές σε μια τέτοια αρχιτεκτονική.

Αρχικά, δεν δημιουργήσαμε ένα οικοσύστημα που θα μας βοηθούσε ολοκληρωμένα στην ανάπτυξη και την έναρξη μικροϋπηρεσιών. Απλώς συνέλεξαν έξυπνες λύσεις ανοιχτού κώδικα, τις κυκλοφόρησαν στο σπίτι και πρόσφεραν στον προγραμματιστή να τις αντιμετωπίσει. Ως αποτέλεσμα, πήγε σε μια ντουζίνα μέρη (πίνακες εργαλείων, εσωτερικές υπηρεσίες), μετά από τα οποία ενίσχυσε την επιθυμία του να κόψει τον κωδικό με τον παλιό τρόπο, σε μονόλιθο. Το πράσινο χρώμα στα παρακάτω διαγράμματα υποδεικνύει τι κάνει ο προγραμματιστής με τον ένα ή τον άλλο τρόπο με τα χέρια του, το κίτρινο χρώμα υποδηλώνει αυτοματισμό.

Τώρα, στο βοηθητικό πρόγραμμα PaaS CLI, μια ομάδα δημιουργεί μια νέα υπηρεσία και άλλες δύο προσθέτουν μια νέα βάση δεδομένων και την αναπτύσσουν στο Stage.

Πώς να ξεπεράσετε την εποχή του «κατακερματισμού μικροϋπηρεσιών»

Με μια μονολιθική αρχιτεκτονική, για χάρη της συνέπειας των αλλαγών στο προϊόν, οι προγραμματιστές αναγκάστηκαν να καταλάβουν τι συνέβαινε με τους γείτονές τους. Όταν εργάζεστε στη νέα αρχιτεκτονική, τα περιβάλλοντα υπηρεσιών δεν εξαρτώνται πλέον το ένα από το άλλο.

Επιπλέον, για να είναι αποτελεσματική η αρχιτεκτονική μικροϋπηρεσιών, είναι απαραίτητο να καθιερωθούν πολλές διαδικασίες, και συγκεκριμένα:

• υλοτομία.
• ανίχνευση αιτήματος (Jaeger).
• συνάθροιση σφαλμάτων (Sentry).
• καταστάσεις, μηνύματα, συμβάντα από Kubernetes (Επεξεργασία ροής συμβάντων).
• όριο αγώνα / διακόπτη κυκλώματος (μπορείτε να χρησιμοποιήσετε το Hystrix).
• Έλεγχος συνδεσιμότητας υπηρεσιών (χρησιμοποιούμε Netramesh).
• παρακολούθηση (Grafana);
• συναρμολόγηση (TeamCity);
• επικοινωνία και ειδοποίηση (Slack, email).
• παρακολούθηση εργασιών. (Jira)
• προετοιμασία εγγράφων.

Για να διασφαλίσουμε ότι το σύστημα δεν θα χάσει την ακεραιότητα και θα παραμείνει αποτελεσματικό καθώς κλιμακώνεται, σκεφτήκαμε ξανά την οργάνωση των μικροϋπηρεσιών στο Avito.

Πώς διαχειριζόμαστε τις μικροϋπηρεσίες

Η Avito συμβάλλει στην εφαρμογή μιας ενιαίας «πολιτικής κομμάτων» μεταξύ των πολλών μικροϋπηρεσιών:

• διαίρεση της υποδομής σε επίπεδα·
• την έννοια της Πλατφόρμας ως Υπηρεσίας (PaaS)·
• παρακολουθώντας όλα όσα συμβαίνουν με τις μικροϋπηρεσίες.

Τα επίπεδα άντλησης υποδομής περιλαμβάνουν τρία επίπεδα. Πάμε από πάνω προς τα κάτω.

Α. Πλέγμα κορυφής. Στην αρχή δοκιμάσαμε το Istio, αλλά αποδείχθηκε ότι χρησιμοποιεί πάρα πολλούς πόρους, κάτι που είναι πολύ ακριβό για τους τόμους μας. Ως εκ τούτου, ο ανώτερος μηχανικός στην ομάδα αρχιτεκτονικής Alexander Lukyanchenko ανέπτυξε τη δική του λύση − Netramesh (διαθέσιμο σε Open Source), το οποίο χρησιμοποιούμε αυτήν τη στιγμή στην παραγωγή και το οποίο καταναλώνει πολλές φορές λιγότερους πόρους από το Istio (αλλά δεν κάνει ό,τι μπορεί να καυχηθεί το Istio).
B. Medium - Kubernetes. Σε αυτό, αναπτύσσουμε και λειτουργούμε μικροϋπηρεσίες.
Γ. Κάτω - γυμνό μέταλλο. Δεν χρησιμοποιούμε σύννεφα και πράγματα όπως το OpenStack, αλλά καθόμαστε εξ ολοκλήρου σε γυμνό μέταλλο.

Όλα τα στρώματα συνδυάζονται PaaS. Και αυτή η πλατφόρμα, με τη σειρά της, αποτελείται από τρία μέρη.

Ι. Γεννήτριες, διαχείριση μέσω του βοηθητικού προγράμματος CLI. Είναι αυτή που βοηθά τον προγραμματιστή να δημιουργήσει μια microservice με τον σωστό τρόπο και με ελάχιστη προσπάθεια.

II. Ενοποιημένος συλλέκτης με έλεγχο όλων των οργάνων μέσω ενός κοινού ταμπλό.

III. αποθήκευση. Συνδέεται με προγραμματιστές που ορίζουν αυτόματα εναύσματα για ουσιαστικές ενέργειες. Χάρη σε ένα τέτοιο σύστημα, δεν χάνεται ούτε μια εργασία μόνο και μόνο επειδή κάποιος ξέχασε να βάλει μια εργασία στο Jira. Χρησιμοποιούμε ένα εσωτερικό εργαλείο που ονομάζεται Atlas για αυτό.

Η υλοποίηση των μικροϋπηρεσιών στο Avito πραγματοποιείται επίσης σύμφωνα με ένα ενιαίο σχήμα, το οποίο απλοποιεί τον έλεγχο τους σε κάθε στάδιο ανάπτυξης και κυκλοφορίας.

Πώς λειτουργεί ο τυπικός αγωγός ανάπτυξης μικροϋπηρεσιών

Γενικά, η αλυσίδα δημιουργίας microservice μοιάζει με αυτό:

CLI-push → Continuous Integration → Bake → Deploy → Τεχνητές δοκιμές → Canary tests → Squeeze Testing → Production → Maintenance.

Ας το δούμε ακριβώς με αυτή τη σειρά.

CLI-ώθηση

• Δημιουργία microservice.
Αγωνιστήκαμε για πολύ καιρό για να διδάξουμε σε κάθε προγραμματιστή πώς να δημιουργεί μικροϋπηρεσίες. Συμπεριλαμβανομένων έγραψε λεπτομερείς οδηγίες στο Confluence. Αλλά τα σχήματα άλλαξαν και συμπληρώθηκαν. Το αποτέλεσμα - δημιουργήθηκε ένα σημείο συμφόρησης στην αρχή του ταξιδιού: χρειάστηκε πολύ περισσότερος χρόνος για την έναρξη των μικροϋπηρεσιών από ό,τι επιτρεπόταν, και παρόλα αυτά υπήρχαν συχνά προβλήματα κατά τη δημιουργία τους.

Στο τέλος, δημιουργήσαμε ένα απλό βοηθητικό πρόγραμμα CLI που αυτοματοποιεί τα βασικά βήματα για τη δημιουργία μιας microservice. Στην πραγματικότητα, αντικαθιστά το πρώτο git push. Να τι ακριβώς κάνει.

- Δημιουργεί μια υπηρεσία σύμφωνα με ένα πρότυπο - βήμα προς βήμα, στη λειτουργία "μάγος". Έχουμε πρότυπα για τις κύριες γλώσσες προγραμματισμού στο σύστημα υποστήριξης Avito: PHP, Golang και Python.

- Μία εντολή τη φορά αναπτύσσει ένα περιβάλλον για τοπική ανάπτυξη σε ένα συγκεκριμένο μηχάνημα - Το Minikube ανεβαίνει, τα γραφήματα Helm δημιουργούνται αυτόματα και εκτελούνται σε τοπικά kubernetes.

— Συνδέει την απαιτούμενη βάση δεδομένων. Ο προγραμματιστής δεν χρειάζεται να γνωρίζει την IP, τη σύνδεση και τον κωδικό πρόσβασης για να αποκτήσει πρόσβαση στη βάση δεδομένων που χρειάζεται - τουλάχιστον τοπικά, τουλάχιστον στο Stage, τουλάχιστον στην παραγωγή. Επιπλέον, η βάση δεδομένων αναπτύσσεται αμέσως σε διαμόρφωση ανεκτική σε σφάλματα και με εξισορρόπηση.

- Εκτελεί η ίδια ζωντανή συναρμολόγηση. Ας πούμε ότι ο προγραμματιστής διόρθωσε κάτι στο microservice μέσω του IDE του. Το βοηθητικό πρόγραμμα βλέπει αλλαγές στο σύστημα αρχείων και, με βάση αυτές, αναδομεί την εφαρμογή (για Golang) και κάνει επανεκκίνηση. Για την PHP, απλώς προωθούμε τον κατάλογο μέσα στον κύβο και εκεί η ζωντανή επαναφόρτωση λαμβάνεται "αυτόματα".

- Δημιουργεί αυτόματα τεστ. Με τη μορφή κενών, αλλά αρκετά χρησιμοποιήσιμα.

• Ανάπτυξη microservice.

Κάποτε ήταν λίγο θλιβερό να αναπτύξουμε μια microservice μαζί μας. Υποχρεωτικά υποχρεωτικά:

Ι. Dockerfile.

II. Διαμόρφωση.
III. Πίνακας τιμόνι, το οποίο είναι από μόνο του δυσκίνητο και περιλαμβάνει:

- τα ίδια τα γραφήματα.
- πρότυπα?
- συγκεκριμένες τιμές λαμβάνοντας υπόψη διαφορετικά περιβάλλοντα.

Έχουμε αφαιρέσει τον πόνο από την εκ νέου επεξεργασία των εκδηλώσεων Kubernetes και τώρα δημιουργούνται αυτόματα. Αλλά το πιο σημαντικό, απλοποιήσαμε την ανάπτυξη στο όριο. Από εδώ και στο εξής, έχουμε ένα Dockerfile και ο προγραμματιστής γράφει ολόκληρη τη διαμόρφωση σε ένα μόνο σύντομο αρχείο app.toml.

Ναι, και στο ίδιο το app.toml, υπάρχει τώρα ένα θέμα για ένα λεπτό. Προδιαγράφουμε πού πόσα αντίγραφα της υπηρεσίας που θα δημιουργηθούν (στο διακομιστή dev-server, στη σκηνή, στην παραγωγή), υποδεικνύουν τις εξαρτήσεις της. Σημειώστε το μέγεθος γραμμής = "small" στο μπλοκ [engine]. Αυτό είναι το όριο που θα εκχωρηθεί στην υπηρεσία μέσω του Kubernetes.

Επιπλέον, με βάση τη διαμόρφωση, δημιουργούνται αυτόματα όλα τα απαραίτητα Helm-charts και δημιουργούνται συνδέσεις με τις βάσεις δεδομένων.

• Βασική επικύρωση. Τέτοιοι έλεγχοι είναι επίσης αυτοματοποιημένοι.
Ανάγκη παρακολούθησης:
- υπάρχει Dockerfile;
- υπάρχει app.toml;
- Υπάρχει τεκμηρίωση;
— κατά τη σειρά εξάρτησης·
— εάν έχουν τεθεί κανόνες προειδοποίησης.
Στο τελευταίο σημείο: ο ίδιος ο κάτοχος της υπηρεσίας καθορίζει ποιες μετρήσεις προϊόντος θα παρακολουθεί.

• Προετοιμασία τεκμηρίωσης.
Ακόμα μια προβληματική περιοχή. Φαίνεται να είναι το πιο προφανές, αλλά ταυτόχρονα το ρεκόρ «συχνά ξεχασμένο», και άρα ο ευάλωτος κρίκος της αλυσίδας.
Είναι απαραίτητο η τεκμηρίωση να είναι για κάθε microservice. Περιλαμβάνει τα ακόλουθα μπλοκ.

I. Σύντομη περιγραφή της υπηρεσίας. Λίγες φράσεις για το τι κάνει και σε τι χρησιμεύει.

II. Σύνδεσμος με το διάγραμμα αρχιτεκτονικής. Είναι σημαντικό ότι με μια ματιά είναι εύκολο να καταλάβετε, για παράδειγμα, εάν χρησιμοποιείτε το Redis για προσωρινή αποθήκευση ή ως τον κύριο χώρο αποθήκευσης δεδομένων σε μόνιμη λειτουργία. Στο Avito, προς το παρόν, αυτός είναι ένας σύνδεσμος προς το Confluence.

III. runbook. Ένας σύντομος οδηγός για την έναρξη της υπηρεσίας και τις λεπτές λεπτομέρειες του χειρισμού της.

IV. FAQ, όπου καλό θα ήταν να προλάβετε προβλήματα που μπορεί να αντιμετωπίσουν οι συνάδελφοί σας όταν εργάζεστε με την υπηρεσία.

V. Περιγραφή των τελικών σημείων API. Εάν ξαφνικά δεν προσδιορίσατε προορισμούς, οι συνάδελφοι των οποίων οι μικροϋπηρεσίες είναι συνδεδεμένες με τις δικές σας είναι σχεδόν βέβαιο ότι θα το πληρώσουν. Τώρα χρησιμοποιούμε το Swagger για αυτό και η λύση μας ονομάζεται συνοπτική.

VI. Ετικέτες. Ή δείκτες που δείχνουν σε ποιο προϊόν, λειτουργικότητα, δομικό τμήμα της εταιρείας ανήκει η υπηρεσία. Σας βοηθούν να κατανοήσετε γρήγορα, για παράδειγμα, εάν βλέπετε τη λειτουργικότητα που κυκλοφόρησαν οι συνάδελφοί σας για την ίδια επιχειρηματική μονάδα πριν από μια εβδομάδα.

VII. Κάτοχος ή ιδιοκτήτες υπηρεσίας. Στις περισσότερες περιπτώσεις, αυτό - ή αυτοί - μπορεί να προσδιοριστεί αυτόματα χρησιμοποιώντας το PaaS, αλλά για ασφάλιση, απαιτούμε από τον προγραμματιστή να τα καθορίσει και χειροκίνητα.

Τέλος, είναι καλή πρακτική η διεξαγωγή ελέγχων τεκμηρίωσης, παρόμοια με τους ελέγχους κώδικα.

Συνεχής ολοκλήρωση

• Προετοιμασία αποθετηρίων.
• Δημιουργία αγωγού στο TeamCity.
• Παραχώρηση δικαιωμάτων.
• Αναζήτηση για κατόχους υπηρεσιών. Εδώ είναι ένα υβριδικό σχήμα - χειροκίνητη σήμανση και ελάχιστος αυτοματισμός από την PaaS. Το πλήρως αυτόματο σχήμα αποτυγχάνει όταν οι υπηρεσίες μεταφέρονται σε υποστήριξη σε άλλη ομάδα ανάπτυξης ή, για παράδειγμα, εάν ο προγραμματιστής της υπηρεσίας εγκαταλείψει.
• Εγγραφή υπηρεσίας στον Άτλαντα (βλέπε παραπάνω). Με όλους τους ιδιοκτήτες και τις εξαρτήσεις του.
• Έλεγχος μεταναστεύσεων. Ελέγχουμε αν υπάρχουν δυνητικά επικίνδυνα μεταξύ τους. Για παράδειγμα, σε ένα από αυτά, εμφανίζεται ένας πίνακας αλλαγής ή κάτι άλλο που μπορεί να διακόψει τη συμβατότητα του σχήματος δεδομένων μεταξύ διαφορετικών εκδόσεων της υπηρεσίας. Στη συνέχεια, η μετεγκατάσταση δεν εκτελείται, αλλά τοποθετείται σε μια συνδρομή - το PaaS θα πρέπει να σηματοδοτήσει τον κάτοχο της υπηρεσίας όταν καταστεί ασφαλής η εφαρμογή της.

Ψήνω

Το επόμενο στάδιο είναι οι υπηρεσίες συσκευασίας πριν από την ανάπτυξη.

• Συναρμολόγηση εφαρμογής. Σύμφωνα με τα κλασικά - σε μια εικόνα Docker.
• Δημιουργία διαγραμμάτων Helm για την ίδια την υπηρεσία και σχετικούς πόρους. Συμπεριλαμβανομένων των βάσεων δεδομένων και της προσωρινής μνήμης. Δημιουργούνται αυτόματα σύμφωνα με τη διαμόρφωση app.toml που δημιουργήθηκε στο στάδιο CLI-push.
• Δημιουργία εισιτηρίων για διαχειριστές για άνοιγμα θυρών (όταν απαιτείται).
• Εκτέλεση δοκιμών μονάδων και υπολογισμός κάλυψης κωδικών. Εάν η κάλυψη κωδικού είναι κάτω από την καθορισμένη τιμή κατωφλίου, τότε, πιθανότατα, η υπηρεσία δεν θα προχωρήσει περαιτέρω - στην ανάπτυξη. Εάν είναι στα όρια του αποδεκτού, τότε στην υπηρεσία θα εκχωρηθεί ένας συντελεστής "απαισιοδοξίας": στη συνέχεια, εάν δεν υπάρξει βελτίωση στον δείκτη με την πάροδο του χρόνου, ο προγραμματιστής θα λάβει μια ειδοποίηση ότι δεν υπάρχει πρόοδος όσον αφορά τις δοκιμές ( και κάτι πρέπει να γίνει γι' αυτό).
• Λογιστική για περιορισμούς μνήμης και CPU. Βασικά, γράφουμε microservices στο Golang και τις τρέχουμε στο Kubernetes. Ως εκ τούτου, μια λεπτότητα σχετίζεται με τη δυνατότητα της γλώσσας Golang: από προεπιλογή, όλοι οι πυρήνες του μηχανήματος χρησιμοποιούνται κατά την εκκίνηση, εάν δεν ορίσετε ρητά τη μεταβλητή GOMAXPROCS και όταν εκκινηθούν πολλές τέτοιες υπηρεσίες στον ίδιο υπολογιστή, ξεκινούν να ανταγωνίζονται για πόρους, παρεμβαίνοντας μεταξύ τους. Τα παρακάτω γραφήματα δείχνουν πώς αλλάζει ο χρόνος εκτέλεσης εάν η εφαρμογή εκτελείται χωρίς διαμάχη και σε λειτουργία αγώνα πόρων. (Οι πηγές των διαγραμμάτων είναι εδώ).

Χρόνος εκτέλεσης, λιγότερο τόσο καλύτερα. Μέγιστο: 643 ms, ελάχιστο: 42 ms. Η φωτογραφία μπορεί να κάνει κλικ.

Ώρα για χειρουργική επέμβαση, λιγότερο είναι καλύτερα. Μέγιστο: 14091 ns, ελάχιστο: 151 ns. Η φωτογραφία μπορεί να κάνει κλικ.

Στο στάδιο προετοιμασίας της συναρμολόγησης, μπορείτε να ορίσετε ρητά αυτήν τη μεταβλητή ή μπορείτε να χρησιμοποιήσετε τη βιβλιοθήκη automaxprocs από τα παιδιά της Uber.

Αναπτύσσω

• Έλεγχος συμβάσεων. Πριν ξεκινήσετε την παράδοση εκδόσεων υπηρεσιών στα περιβάλλοντα που προορίζονται, πρέπει να ελέγξετε τα ακόλουθα:
- Τελικά σημεία API.
— Αντιστοιχία των αποκρίσεων τελικών σημείων API στο σχήμα.
- Μορφή αρχείου καταγραφής.
- Ρύθμιση κεφαλίδων για αιτήματα στην υπηρεσία (τώρα αυτό γίνεται από το netramesh)
- Ρύθμιση του δείκτη κατόχου κατά την αποστολή μηνυμάτων στο λεωφορείο (διαύλου εκδήλωσης). Αυτό είναι απαραίτητο για την παρακολούθηση της συνδεσιμότητας των υπηρεσιών μέσω του λεωφορείου. Μπορείτε να στείλετε τόσο ανεπαρκή δεδομένα στο δίαυλο που δεν αυξάνουν τη συνδεσιμότητα των υπηρεσιών (που είναι καλό), όσο και επιχειρηματικά δεδομένα που ενισχύουν τη συνδεσιμότητα των υπηρεσιών (πράγμα πολύ κακό!). Και τη στιγμή που αυτή η συνδεσιμότητα γίνεται πρόβλημα, η κατανόηση του ποιος γράφει και διαβάζει το λεωφορείο βοηθά στον σωστό διαχωρισμό των υπηρεσιών.

Μέχρι στιγμής, δεν υπάρχουν πολλά συνέδρια στο Avito, αλλά η πισίνα τους επεκτείνεται. Όσο περισσότερες τέτοιες συμφωνίες σε μορφή κατανοητή και βολική για την ομάδα, τόσο πιο εύκολο είναι να διατηρηθεί η συνοχή μεταξύ των μικροϋπηρεσιών.

Συνθετικές δοκιμές

• Δοκιμή κλειστού βρόχου. Για αυτό, τώρα χρησιμοποιούμε ανοιχτό κώδικα hoverfly.io. Πρώτα, καταγράφει το πραγματικό φορτίο στην υπηρεσία και στη συνέχεια - απλώς σε κλειστό βρόχο - μιμείται.

• Stress Testing. Προσπαθούμε να φέρουμε όλες τις υπηρεσίες στη βέλτιστη απόδοση. Και όλες οι εκδόσεις κάθε υπηρεσίας θα πρέπει να υποβάλλονται σε δοκιμή φόρτωσης - ώστε να μπορούμε να κατανοήσουμε την τρέχουσα απόδοση της υπηρεσίας και τη διαφορά με τις προηγούμενες εκδόσεις της ίδιας υπηρεσίας. Εάν, μετά από μια ενημέρωση υπηρεσίας, η απόδοσή του έχει μειωθεί κατά μιάμιση φορά, αυτό είναι ένα σαφές μήνυμα για τους ιδιοκτήτες του: πρέπει να ψάξετε στον κώδικα και να διορθώσετε την κατάσταση.
Ξεκινάμε από τα δεδομένα που συλλέγουμε, για παράδειγμα, για να εφαρμόσουμε σωστά την αυτόματη κλιμάκωση και, στο τέλος, να κατανοήσουμε γενικά πόσο επεκτάσιμη είναι η υπηρεσία.

Κατά τη διάρκεια της δοκιμής φορτίου, ελέγχουμε εάν η κατανάλωση πόρων πληροί τα όρια που έχουν οριστεί. Και εστιάζουμε κυρίως στα άκρα.

α) Εξετάζουμε το συνολικό φορτίο.
- Πολύ μικρό - πιθανότατα κάτι δεν λειτουργεί καθόλου εάν το φορτίο πέσει ξαφνικά πολλές φορές.
- Πολύ μεγάλο - απαιτείται βελτιστοποίηση.

β) Κοιτάξτε την αποκοπή RPS.
Εδώ εξετάζουμε τη διαφορά μεταξύ της τρέχουσας έκδοσης και της προηγούμενης και του συνολικού αριθμού. Για παράδειγμα, εάν η υπηρεσία δίνει 100 rps, τότε είτε είναι κακώς γραμμένο, είτε αυτές είναι οι ιδιαιτερότητές της, αλλά σε κάθε περίπτωση, αυτός είναι ένας λόγος για να δούμε την υπηρεσία πολύ προσεκτικά.
Εάν, αντίθετα, υπάρχουν πάρα πολλά RPS, τότε, ίσως, κάποιο είδος σφάλματος και ορισμένα από τα τελικά σημεία σταμάτησαν να εκτελούν το ωφέλιμο φορτίο, αλλά μόνο μερικά return true;

Δοκιμές καναρίνι

Αφού περάσουν τα συνθετικά τεστ, εκτελούμε τη microservice σε μικρό αριθμό χρηστών. Ξεκινάμε προσεκτικά, με ένα μικρό μερίδιο του επιδιωκόμενου κοινού της υπηρεσίας - λιγότερο από 0,1%. Σε αυτό το στάδιο, είναι πολύ σημαντικό να εισάγονται οι σωστές τεχνικές μετρήσεις και μετρήσεις προϊόντος στην παρακολούθηση ώστε να δείχνουν το πρόβλημα στο σέρβις όσο το δυνατόν γρηγορότερα. Ο ελάχιστος χρόνος δοκιμής καναρίνι είναι 5 λεπτά, ο κύριος είναι 2 ώρες. Για πολύπλοκες υπηρεσίες, ρυθμίζουμε την ώρα σε χειροκίνητη λειτουργία.
Αναλύουμε:
- ειδικές μετρήσεις γλώσσας, ειδικότερα, εργαζόμενοι php-fpm.
— σφάλματα στο Sentry.
— καταστάσεις απαντήσεων·
— χρόνος απόκρισης (χρόνος απόκρισης), ακριβής και μέσος όρος·
— λανθάνουσα κατάσταση·
- εξαιρέσεις, διεκπεραιωμένες και μη χειρισμένες·
- μετρήσεις προϊόντων.

Δοκιμή συμπίεσης

Το Squeeze Testing ονομάζεται επίσης δοκιμή "squeeze". Το όνομα της τεχνικής εισήχθη στο Netflix. Η ουσία του είναι ότι πρώτα γεμίζουμε μια παρουσία με πραγματική κίνηση στην κατάσταση αστοχίας και έτσι ορίζουμε το όριο της. Στη συνέχεια, προσθέτουμε ένα άλλο παράδειγμα και φορτώνουμε αυτό το ζευγάρι - ξανά στο μέγιστο. βλέπουμε το ταβάνι και το δέλτα τους με το πρώτο σφίξιμο. Και έτσι συνδέουμε ένα στιγμιότυπο ανά βήμα και υπολογίζουμε το μοτίβο στις αλλαγές.
Τα δεδομένα σχετικά με τις δοκιμές μέσω "συμπίεσης" ρέουν επίσης σε μια κοινή βάση δεδομένων μετρήσεων, όπου είτε εμπλουτίζουμε τα αποτελέσματα τεχνητού φορτίου με αυτά, είτε αντικαθιστούμε τα "συνθετικά" με αυτά.

Παραγωγή

• Κλιμάκωση. Διαθέτοντας την υπηρεσία στην παραγωγή, παρακολουθούμε πώς κλιμακώνεται. Σε αυτήν την περίπτωση, η παρακολούθηση μόνο των δεικτών CPU, από την εμπειρία μας, είναι αναποτελεσματική. Η αυτόματη κλιμάκωση με συγκριτική αξιολόγηση RPS λειτουργεί στην πιο καθαρή της μορφή, αλλά μόνο για ορισμένες υπηρεσίες, όπως η διαδικτυακή ροή. Επομένως, εξετάζουμε κυρίως τις μετρήσεις προϊόντων για συγκεκριμένες εφαρμογές.

Ως αποτέλεσμα, κατά την κλιμάκωση, αναλύουμε:
- Ενδείξεις CPU και RAM,
- τον αριθμό των αιτημάτων στην ουρά,
- χρόνος απόκρισης,
— πρόβλεψη με βάση τα συσσωρευμένα ιστορικά δεδομένα.

Κατά την κλιμάκωση μιας υπηρεσίας, είναι επίσης σημαντικό να παρακολουθείτε τις εξαρτήσεις της, έτσι ώστε να μην συμβεί να κλιμακώνουμε την πρώτη υπηρεσία στην αλυσίδα και αυτές στις οποίες έχει πρόσβαση να υποστούν φορτίο. Προκειμένου να δημιουργηθεί ένα αποδεκτό φορτίο για ολόκληρη την ομάδα υπηρεσιών, εξετάζουμε τα ιστορικά δεδομένα της «πλησιέστερης» εξαρτημένης υπηρεσίας (όσον αφορά την CPU και τη μνήμη RAM, μαζί με μετρήσεις για συγκεκριμένες εφαρμογές) και τα συγκρίνουμε με τα ιστορικά δεδομένα της την υπηρεσία αρχικοποίησης και ούτω καθεξής σε ολόκληρη την «αλυσίδα εξάρτησης», από πάνω προς τα κάτω.

Υπηρεσία

Αφού τεθεί σε λειτουργία το microservice, μπορούμε να κρεμάσουμε σκανδάλες σε αυτό.

Ακολουθούν τυπικές καταστάσεις στις οποίες λειτουργούν τα ερεθίσματα.
- Εντοπίστηκαν δυνητικά επικίνδυνες μεταναστεύσεις.
- Έχουν κυκλοφορήσει ενημερώσεις ασφαλείας.
- Η ίδια η υπηρεσία δεν έχει ενημερωθεί εδώ και πολύ καιρό.
— Ο φόρτος της υπηρεσίας έχει μειωθεί αισθητά ή ορισμένες από τις μετρήσεις προϊόντων της είναι εκτός του κανόνα.
— Η υπηρεσία δεν πληροί πλέον τις νέες απαιτήσεις της πλατφόρμας.

Ορισμένες από τις σκανδάλες είναι υπεύθυνες για τη σταθερότητα της εργασίας, ορισμένες - ως λειτουργία συντήρησης συστήματος - για παράδειγμα, κάποια υπηρεσία δεν έχει αναπτυχθεί για μεγάλο χρονικό διάστημα και η βασική της εικόνα έχει πάψει να περνάει από ελέγχους ασφαλείας.

Ταμπλό

Εν ολίγοις, το ταμπλό είναι ο πίνακας ελέγχου ολόκληρου του PaaS μας.

• Ένα ενιαίο σημείο πληροφοριών για την υπηρεσία, με δεδομένα για την κάλυψη δοκιμής της, τον αριθμό των εικόνων της, τον αριθμό των αντιγράφων παραγωγής, τις εκδόσεις κ.λπ.
• Ένα εργαλείο για το φιλτράρισμα δεδομένων κατά υπηρεσίες και ετικέτες (μαρτυρίες που ανήκουν σε επιχειρηματικές μονάδες, λειτουργικότητα προϊόντος κ.λπ.)
• Εργαλείο ενσωμάτωσης με εργαλεία υποδομής για εντοπισμό, καταγραφή, παρακολούθηση.
• Ενιαίο σημείο τεκμηρίωσης για υπηρεσίες.
• Μια ενιαία άποψη όλων των γεγονότων ανά υπηρεσία.

Σε συνολικά

Πριν από την εισαγωγή του PaaS, ένας νέος προγραμματιστής μπορούσε να αφιερώσει αρκετές εβδομάδες κατανοώντας όλα τα εργαλεία που απαιτούνται για την έναρξη μιας μικρουπηρεσίας στην παραγωγή: Kubernetes, Helm, εσωτερικές μας δυνατότητες TeamCity, δημιουργία σύνδεσης με βάσεις δεδομένων και κρυφές μνήμες με ασφαλή τρόπο, κ.λπ. Τώρα χρειάζονται μερικές ώρες για να διαβάσετε τη γρήγορη εκκίνηση και να κάνετε την ίδια την υπηρεσία.

Έκανα μια αναφορά για αυτό το θέμα για το HighLoad ++ 2018, μπορείτε να δείτε βίντεο и παρουσίαση.

Μπόνους κομμάτι για όσους διαβάζουν μέχρι το τέλος

Εμείς στην Avito οργανώνουμε μια εσωτερική τριήμερη εκπαίδευση για προγραμματιστές από Κρις Ρίτσαρντσον, ειδικός στην αρχιτεκτονική μικροϋπηρεσιών. Θέλουμε να δώσουμε την ευκαιρία να συμμετάσχει σε αυτό σε έναν από τους αναγνώστες αυτής της ανάρτησης. Εδώ το εκπαιδευτικό πρόγραμμα έχει αναρτηθεί.

Η εκπαίδευση θα διεξαχθεί από τις 5 έως τις 7 Αυγούστου στη Μόσχα. Είναι εργάσιμες μέρες που θα είναι πλήρως απασχολημένες. Το μεσημεριανό γεύμα και η εκπαίδευση θα γίνονται στο γραφείο μας και ο επιλεγμένος συμμετέχων πληρώνει μόνος του τα έξοδα του ταξιδιού και της διαμονής.

Μπορείτε να κάνετε αίτηση συμμετοχής σε αυτήν τη φόρμα google. Από εσάς - η απάντηση στην ερώτηση γιατί πρέπει να παρακολουθήσετε την εκπαίδευση και πληροφορίες σχετικά με τον τρόπο επικοινωνίας μαζί σας. Απαντήστε στα αγγλικά, γιατί ο συμμετέχων που θα φτάσει στην εκπαίδευση θα επιλεγεί από τον ίδιο τον Chris.
Θα ανακοινώσουμε το όνομα του συμμετέχοντα στην εκπαίδευση με μια ενημέρωση σε αυτήν την ανάρτηση και στα κοινωνικά δίκτυα Avito για προγραμματιστές (AvitoTech σε Facebook, Vkontakte, Έξαψη) το αργότερο μέχρι τις 19 Ιουλίου.

Πηγή: www.habr.com