Υλοποίηση μικροϋπηρεσιών σε περιβάλλοντα παραγωγής

Informatec Digital » Πόροι » Υλοποίηση μικροϋπηρεσιών σε περιβάλλοντα παραγωγής

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

Τα καλά νέα είναι ότι σήμερα έχουμε συσσωρεύσει πολλή εμπειρία από οργανισμούς όπως το Netflix, το Amazon, η Google ή μεγάλες εταιρείες που λειτουργούν Εκατοντάδες μικροϋπηρεσίες σε παραγωγήΜε βάση αυτά τα μαθήματα, καθώς και τις βέλτιστες πρακτικές σε εταιρικά περιβάλλοντα σε Kubernetes και OpenShift, μπορεί να σχεδιαστεί μια πολύ σταθερή προσέγγιση για το σχεδιασμό, την ανάπτυξη και τη λειτουργία μικροϋπηρεσιών σε κλίμακα χωρίς να χαθεί ο έλεγχος.

Γιατί να αναπτύξετε μικροϋπηρεσίες στην παραγωγή (και όταν δεν αξίζει τον κόπο);

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

Ένα άλλο βασικό όφελος είναι το ανεξάρτητη κλιμάκωση ανά υπηρεσίαΔεν χρειάζεται να υπερμεγεθύνετε ολόκληρη την εφαρμογή εάν μόνο ο κατάλογος, το checkout ή το δημόσιο API παρουσιάζουν αιχμές επισκεψιμότητας. Μπορείτε να κλιμακώσετε κάθε μικρουπηρεσία οριζόντια ή κάθετα με βάση το μοτίβο φόρτωσής της, να μετρήσετε με ακρίβεια το κόστος κάθε λειτουργίας και να διατηρήσετε τη διαθεσιμότητα ακόμη και αν μια συγκεκριμένη περιοχή παρουσιάσει αύξηση στην κατανάλωση.

Ο τρόπος με τον οποίο αυτές οι υπηρεσίες συσκευάζονται και αναπτύσσονται διευκολύνει συνεχής εφαρμογή με χαμηλό κίνδυνοΕάν κάθε μικρουπηρεσία κυκλοφορήσει ανεξάρτητα, η δοκιμή νέων ιδεών και η επαναφορά προβληματικών εκδόσεων είναι πολύ πιο απλή: οι εφαρμογές τύπου canary, οι μπλε/πράσινες εφαρμογές και οι αυτόματες επαναφορές μειώνουν το κόστος των σφαλμάτων και επιτρέπουν περιθώρια για πειραματισμό.

Από τεχνολογικής άποψης, οι μικροϋπηρεσίες προωθούν την ελευθερία επιλογής γλωσσών, πλαισίων και βάσεων δεδομένων ανά υπηρεσία. Δεν ταιριάζουν όλες οι ανάγκες στην ίδια τεχνολογική στοίβα: μπορεί να έχετε επιχειρηματικές υπηρεσίες σε .NET ή Java, επεξεργασία δεδομένων σε Scala/Spark, εξειδικευμένες υπηρεσίες σε Python ή F# ή μικροϋπηρεσίες Τεχνητής Νοημοσύνης σε R. Αυτή η ελεγχόμενη ποικιλομορφία σάς επιτρέπει να χρησιμοποιείτε το σωστό εργαλείο για κάθε περίπτωση, χωρίς να παρασύρετε ολόκληρη την εφαρμογή σε μια παγκόσμια τεχνολογική αλλαγή.

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

Αρχιτεκτονικός σχεδιασμός και σχεδιασμός υπηρεσιών

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

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

Τα API που εκθέτουν αυτές τις υπηρεσίες πρέπει να έχουν σαφώς καθορισμένες και σταθερές συμβάσειςΑυτό περιλαμβάνει αυστηρή τεκμηρίωση (REST με OpenAPI, gRPC με αρχεία .proto, κ.λπ.), σαφή διαχείριση εκδόσεων, διατήρηση συμβατότητας με παλαιότερες εκδόσεις όπου είναι δυνατόν και αυτοματοποίηση της επικύρωσης συμβάσεων για την ανίχνευση προβληματικών αλλαγών πριν φτάσουν στην παραγωγή.

