Σχεδόν κάθε σύστημα υπολογιστή εκτελεί πολλαπλές εργασίες χρησιμοποιώντας κοινόχρηστους πόρους και ένα από τα ερωτήματα του προγραμματισμού υπολογιστών είναι πόσο κοντά τα κομμάτια κώδικα που εκτελούν αυτές τις εργασίες πρέπει να συνδέονται μεταξύ τους. Μια ολοένα και πιο δημοφιλής απάντηση είναι η έννοια μιας μικρο-υπηρεσίας—ένα μικρό, διακριτό κομμάτι λειτουργικότητας που αλληλεπιδρά με άλλες μικροϋπηρεσίες για τη δημιουργία ενός μεγαλύτερου συστήματος.
Αν και η βασική ιδέα της ύπαρξης τέτοιων διακριτών στοιχείων δεν είναι καινούργια, ο τρόπος με τον οποίο εφαρμόζονται οι μικροϋπηρεσίες τις καθιστά ένα φυσικό θεμέλιο και για τις δύο σύγχρονες εφαρμογές που βασίζονται σε σύννεφο. Οι υπηρεσίες μικροϋπολογιστών συνάδουν επίσης με τη φιλοσοφία devops, η οποία ενθαρρύνει τη γρήγορη και συνεχή ανάπτυξη νέων λειτουργιών.
Τι είναι οι μικροϋπηρεσίες;
Το "micro" στις μικροσυσκευές υποδηλώνει ότι αυτές είναι μικρές εφαρμογές. Αυτό είναι μερικές φορές αλήθεια, αλλά ένας καλύτερος τρόπος να τα σκεφτούμε είναι ότι πρέπει να είναι τόσο μεγάλα όσο χρειάζεται για να κάνουν ένα συγκεκριμένο πράγμα ή να λύσουν ένα συγκεκριμένο πρόβλημα. Αυτό το πρόβλημα πρέπει να είναι εννοιολογικό και όχι τεχνικό. Όπως το θέτει η Microsoft, «Οι μικροεπηρεσίες πρέπει να σχεδιαστούν γύρω από επιχειρηματικές δυνατότητες, όχι οριζόντια επίπεδα όπως πρόσβαση δεδομένων ή ανταλλαγή μηνυμάτων». Επικοινωνούν με άλλους μικροϋπηρεσίες και εξωτερικούς χρήστες μέσω σχετικά σταθερών API για τη δημιουργία μιας μεγαλύτερης εφαρμογής.
Έτσι, η εσωτερική λειτουργικότητα μιας μεμονωμένης μικροϋπηρεσίας μπορεί να τροποποιηθεί ή να αναβαθμιστεί ριζικά χωρίς να επηρεαστεί το υπόλοιπο σύστημα. Αυτό με τη σειρά του συνδέεται με τον τρόπο με τον οποίο επιδιώκουν να λειτουργούν τα καταστήματα devops: Εάν οι συγκεκριμένες λειτουργίες μιας μεγαλύτερης εφαρμογής χωρίζονται σε διακριτά, ανεξάρτητα λειτουργικά κομμάτια κώδικα, είναι πιο εύκολο να ζήσετε το μάντρα devops του CI / CD (συνεχής ολοκλήρωση και συνεχής παράδοση) . Επίσης, τα καλά καθορισμένα API διευκολύνουν την αυτόματη δοκιμή των μικροϋπηρεσιών.
Αρχιτεκτονική μικροϋπηρεσιών έναντι μονολιθικής αρχιτεκτονικής
Συχνά θα ακούτε τις μικροϋπηρεσίες που αναφέρονται σε μια «αρχιτεκτονική μικροσυσκευών.” Αυτή η φράση δεν περιλαμβάνει μόνο τις ίδιες τις μικροϋπηρεσίες, αλλά και συστατικά για τη διαχείριση και την ανακάλυψη υπηρεσιών, καθώς και μια πύλη API που χειρίζεται την επικοινωνία μεταξύ μικροϋπηρεσιών και του εξωτερικού κόσμου.
Μια «μονολιθική εφαρμογή» είναι το αντίθετο από αυτό που είναι οι μικρο-υπηρεσίες. Πρόκειται για ένα retronym για μια εφαρμογή όπου όλος ο κώδικας βρίσκεται σε ένα μεγάλο εκτελέσιμο αρχείο. Όπως εξηγεί η TechTarget, μια μονολιθική εφαρμογή είναι δυσκολότερη για κλιμάκωση και δυσκολότερη για βελτίωση. Αλλά επειδή έχει δημιουργηθεί ως μια ενιαία συνεκτική εφαρμογή, δεν απαιτεί τόσο διαχείριση όσο μια αρχιτεκτονική μικροσυσκευών.
Οριοθετημένες έννοιες: Πώς να ορίσετε μια μικρο-υπηρεσία
Ας υποστηρίξουμε για μια στιγμή την προηγούμενη εντολή μας ότι οι μικροϋπηρεσίες πρέπει να κάνουν ένα συγκεκριμένο πράγμα. Αυτό είναι εύκολο να πούμε, αλλά στην πράξη, η λειτουργικότητα συχνά συμπλέκεται και η διαίρεση των τμημάτων είναι πιο δύσκολη από ό, τι φαίνεται. Η ανάλυση τομέων και ο σχεδιασμός βάσει τομέων είναι οι θεωρητικές προσεγγίσεις που θα σας βοηθήσουν να διαχωρίσετε το έργο σας με μεγάλη εικόνα σε μεμονωμένα προβλήματα που μπορεί να επιλύσει μια μικρο-υπηρεσία. Σε αυτήν τη διαδικασία, που περιγράφεται σε μια φωτιστική σειρά αναρτήσεων ιστολογίου από τη Microsoft, δημιουργείτε ένα αφηρημένο μοντέλο του τομέα της επιχείρησής σας και στη διαδικασία ανακαλύψτε τα περιορισμένα περιβάλλοντα, που ομαδοποιούν τη λειτουργικότητα που αλληλεπιδρά με τον κόσμο με συγκεκριμένο τρόπο.
Για παράδειγμα, μπορεί να έχετε ένα περιορισμένο πλαίσιο για αποστολή και ένα άλλο για λογαριασμούς. Φυσικά, ένα πραγματικό αντικείμενο θα έχει τόσο μια τιμή όσο και ένα μέρος που πρέπει να πάει, αλλά τα περιορισμένα περιβάλλοντα αντιπροσωπεύουν συγκεκριμένους τρόπους με τους οποίους η εφαρμογή σας σκέφτεται και αλληλεπιδρά με αυτά τα αντικείμενα. Κάθε μικροϋπηρεσία θα πρέπει να υπάρχει εξ ολοκλήρου εντός ενός πλαισίου με ένα μόνο όριο, αν και ορισμένα περιορισμένα περιβάλλοντα ενδέχεται να περιλαμβάνουν περισσότερες από μία μικροϋπηρεσίες.
Μικροσυσκευές έναντι αρχιτεκτονικής προσανατολισμένης στις υπηρεσίες έναντι υπηρεσιών Ιστού
Σε αυτό το σημείο, εάν είστε επαγγελματίας πληροφορικής που βρίσκεστε στον κλάδο για λίγο, ίσως νομίζετε ότι πολλά από αυτά ακούγονται οικεία. Η ιδέα μικρών ατομικών προγραμμάτων που συνεργάζονται μπορεί να σας υπενθυμίζει τόσο υπηρεσίες SOA (αρχιτεκτονική προσανατολισμένη στις υπηρεσίες) όσο και υπηρεσίες Web, δύο λέξεις-κλειδιά από το μεθυστικό Web 2.0 ημέρες της δεκαετίας του 2000. Ενώ με μία έννοια δεν υπάρχει πραγματικά τίποτα νέο κάτω από τον ήλιο, υπάρχουν σημαντικές διαφορές μεταξύ αυτών των εννοιών και των μικροϋπηρεσιών. Η βάση δεδομένων έχει μια καλή ανάλυση των διαφορών, αλλά εδώ είναι μια σύντομη έκδοση:
- Σε μια αρχιτεκτονική προσανατολισμένη στις υπηρεσίες, τα μεμονωμένα στοιχεία είναι σχετικά στενά συνδεδεμένα, μοιράζονται συχνά περιουσιακά στοιχεία, όπως αποθήκευση και επικοινωνούν μέσω ενός εξειδικευμένου λογισμικού που ονομάζεται εταιρικό λεωφορείο αποθήκευσης. Οι μικροϋπηρεσίες είναι πιο ανεξάρτητες, μοιράζονται λιγότερους πόρους και επικοινωνούν μέσω πιο ελαφρών πρωτοκόλλων. Αξίζει να σημειωθεί ότι οι μικρο-υπηρεσίες προέκυψαν από το περιβάλλον SOA, και μερικές φορές θεωρούνται ένα είδος SOA, ή διάδοχος της ιδέας.
- Μια υπηρεσία Ιστού είναι ένα σύνολο λειτουργιών που αντιμετωπίζει δημόσια η πρόσβαση σε άλλες εφαρμογές μέσω του Ιστού. ίσως το πιο διαδεδομένο παράδειγμα είναι οι Χάρτες Google, τους οποίους μπορεί να ενσωματώσει ένας ιστότοπος ενός εστιατορίου για να παρέχει οδηγίες στους πελάτες. Αυτή είναι μια πολύ πιο χαλαρή σύνδεση από ό, τι θα είχατε δει στην αρχιτεκτονική των μικροϋπηρεσιών.
Επικοινωνία μικροϋπηρεσιών
Μια φράση που θα ακούτε συχνά να χρησιμοποιείται για τις αρχιτεκτονικές μικροεπηρεσιών είναι ότι πρέπει να διαθέτουν "έξυπνα τελικά σημεία και χαζούς σωλήνες". Με άλλα λόγια, οι μικροϋπηρεσίες πρέπει να στοχεύουν στη χρήση βασικών και καθιερωμένων μεθόδων επικοινωνίας και όχι σύνθετης και αυστηρής ολοκλήρωσης. Όπως σημειώθηκε, αυτό είναι ένα άλλο πράγμα που διακρίνει τις μικροϋπηρεσίες από το SOA.
Σε γενικές γραμμές, η επικοινωνία μεταξύ μικροϋπηρεσιών θα πρέπει να είναι ασύγχρονη, με την έννοια ότι τα νήματα κώδικα δεν αποκλείονται αναμένοντας απαντήσεις. (Είναι ακόμα καλό να χρησιμοποιείτε πρωτόκολλα σύγχρονης επικοινωνίας όπως το HTTP, αν και ασύγχρονα πρωτόκολλα όπως το AMQP (Advanced Message Queuing Protocol) είναι επίσης κοινά στις αρχιτεκτονικές μικροσυσκευών.) Αυτό το είδος χαλαρής ζεύξης καθιστά μια αρχιτεκτονική μικροϋπηρεσιών πιο ευέλικτη ενόψει της αποτυχίας μεμονωμένων στοιχείων ή τμημάτων του δικτύου, το οποίο αποτελεί βασικό όφελος.
Μικροσυσκευές, Java και Spring Boot και Spring Cloud
Μερικές από τις πρώτες εργασίες σε μικροϋπηρεσίες προέκυψαν στην κοινότητα Java. Ο Martin Fowler ήταν πρώιμος υποστηρικτής. Ένα συνέδριο Java του 2012 στην Πολωνία παρουσίασε μία από τις πιο σημαντικές πρώιμες παρουσιάσεις σχετικά με το θέμα, με τίτλο «Micro services - Java, the Unix Way». Συνέστησε την εφαρμογή των αρχών που καθοδήγησαν την ανάπτυξη των πρώτων εφαρμογών Unix στη δεκαετία του 1970 («Γράψτε προγράμματα που κάνουν ένα πράγμα και το κάνουν καλά. Γράψτε προγράμματα για συνεργασία ») για την ανάπτυξη Java.
Ως αποτέλεσμα αυτής της ιστορίας, υπάρχουν πολλά πλαίσια Java που σας επιτρέπουν να δημιουργήσετε μικροϋπηρεσίες. Ένα από τα πιο δημοφιλή είναι το Spring Boot, το οποίο έχει σχεδιαστεί ειδικά για μικροσυσκευές. Η εκκίνηση επεκτείνεται από το Spring Cloud, το οποίο όπως υποδηλώνει το όνομα, σας επιτρέπει να αναπτύξετε και αυτές τις υπηρεσίες στο cloud. Το Pivotal Software, ο προγραμματιστής του Spring, έχει ένα καλό σεμινάριο για να ξεκινήσει με την ανάπτυξη μικροϋπηρεσιών χρησιμοποιώντας αυτά τα πλαίσια.
Μικροσυσκευές και κοντέινερ: Docker, Kubernetes και άλλα
Η υποκείμενη τεχνολογία που έχει προχωρήσει πιο μακριά για την είσοδο των μικροϋπηρεσιών στο mainstream είναι εμπορευματοκιβώτια. Ένα κοντέινερ είναι παρόμοιο με ένα στιγμιότυπο VM, αλλά αντί να περιλαμβάνει ένα ολόκληρο αυτόνομο λειτουργικό σύστημα, ένα κοντέινερ είναι απλώς ένας απομονωμένος χώρος χρήστη που χρησιμοποιεί τον πυρήνα του λειτουργικού συστήματος κεντρικού υπολογιστή, αλλά διατηρεί τον κώδικα που εκτελείται μέσα σε αυτό αυτόνομο. Τα κοντέινερ είναι πολύ μικρότερα από τις παρουσίες VM και είναι εύκολο να αναπτυχθούν γρήγορα, είτε τοπικά είτε στο cloud, και μπορούν να περιστραφούν πάνω ή κάτω για να ταιριάζουν με τη ζήτηση και τους διαθέσιμους πόρους.
Η ελκυστικότητα των κοντέινερ για μικροσυσκευές θα πρέπει να είναι προφανής: Κάθε μεμονωμένη μικροσυσκευή μπορεί να τρέχει στο δικό της κοντέινερ, γεγονός που μειώνει σημαντικά τα γενικά έξοδα διαχείρισης υπηρεσιών. Οι περισσότερες εφαρμογές κοντέινερ έχουν συμπληρωματικά εργαλεία ενορχήστρωσης που αυτοματοποιούν την ανάπτυξη, διαχείριση, κλιμάκωση, δικτύωση και διαθεσιμότητα εφαρμογών με βάση κοντέινερ. Είναι ο συνδυασμός μικρών, εύχρηστων μικροϋπηρεσιών και εύχρηστων κοντέινερ που καθιστά δυνατή τη φιλοσοφία του devops. Υπάρχουν πολλές υλοποιήσεις του concept container, αλλά μακράν το πιο δημοφιλές είναι το Docker, το οποίο γενικά συνδυάζεται με το Kubernetes ως πλατφόρμα ενορχήστρωσης.
Η άνοιξη, ενώ είναι δημοφιλής, συνδέεται με την πλατφόρμα Java. Τα συστήματα που βασίζονται σε κοντέινερ, από την άλλη πλευρά, είναι polyglot: Οποιαδήποτε γλώσσα προγραμματισμού που υποστηρίζει το λειτουργικό σύστημα μπορεί να εκτελεστεί σε ένα κοντέινερ, το οποίο δίνει μεγαλύτερη ευελιξία στους προγραμματιστές. Πράγματι, ένα μεγάλο πλεονέκτημα των μικροϋπηρεσιών είναι ότι κάθε μεμονωμένη υπηρεσία μπορεί να γραφτεί σε οποιαδήποτε γλώσσα έχει νόημα ή με την οποία οι προγραμματιστές είναι πιο άνετοι. Πράγματι, μια υπηρεσία θα μπορούσε να ξαναχτιστεί πλήρως σε μια νέα γλώσσα χωρίς να επηρεαστεί το σύστημα στο σύνολό του, αρκεί τα API της να παραμένουν σταθερά. Το DZone έχει ένα άρθρο που συζητά τα πλεονεκτήματα και τα μειονεκτήματα του Spring Cloud εναντίον του Kubernetes για μικροϋπηρεσίες.
Σχέδια σχεδίασης μικροσυσκευών
Ανεξάρτητα από τη γλώσσα που χρησιμοποιείτε για την ανάπτυξη μικροϋπηρεσιών, θα αντιμετωπίσετε προβλήματα που έχουν αντιμετωπίσει άλλοι προγραμματιστές στο παρελθόν. Τα μοτίβα σχεδιασμού είναι τυποποιημένα, αφηρημένες λύσεις σε επαναλαμβανόμενα προβλήματα στην επιστήμη των υπολογιστών και ορισμένα από αυτά είναι ειδικά για μικροϋπηρεσίες. Η Devopedia έχει μια υπέροχη λίστα, η οποία περιλαμβάνει:
- Μητρώο υπηρεσιών: για τη σύνδεση πελατών με διαθέσιμες παρουσίες μικροϋπηρεσιών
- Circuit Breaker: για την αποτροπή επανάληψης κλήσης αποτυχημένων υπηρεσιών
- Εναλλακτικά: για την παροχή εναλλακτικής λύσης σε μια αποτυχημένη υπηρεσία
- Sidecar: για την παροχή βοηθητικής υπηρεσίας στο κύριο κοντέινερ, όπως για καταγραφή, συγχρονισμό υπηρεσιών ή παρακολούθηση
- Προσαρμογέας: για τυποποίηση ή ομαλοποίηση της διεπαφής μεταξύ του κύριου κοντέινερ και του εξωτερικού κόσμου
- Πρέσβης: για τη σύνδεση του κύριου εμπορευματοκιβωτίου με τον εξωτερικό κόσμο, όπως για τη μεσολάβηση συνδέσεων localhost σε εξωτερικές συνδέσεις
Μικροϋπηρεσίες και το νέφος: AWS και Azure
Όπως προαναφέρθηκε, ένα από τα πλεονεκτήματα της χρήσης κοντέινερ είναι ότι μπορούν να αναπτυχθούν εύκολα στο cloud, όπου υπάρχουν ευέλικτοι υπολογιστικοί πόροι, ώστε να μπορείτε να μεγιστοποιήσετε την αποτελεσματικότητα της εφαρμογής σας. Όπως μπορείτε να φανταστείτε, οι μεγάλοι δημόσιοι προμηθευτές cloud είναι όλοι πρόθυμοι να χρησιμοποιήσετε τις πλατφόρμες τους για να εκτελέσετε τις εφαρμογές σας που βασίζονται σε μικροσυσκευές. Για περισσότερες πληροφορίες, δείτε τους πόρους από την Amazon, τη Microsoft και την Google.