Σε περιβάλλοντα με δεκάδες ή εκατοντάδες υπηρεσίες, είναι ζωτικής σημασίας να ενσωματωθούν πρότυπα ανθεκτικότητας από το στάδιο του σχεδιασμού, έτσι ώστε το σύστημα να είστε προετοιμασμένοι για μερικές αποτυχίεςΜοτίβα όπως οι διακόπτες κυκλώματος, οι επαναλήψεις με υποχώρηση, τα σαφώς καθορισμένα χρονικά όρια, τα διαφράγματα και η αντίθλιψη βοηθούν στην αποτροπή της επίδρασης των υπολοίπων από την αποτυχία μιας υπηρεσίας. Εργαλεία μηχανικής Chaos όπως το Chaos Monkey ή το Gremlin χρησιμοποιούνται για να δοκιμαστεί στην πράξη ο τρόπος με τον οποίο συμπεριφέρεται η πλατφόρμα υπό προσομοιωμένες διακοπές ρεύματος.

Σε πολλά πολύπλοκα συστήματα, οι σχετικά απλές υπηρεσίες CRUD συνυπάρχουν με πιο εξελιγμένες υπηρεσίες που επικεντρώνονται στην αλλαγή των επιχειρηματικών κανόνων. Δεν χρειάζονται όλες οι μικροϋπηρεσίες μια σύνθετη εσωτερική αρχιτεκτονικήΜερικοί μπορεί να είναι απλοί ελεγκτές HTTP με βασική πρόσβαση σε δεδομένα, ενώ άλλοι, όπως η υπηρεσία παραγγελιών ή χρέωσης, μπορεί να εκμεταλλεύονται πιο προηγμένα μοτίβα (DDD, CQRS, συμβάντα τομέα κ.λπ.).

Υποδομή παραγωγής: cloud, containers και Kubernetes/OpenShift

Η εμπειρία από τον πραγματικό κόσμο δείχνει ότι οι μικροϋπηρεσίες ταιριάζουν πολύ καλύτερα όταν αναπτύσσονται σε υποδομή cloud με κοντέινερ και ενορχήστρωση από ό,τι σε απομονωμένες εικονικές μηχανές. Πλατφόρμες όπως το Kubernetes και το OpenShift παρέχουν τα απαραίτητα πρωτόγονα για τη συσκευασία υπηρεσιών ως κοντέινερ, την κλιμάκωση, την αναβάθμιση, την εξισορρόπηση φορτίου και τη διαχείριση υψηλής διαθεσιμότητας.

Συνήθως, κάθε μικρουπηρεσία είναι συσκευασία σε εικόνα δοχείου με βάση μια εταιρική βασική εικόνα (για παράδειγμα, OpenJDK 21 για υπηρεσίες Java) που διέπονται από την ομάδα υποδομής. Αυτή η βασική εικόνα ενημερώνεται με ενημερώσεις ασφαλείας και όταν κυκλοφορεί μια νέα έκδοση, οι ομάδες ανάπτυξης είναι υπεύθυνες για την ανακατασκευή και την αναδιάταξη των υπηρεσιών τους στα αντίστοιχα περιβάλλοντα.

Στο Kubernetes/OpenShift, η βασική μονάδα ανάπτυξης είναι η pod, το οποίο περικλείει ένα ή περισσότερα δοχείαΣυνήθως, μια μικρουπηρεσία αντιστοιχεί σε έναν τύπο pod και αναπτύσσεται χρησιμοποιώντας πόρους όπως Deployments (για υπηρεσίες χωρίς κατάσταση) ή StatefulSets (όταν υπάρχει συσχετισμένη κατάσταση). Από την αρχή, ορίζεται ένας ελάχιστος αριθμός αντιγράφων ανά περιβάλλον, έτσι ώστε τα περιβάλλοντα δοκιμών, προπαραγωγής και παραγωγής να έχουν επίπεδα διαθεσιμότητας κατάλληλα για την κρισιμότητά τους.

Η αυτόματη κλιμάκωση υλοποιείται με Horizontal Pod Autoscaler (HPA)Αυτό προσαρμόζει τον αριθμό των αντιγράφων με βάση μετρήσεις όπως η CPU, η μνήμη ή άλλες προσαρμοσμένες μετρήσεις. Η πλατφόρμα πρέπει επίσης να διαμορφώσει κανόνες κατά της συσχέτισης pod, έτσι ώστε τα αντίγραφα της ίδιας υπηρεσίας να κατανέμονται σε διαφορετικούς κόμβους, αποτρέποντας την κατάργηση όλων των παρουσιών από μια αστοχία κόμβου.

Όσον αφορά την κάθετη διαστασιολόγηση, παίζει με resources.requests και resources.limits Για να ορίσετε το εύρος της CPU και της μνήμης που μπορεί να καταναλώσει ένα pod. Για παράδειγμα, δεσμεύοντας τουλάχιστον 100m CPU και 256Mi μνήμης, και επιτρέποντας έως και 500m και 2G αντίστοιχα σε μια υπηρεσία Java, προσαρμόζοντας την JVM (Xms, Xmx, Xss) για να αξιοποιήσετε σωστά τους πόρους του κοντέινερ.

Διαχείριση κατάστασης: μικροϋπηρεσίες χωρίς και με κατάσταση

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

Ωστόσο, υπάρχουν περιπτώσεις όπου δεν υπάρχει άλλη επιλογή από το να μικροϋπηρεσίες με κατάσταση που υποστηρίζονται από μόνιμους τόμουςΑυτό ισχύει για ορισμένες βάσεις δεδομένων, κατανεμημένα συστήματα αρχείων ή στοιχεία που απαιτούν τη διατήρηση τοπικών δεδομένων. Αυτά τα pod συνήθως αναπτύσσονται με StatefulSets, συνδέονται με PersistentVolume χρησιμοποιώντας PersistentVolumeClaims και κλιμακώνονται κάθετα και όχι οριζόντια.

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

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

Αποκέντρωση δεδομένων και κυριαρχία υπηρεσιών

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

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

Αυτό δεν σημαίνει ότι δεν υπάρχει ενσωμάτωση μεταξύ των δεδομένων: σημαίνει ότι το Η συνέπεια μεταξύ των υπηρεσιών διαχειρίζεται με συμβάντα και ασύγχρονη ανταλλαγή μηνυμάτωνΑποδοχή της τελικής συνέπειας όταν είναι εύλογη. Είναι σύνηθες να χρησιμοποιούνται διάφοροι δίαυλοι συμβάντων (RabbitMQ, Azure Service Bus, Kafka, κ.λπ.) για τη διάδοση αλλαγών κατάστασης μεταξύ μικροϋπηρεσιών, μειώνοντας τις ισχυρές εξαρτήσεις από μία μόνο βάση δεδομένων.

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

Κατανεμημένη διακυβέρνηση, ομάδες και οργάνωση

Η μετάβαση σε μικροϋπηρεσίες χωρίς αλλαγή του οργανισμού είναι σαν να ζητάς προβλήματα. Αντί για το κλασικό Λειτουργικά σιλό για δίκτυα, συστήματα, βάσεις δεδομένων, ανάπτυξη και λειτουργίεςΕνθαρρύνεται μια δομή που βασίζεται σε ομάδες προϊόντων, η οποία θα συνδυάζει προφίλ ανάπτυξης, διασφάλισης ποιότητας (QA), DevOps και, όπου είναι εφικτό, επιχειρηματικούς αναλυτές ή αναλυτές δεδομένων.

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

Για να αποτραπεί αυτή η κατανεμημένη διακυβέρνηση από το να οδηγήσει σε αναρχία, είναι σημαντικό να οριστεί ελαφριά πρότυπα και κοινόχρηστοι κατάλογοιΕγκεκριμένες βασικές εικόνες, μοτίβα ανάπτυξης, συμβάσεις ονοματοδοσίας για χώρους ονομάτων και υπηρεσίες, οδηγίες API, πρότυπα Dockerfile και Kustomize, κ.λπ. Αυτές οι οδηγίες χρησιμεύουν ως "κιγκλιδώματα" που καθοδηγούν τις ομάδες χωρίς να εμποδίζουν την ικανότητά τους να αποφασίζουν.

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

CI/CD, αυτοματισμός και το μοντέλο GitOps

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

Ένας τυπικός αγωγός συνεχούς ολοκλήρωσης και συνεχούς παράδοσης χειρίζεται μεταγλώττιση κώδικα, εκτέλεση δοκιμών, ανάλυση ποιότητας με εργαλεία όπως το SonarQubeΔημιουργήστε την εικόνα κοντέινερ από το εταιρικό αρχείο Docker και ενημερώστε τα μανιφέστα ανάπτυξης. Από εκεί, ένα σύστημα όπως το ArgoCD ή παρόμοιο εφαρμόζει τις αλλαγές στο σύμπλεγμα ακολουθώντας μια προσέγγιση GitOps.

Κάθε αποθετήριο μικρουπηρεσιών συνήθως περιλαμβάνει ένα τυποποιημένο Dockerfile, ένα αρχείο διαμόρφωσης για τον αγωγό (π.χ., ci.json)Ιδιότητες για ανάλυση ποιότητας και έναν κατάλογο ανάπτυξης με ορισμούς Kubernetes (Kustomize ή Helm) διαχωρισμένους ανά περιβάλλον. Τα webhooks του αποθετηρίου ενεργοποιούν τον αγωγό όταν προκύπτουν συμβάντα όπως προωθήσεις ετικετών ή αιτήματα συγχώνευσης.

Το μοτίβο GitOps δηλώνει ότι το Η πηγή αλήθειας για την υποδομή και την ανάπτυξη είναι το αποθετήριο GitΤα μανιφέστα για Deployments, Services, ConfigMaps, PVCs, SealedSecrets και άλλους πόρους διαμορφώνονται εκεί και συγκεκριμένα εργαλεία χειρίζονται τον συγχρονισμό της κατάστασης του συμπλέγματος με αυτό που ορίζεται στο Git. Αυτό παρέχει ιχνηλασιμότητα, αξιολογήσεις αιτημάτων έλξης και εύκολες δυνατότητες επαναφοράς.

Ρυθμίσεις, μυστικά και ασφάλεια

Σε μια ώριμη πλατφόρμα μικρουπηρεσιών, η διαχείριση διαμόρφωσης βασίζεται σε ConfigMaps για μη ευαίσθητες παραμέτρους και Secrets για εμπιστευτικές πληροφορίεςΚάθε μικρουπηρεσία έχει συνήθως το δικό της ConfigMap ανά περιβάλλον, το οποίο αποθηκεύει ιδιότητες όπως διευθύνσεις URL εξαρτώμενων υπηρεσιών, σημαίες λειτουργικότητας ή παραμέτρους ρύθμισης.

Τα μυστικά (διαπιστευτήρια, κλειδιά, διακριτικά, πιστοποιητικά) διαχειρίζονται με αυστηρές πολιτικές ασφαλείαςΣε λιγότερο κρίσιμα περιβάλλοντα, μπορεί να είναι αποδεκτό να διατηρούνται σε μορφή απλού κειμένου, το οποίο διαχειρίζεται η ομάδα ανάπτυξης, αλλά στην προπαραγωγή και την παραγωγή, συνιστάται η κρυπτογράφησή τους χρησιμοποιώντας εργαλεία όπως το Sealed Secrets ή συγκεκριμένους εξωτερικούς διαχειριστές cloud.

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

Στον τομέα της ασφάλειας των επικοινωνιών, το κυρίαρχο μοτίβο είναι το Μηδενική εμπιστοσύνηΤίποτα δεν θεωρείται δεδομένο μόνο και μόνο επειδή η κίνηση είναι «εσωτερική». Όλες οι κλήσεις μεταξύ υπηρεσιών, τόσο εσωτερικών όσο και εξωτερικών, πρέπει να ελέγχονται και να εξουσιοδοτούνται, ιδανικά με mTLS, JWT tokens ή άλλους ισοδύναμους μηχανισμούς. Οι μικροϋπηρεσίες δεν αναθέτουν τυφλά την ασφάλεια στον API Manager ή στο δίκτυο. Εκτελούν επίσης τους δικούς τους ελέγχους.

Επικοινωνία μεταξύ μικροϋπηρεσιών, API και ανταλλαγής μηνυμάτων

Σε μια ώριμη αρχιτεκτονική μικρουπηρεσιών, το επίπεδο επικοινωνίας χωρίζεται σε διάφορες περιπτώσεις. Για την κίνηση από πελάτες (προγράμματα περιήγησης, εφαρμογές για κινητά, τρίτους) στο back-end, χρησιμοποιούνται τα ακόλουθα: API που δημοσιεύονται και διέπονται μέσω ενός Διαχειριστή APIΑυτά τα API είναι συνήθως REST (συχνά χρησιμοποιώντας OpenAPI) ή, σε ορισμένες περιπτώσεις, gRPC που εκτίθενται μέσω μιας πύλης.

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

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

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

Εκτός από τη σύγχρονη επικοινωνία, η Η ασύγχρονη ανταλλαγή μηνυμάτων παίζει καθοριστικό ρόλοΧρησιμοποιείται για την αποσύνδεση των διαδικασιών, την απορρόφηση των αιχμών, τη διάδοση επιχειρηματικών συμβάντων μεταξύ υπηρεσιών και τη βελτίωση της ανθεκτικότητας. Κάθε συμβάν συνήθως έχει ένα καλά καθορισμένο και εκδοχικό σχήμα, με μηχανισμούς παρακολούθησης για την αποτροπή βλαβών μεταξύ παραγωγών και καταναλωτών καθώς εξελίσσονται.

Παρατηρησιμότητα, Συλλέκτης OTEL και λειτουργία

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

Κεντρικό στοιχείο σε αυτό το σχέδιο είναι το Συλλέκτης OpenTelemetry (Συλλογέας OTEL)Αυτό αναπτύσσεται στον χώρο ονομάτων ή κεντρικά για τη συλλογή μετρήσεων, αρχείων καταγραφής και ιχνών από όλα τα στοιχεία. Οι μικροϋπηρεσίες χρειάζεται να γνωρίζουν μόνο ότι πρέπει να στείλουν την τηλεμετρία τους στον Συλλέκτη. Ο Συλλέκτης στη συνέχεια την προωθεί σε συστήματα παρατηρησιμότητας (Prometheus, Grafana, Jaeger, Elastic, κ.λπ.) χωρίς η υπηρεσία να χρειάζεται να γνωρίζει τις λεπτομέρειες.

Για το σχέδιο υποδομής, χρησιμοποιούνται τα ακόλουθα: συλλέκτες και εξαγωγείς σε επίπεδο κόμβου Αυτά τα συστήματα συλλέγουν μετρήσεις CPU, μνήμης, δίσκου, δικτύου και αρχείων καταγραφής από τις ομάδες (pods), στέλνοντάς τες στον Prometheus και την Elasticsearch αντίστοιχα. Εργαλεία όπως το Grafana και το Kibana χρησιμοποιούνται για την οπτικοποίηση αυτών των πληροφοριών, τη δημιουργία πινάκων ελέγχου και τον ορισμό ειδοποιήσεων με έξυπνα όρια και σχετικά runbooks.

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

Στρατηγική δοκιμών, συμβάσεις και εμπειρία τοπικής ανάπτυξης

Η δοκιμή μιας κατανεμημένης αρχιτεκτονικής μικρουπηρεσιών απαιτεί πιο περίπλοκη στρατηγική δοκιμών από ό,τι σε ένα μονόλιθο. Οι δοκιμές μονάδας παραμένουν θεμελιώδεις, αλλά οι δοκιμές συμβολαίων (για API και συμβάντα), οι δοκιμές ενσωμάτωσης μεταξύ υπηρεσιών και οι δοκιμές από άκρο σε άκρο που διασχίζουν ολόκληρες ροές αποκτούν όλο και μεγαλύτερη σημασία.

Για να αποφευχθούν αλλαγές που διαταράσσουν τη συμβατότητα, τεχνικές όπως δοκιμές συμβάσεων με γνώμονα τον καταναλωτήόπου οι πελάτες καθορίζουν τις προσδοκίες API και οι πάροχοι υπηρεσιών τις εκπληρώνουν. Κάθε αλλαγή σύμβασης υποβάλλεται σε αυτοματοποιημένες δοκιμές που εκτελούνται σε αγωγούς CI, αποτρέποντας αναπτύξεις που θα προκαλέσουν προβλήματα σε γνωστούς καταναλωτές.

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

Οι δοκιμές από άκρο σε άκρο βασίζονται όλο και περισσότερο σε εφήμερα περιβάλλοντα ή «προεπισκοπήσεις» που δημιουργούνται από κλάδους χαρακτηριστικώνΑυτά τα εργαλεία δημιουργούν ένα απομονωμένο περιβάλλον με τις υπηρεσίες που σχετίζονται με αυτήν τη λειτουργικότητα. Αυτό ελαχιστοποιεί τις τριβές μεταξύ των ομάδων, μειώνει το φαινόμενο «λειτουργεί στον υπολογιστή μου» και εντοπίζει προβλήματα ενσωμάτωσης πριν φτάσουν σε πιο ακριβά περιβάλλοντα, όπως η προπαραγωγή.

Μοτίβα ανάπτυξης μικροϋπηρεσιών στην παραγωγή

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

Στο μοτίβο του στιγμιότυπο υπηρεσίας ανά εικονική μηχανήΚάθε υπηρεσία συσκευάζεται ως εικόνα VM (π.χ., ένα EC2 AMI) και εκτελείται σε ξεχωριστή παρουσία. Αυτό παρέχει ισχυρή απομόνωση με κόστος την υψηλότερη κατανάλωση πόρων και τους βραδύτερους χρόνους εκκίνησης. Εργαλεία όπως το Packer ή λύσεις ειδικά για παρόχους cloud διευκολύνουν τη δημιουργία εικόνων VM έτοιμων για παραγωγή.

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

Τέλος, οι προσεγγίσεις έχουν κερδίσει δημοτικότητα χωρίς διακομιστή, όπως το AWS LambdaΑυτό το μοτίβο περιλαμβάνει συναρτήσεις συσκευασίας που ανταποκρίνονται σε αιτήματα HTTP ή συμβάντα από άλλες υπηρεσίες (S3, DynamoDB, ουρές, κ.λπ.), με τους χρήστες να πληρώνουν μόνο για αυτό που χρησιμοποιούν. Είναι ιδιαίτερα κατάλληλο για πολύ μικρές μικρουπηρεσίες ή βραχύβιες εργασίες που βασίζονται σε συμβάντα, αν και εισάγει πρόσθετες παραμέτρους σχετικά με την παρατηρησιμότητα, τις κρύες εκκινήσεις και τα όρια εκτέλεσης.

Στην πράξη, πολλοί οργανισμοί καταλήγουν σε ένα υβριδικό οικοσύστημα: το βασικό μέρος του συστήματος λειτουργεί σε κοντέινερ και ορχηστρωτές, ενώ ορισμένα βοηθητικά στοιχεία υλοποιούνται ως λειτουργίες χωρίς διακομιστή ή ως εξειδικευμένες εικονικές μηχανές (VM), πάντα με σαφείς διεπαφές και σαφώς καθορισμένα πρωτόκολλα να τα ενσωματώσουν στο σύνολο.

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