Η ανάπτυξη κατανεμημένων συστημάτων αναπτύσσεται ραγδαία καθώς οι προγραμματιστές λογισμικού δημιουργούν συστήματα που πρέπει να συμβαδίζουν με τις συνεχώς αυξανόμενες απαιτήσεις που επιβάλλει το ηλεκτρονικό επιχειρείν. Όμως, ποτέ ο σχεδιασμός και η εφαρμογή ενός επιπέδου επεξεργασίας μηνυμάτων σε ένα κατανεμημένο σύστημα δεν ήταν τόσο περίπλοκο όσο είναι σήμερα. Αυτό οφείλεται κυρίως στη δραματική αύξηση της πιθανής λειτουργικότητας που ενεργοποιείται από πρότυπα όπως η υπηρεσία Java Message Service (JMS) που συνδέουν τεχνολογίες πολλών προμηθευτών σε ένα μόνο σύστημα. Επιπλέον, ο πολλαπλασιασμός του Διαδικτύου έχει οδηγήσει σε νέες, επεκτατικές βάσεις χρηστών και έχει διαθέσει αρκετά πρωτόκολλα για επικοινωνία σε ένα κατανεμημένο σύστημα. Τέτοια πρωτόκολλα περιλαμβάνουν το CORBA IIOP (Internet Inter-ORB Protocol), το Microsoft DCOM (Μοντέλο αντικειμένου κατανεμημένου στοιχείου) και το Java RMI (Απομακρυσμένη μέθοδος επίκλησης).
Η φυσική εξέλιξη αυτών των πρωτοκόλλων οδήγησε στην εισαγωγή του ενδιάμεσου λογισμικού προσανατολισμένου σε μηνύματα (MOM), το οποίο επιτρέπει χαλαρότερη σύζευξη σε κατανεμημένα συστήματα αφαιρώντας τη μετάφραση, την ασφάλεια και τα υποκείμενα πρωτόκολλα επικοινωνίας από πελάτες και διακομιστές. Οι λύσεις Middleware περιλαμβάνουν το SOAP (Simple Object Access Protocol) και το JMS. Ιδιωτική επεξεργασία συναλλαγών μεσαίου επιπέδου υπάρχει από τις πρώτες μέρες της COBOL (Common Business Oriented Language), αλλά δεν ήταν πολύ περίπλοκη λόγω των περιορισμών των τεχνολογιών πρώιμων μηνυμάτων.
Με την εμφάνιση προτύπων όπως το JMS, οι προγραμματιστές μπορούν πλέον να συνδέσουν πολλές τεχνολογίες. Οι αποφάσεις σχεδιασμού κατανεμημένου συστήματος είναι πιο δύσκολες και οι επιπτώσεις τους στην ακεραιότητα και τη διανομή δεδομένων είναι κρίσιμες για την επιτυχία ή την αποτυχία του συστήματος.
Μια διαδεδομένη και σιωπηρή υπόθεση είναι ότι η εισαγωγή της τεχνολογίας είναι ένα πλεονέκτημα, ενώ οι υποχρεώσεις της συχνά αγνοούνται. Η μη καταλογισμό των υποχρεώσεων οδηγεί συχνά σε ένα σύστημα που είναι είτε περιττό περίπλοκο ή / και υπερβολικά κατασκευασμένο. Μια βασική κατανόηση του JMS και των εγγενών ιδιοτήτων του (ανεξάρτητες από το σύστημα ιδιότητες), ακολουθούμενη από μια προσεκτική ανάλυση σε σχέση με συγκεκριμένα σενάρια κατανεμημένου συστήματος μπορεί να δείξει πόσο καλά το JMS μπορεί να επιλύσει τις απαιτήσεις του συστήματος είτε με την αλλαγή υφιστάμενων προβλημάτων είτε με την εισαγωγή νέων.
Επισκόπηση JMS
Το JMS, που εισήχθη από την Sun Microsystems το 1999 ως μέρος της προδιαγραφής Java 2 Platform, Enterprise Edition (J2EE), είναι ένα σύνολο προτύπων που περιγράφουν τα θεμέλια για ένα επίπεδο ενδιάμεσου λογισμικού επεξεργασίας μηνυμάτων. Το JMS επιτρέπει στα συστήματα να επικοινωνούν συγχρονισμένα ή ασύγχρονα και μέσω μοντέλων point-to-point και δημοσίευσης-εγγραφής. Σήμερα, αρκετοί προμηθευτές παρέχουν υλοποιήσεις JMS όπως BEA Systems, Hewlett-Packard, IBM, Macromedia και Oracle, επιτρέποντας έτσι στο JMS να αλληλεπιδρά με πολλαπλές τεχνολογίες προμηθευτών.
Το Σχήμα 1 δείχνει ένα απλό σύστημα βασισμένο σε JMS με μια εξερχόμενη ουρά συμπληρωμένη με μηνύματα για επεξεργασία από τους πελάτες και μια εισερχόμενη ουρά, η οποία συλλέγει τα αποτελέσματα επεξεργασίας του πελάτη για εισαγωγή σε μια βάση δεδομένων.
Όπως αναφέρθηκε παραπάνω, το MOM (όπως το JMS) επιτρέπει χαλαρότερη σύζευξη σε κατανεμημένα συστήματα αφαιρώντας τη μετάφραση, την ασφάλεια και τα υποκείμενα πρωτόκολλα επικοινωνίας από τους πελάτες και τους διακομιστές. Ένα από τα κύρια στοιχεία του επιπέδου επεξεργασίας μηνυμάτων είναι ότι, επειδή εισάγει αυτό το επίπεδο αφαίρεσης, η εφαρμογή είτε του πελάτη είτε του διακομιστή μπορεί να αλλάξει, μερικές φορές ριζικά, χωρίς να επηρεάζει άλλα στοιχεία του συστήματος.
Δύο συγκεκριμένα σενάρια
Σε αυτήν την ενότητα, παρουσιάζω δύο κατανεμημένα συστήματα που είναι δυνητικοί υποψήφιοι για JMS και εξηγώ τους στόχους κάθε συστήματος και γιατί τα συστήματα είναι υποψήφιοι JMS.
Σενάριο 1
Ο πρώτος υποψήφιος είναι ένα κατανεμημένο σύστημα κωδικοποίησης (φαίνεται στο σχήμα 2). Αυτό το σύστημα διαθέτει ένα σύνολο Ν πελάτες που ανακτούν εργασίες κωδικοποίησης από κεντρικό διακομιστή βάσης δεδομένων. Στη συνέχεια, οι πελάτες εκτελούν τον πραγματικό μετασχηματισμό (κωδικοποίηση) από ψηφιακό κύριο σε κωδικοποιημένα αρχεία και τελειώνουν αναφέροντας την κατάσταση μετά την επεξεργασία τους (π.χ. επιτυχία / αποτυχία) πίσω στον κεντρικό διακομιστή βάσης δεδομένων.
Οι τύποι κωδικοποίησης (π.χ. κείμενο, ήχος ή βίντεο) ή μετασχηματισμοί (π.χ., .pdf προς την .xml, . wav προς την .mp3, .avi προς την .qt) δεν πειράζει. Είναι σημαντικό να κατανοήσουμε ότι η κωδικοποίηση απαιτεί ένταση CPU και απαιτεί διανεμημένη επεξεργασία σε πολλούς πελάτες σε κλίμακα.
Με μια ματιά, αυτό το σύστημα είναι πιθανός υποψήφιος JMS επειδή:
- Η επεξεργασία πρέπει να διανεμηθεί καθώς είναι εξαιρετικά απαιτητική για τον επεξεργαστή (CPU)
- Μπορεί να είναι προβληματικό, από την άποψη της απόδοσης του συστήματος, να συνδέσετε πολλούς πελάτες απευθείας σε έναν διακομιστή βάσης δεδομένων
Σενάριο 2
Το δεύτερο υποψήφιο σύστημα JMS είναι ένα παγκόσμιο σύστημα εγγραφής για μια διαδικτυακή πύλη. Η καθολική εγγραφή χειρίζεται αιτήματα για δημιουργία νέου χρήστη (εγγραφή), σύνδεση και έλεγχο ταυτότητας.
Οι συγκεκριμένες πληροφορίες εγγραφής (π.χ. όνομα, διεύθυνση, αγαπημένο χρώμα) και μέθοδοι ελέγχου ταυτότητας χρήστη (π.χ. αντικείμενα χρήστη από διακομιστή, cookie HTTP) δεν έχουν σημασία. Ωστόσο, είναι σημαντικό αυτή η κλίμακα συστήματος να χειρίζεται εκατομμύρια χρήστες και τα πρότυπα χρήσης είναι δύσκολο, αν όχι αδύνατο, να προβλεφθούν. (Κατά τη διάρκεια ενός τηλεοπτικού παιχνιδιού ESPN World Cup ο εκφωνητής λέει, "Συνδεθείτε και ψηφίστε στην ηλεκτρονική μας δημοσκόπηση. Θα παρουσιάσουμε τα αποτελέσματα στο τέλος της παράστασης." Ξαφνικά, 500.000 χρήστες συνδέονται μέσα σε τρία λεπτά διάστημα 3 λεπτά = 180 δευτερόλεπτα, 500.000 συνδέσεις χρήστη / 180 δευτερόλεπτα = 2.778 συνδέσεις χρήστη / δευτερόλεπτο.)
Αυτό το σύστημα είναι πιθανός υποψήφιος JMS για τους ακόλουθους λόγους:
- Το σύστημα πρέπει να διανεμηθεί για να κλιμακώσει τον όγκο συναλλαγών
- Οι συναλλαγές είναι ατομικές (π.χ. σύνδεση), επομένως είναι ανιθαγενείς και επομένως υποψήφιοι για διανομή
Τα δύο συστήματα είναι αρχιτεκτονικά όμοια. Αρκετοί υπολογιστές-πελάτες εξάγουν δεδομένα από έναν κεντρικό διακομιστή βάσης δεδομένων (πιθανώς αναπαράγονται στο Μ διακομιστές βάσης δεδομένων μόνο για ανάγνωση), εκτελέστε κάποια λογική στον υπολογιστή-πελάτη και, στη συνέχεια, αναφέρετε την κατάσταση στον κεντρικό διακομιστή βάσης δεδομένων. Ένα σύστημα παρέχει κωδικοποιημένα αρχεία σε ένα σύστημα αρχείων μέσω UNC / FTP. ο άλλος παρέχει περιεχόμενο HTML σε προγράμματα περιήγησης Ιστού μέσω HTTP. Και τα δύο συστήματα διανέμονται.
Αυτό συμβαίνει όσο πολλοί μηχανικοί ακολουθούν τις αναλύσεις τους πριν εφαρμόσουν το JMS. Στο υπόλοιπο αυτού του άρθρου, εξηγώ ότι, αν και αυτά τα συστήματα έχουν πολλά χαρακτηριστικά, η καταλληλότητα του JMS γίνεται σαφέστερη και πιο αποκλίνουσα καθώς εξετάζουμε τις απαιτήσεις κάθε συστήματος, συμπεριλαμβανομένης της απόδοσης του συστήματος, της διανομής δεδομένων και της επεκτασιμότητας.
Ανάλυση συστήματος: Ενσωμάτωση ή μη ενσωμάτωση
Το JMS έχει εγγενείς ιδιότητες ανεξάρτητες από το σύστημα. Μερικές από αυτές τις ιδιότητες (επαγγελματίες που επισημαίνονται με +, μειονεκτήματα που υποδηλώνονται με -) που ισχύουν και για τα δύο συστήματα περιλαμβάνουν:
- (+) Το JMS είναι ένα σύνολο προτύπων που δημιουργήθηκαν από πολλαπλές υλοποιήσεις προμηθευτών. Ως εκ τούτου, αποφεύγετε τον φόβο κλείδωμα πωλητή πρόβλημα.
- (+) Το JMS επιτρέπει την αφαίρεση (μέσω ενός γενικού API) μεταξύ πελάτη και διακομιστή. μπορείτε να αλλάξετε ένα σχήμα βάσης δεδομένων ή μια πλατφόρμα χωρίς να αλλάξετε το επίπεδο εφαρμογής (υπονοείται ότι υπάρχουν άλλες πιθανές αλλαγές συστήματος, οι οποίες απομονώνονται μεταξύ τους από το επίπεδο μηνυμάτων).
- (+)/(-) Το JMS μπορεί να βοηθήσει μια κλίμακα συστήματος (επαγγελματίας). Το μειονέκτημα είναι ότι κάθε σύστημα που κλιμακώνεται με JMS μπορεί να κλιμακωθεί χωρίς αυτό.
- (-) Το JMS είναι περίπλοκο. Είναι ένα εντελώς νέο επίπεδο με ένα νέο σύνολο διακομιστών. Η διαχείριση λογισμικού, η παρακολούθηση διακομιστών και η ασφάλεια είναι μερικά από τα ασήμαντα προβλήματα που σχετίζονται με την ανάπτυξη JMS. Το κόστος πρέπει επίσης να ληφθεί υπόψη.
- (-) Οι προμηθευτές δεν ερμηνεύουν πάντα και επομένως εφαρμόζουν πρότυπα ακριβώς με τον ίδιο τρόπο, έτσι υπάρχουν διαφορές μεταξύ των διαφόρων εφαρμογών.
- (-) Με το JMS, χρειάζεστε περισσότερους ελέγχους και υπόλοιπα συστήματος. Δεν εισάγετε μόνο ένα νέο επίπεδο, αλλά και την ασύγχρονη διανομή και αναγνώριση δεδομένων, η οποία έχει την πρόσθετη πολυπλοκότητα της ασύγχρονης ειδοποίησης.
- (-) Δεν υπάρχουν ουρές αναφοράς / ενημέρωσης / παρακολούθησης μηνυμάτων χωρίς προσαρμοσμένο λογισμικό.
Το JMS έχει επίσης εξαρτήσεις που εξαρτώνται από το σύστημα. Η καταλληλότητα του JMS εξαρτάται από το πόσο καλά αυτές οι ιδιότητες αντιστοιχούν στο πρόβλημα που προσπαθείτε να λύσετε. Μερικές από αυτές τις ιδιότητες και πώς σχετίζονται με τα δύο συστήματα ενδιαφέροντος ακολουθούν:
Προσωρινή αποθήκευση
Η προσωρινή αποθήκευση είναι πρωταρχικός παράγοντας για τον προγραμματισμό χωρητικότητας σε οποιοδήποτε κατανεμημένο σύστημα. Το JMS έχει πολλές δυνατότητες που επιτρέπουν τη χρήση του ως τεχνολογία προσωρινής αποθήκευσης (κυρίως ότι διανέμεται, σύγχρονη ή ασύγχρονη και ανταλλαγές δεδομένων ως αντικείμενα σε μηνύματα). Επομένως, μια υπάρχουσα εγκατάσταση JMS μπορεί να αξιοποιηθεί ως υποδομή προσωρινής αποθήκευσης, εάν απαιτείται.
Κατά την εξέταση του συστήματος κωδικοποίησης, η προσωρινή αποθήκευση δεν είναι γενικά χρήσιμη για την αύξηση της συνολικής απόδοσης του συστήματος, καθώς οι περισσότεροι μετασχηματισμοί αρχείων εκτελούνται μία φορά και μετακινούνται σε μια εγκατάσταση φιλοξενίας ή SAN (δίκτυο περιοχής αποθήκευσης), και υπάρχουν λίγα αλληλεπικάλυψη περιεχομένου μεταξύ πελατών. Η καθολική εγγραφή είναι πρωταρχικός υποψήφιος για μια προσωρινή μνήμη πληροφοριών χρήστη, καθώς οι χρήστες συνήθως συνδέονται, περιηγούνται και στη συνέχεια αποσυνδέονται. Η σύνδεση δημιουργεί μια καταχώριση προσωρινής μνήμης ενός χρήστη και αυτό το αντικείμενο παρέχει επακόλουθο έλεγχο ταυτότητας χρήστη ενώ ο χρήστης βρίσκεται στον ιστότοπο.
Επεξεργασία παραγγελίας
Στο παγκόσμιο σύστημα εγγραφής, δεν υπάρχει προγραμματισμός ή / και παραγγελία για επεξεργασία συναλλαγών. Οι ψευδο-τυχαίοι χρήστες εισέρχονται στο σύστημα σε ψευδο-τυχαία διαστήματα κατά τη σύνδεση, περιηγούνται στο περιεχόμενο (και επομένως επικυρώνονται όταν έχουν πρόσβαση σε περιορισμένο περιεχόμενο ή / και εφαρμογές) και στη συνέχεια αποσυνδέονται.
Μέσα στο σύστημα κωδικοποίησης, διατάσσεται η επεξεργασία. Το περιεχόμενο ομαδοποιείται σε ομάδες για παράδοση ανάλογα με τη διαθεσιμότητα αφαιρούμενου χώρου αποθήκευσης (π.χ. λύσεις DLT ή αποθήκευση συσκευών δικτύου). Το περιεχόμενο δεν παραδίδεται έως ότου ολοκληρωθεί η παρτίδα, οπότε οι παρτίδες πρέπει να εκτελούνται με τη σειρά (αν και οι μετασχηματισμοί μέσα σε μια παρτίδα μπορεί δυνητικά να είναι χωρίς ταξινόμηση). Είναι δυνατή η εφαρμογή ουρών προτεραιότητας εντός του JMS για τη διατήρηση της παραγγελίας επεξεργασίας, αλλά η διατήρηση αυτής της σειράς παρτίδων μηνυμάτων μεταξύ πολλαπλών διακομιστών JMS και πολλαπλών ουρών γίνεται αρκετά περίπλοκη. Ένας σχεσιακός διακομιστής βάσεων δεδομένων με υποστήριξη για συναλλαγές είναι μια πιο κατάλληλη τεχνολογία για τη διαχείριση αυτής της ροής εργασίας.
Ασφάλεια
Η ασφάλεια δεν αποτελεί μέρος της προδιαγραφής JMS. Το πρόβλημα ασφαλείας δεν αλλάζει απαραίτητα με μια εφαρμογή που βασίζεται σε JMS (εάν έχετε προϋπόθεση ασφαλείας πριν από το JMS, θα έχετε παρόμοια απαίτηση ασφαλείας μετά το JMS). Γνωρίζοντας αυτό, είναι σημαντικό να κατανοήσουμε πώς μπορεί να σχετίζεται το JMS με την υπάρχουσα ασφάλεια υποδομής.
Γενικά, όσο περισσότερη τεχνολογία χρησιμοποιείτε, τόσο πιο ευάλωτο γίνεται το σύστημά σας σε εισβολείς και παραβιάσεις ασφάλειας. Επειδή ο διακομιστής εφαρμογών καθολικής εγγραφής είναι διαδικτυακός, τα προβλήματα ασφαλείας που εντοπίστηκαν στην εφαρμογή JMS των προμηθευτών σας και δημοσιεύθηκαν σε ομάδες ειδήσεων στο Διαδίκτυο γίνονται γρήγορα ευθύνες ασφαλείας για τον ιστότοπό σας. Επίσης, επειδή το JMS είναι ένα γενικό API, είναι πιο επιρρεπές σε παραβιάσεις ασφαλείας από ένα ιδιόκτητο σύστημα που χρησιμοποιεί ένα μη δημοσιευμένο API.
Παρόλο που μπορείτε να αξιοποιήσετε το υπάρχον τείχος προστασίας και την ασφάλεια δικτύου που βασίζεται σε IP για να προστατεύσετε το διακομιστή εφαρμογών και βάσεων δεδομένων του back-end σας (διαβάστε: όχι προς το Διαδίκτυο — προορίζεται για λογοπαίγνιο), υπάρχει σημαντικός κίνδυνος ασφαλείας που δημιουργήθηκε με την έκθεση διακομιστών εφαρμογών JMS απευθείας στο Διαδίκτυο.
Το σύστημα κωδικοποίησης υπάρχει γενικά στο ίδιο δίκτυο (επίσης ένα δίκτυο απομονωμένο από το Διαδίκτυο). Επομένως, δεν υπάρχει τίποτα εγγενές για την τοπογραφία δικτύου αυτού του συστήματος που σχετίζεται με το JMS και να αξιοποιεί αυτήν την τοπογραφία για να παρέχει ασφάλεια (υπάρχουν πολύ λιγότερες απαιτήσεις ασφαλείας για το σύστημα κωδικοποίησης, καθώς δεν είναι προσανατολισμένη στον Ιστό).
Επεκτασιμότητα
Επειδή το παγκόσμιο σύστημα εγγραφής υπόκειται στις ιδιοτροπίες μιας μεγάλης και ιδιόμορφης κλικ χρήστη, οι απαιτήσεις επεκτασιμότητας του συστήματος δικαιολογούν το JMS. Το JMS όχι μόνο θα βοηθήσει στην κλιμάκωση του συστήματος, αλλά και στην ουρά συναλλαγών, αν και δεν θα βοηθήσει πολύ όταν τα αιτήματα των χρηστών πλημμυρίσουν το σύστημα.
Επειδή το κατανεμημένο σύστημα κωδικοποίησης έχει ρυθμίσει προσεκτικά την κυκλοφορία δεδομένων (καθώς είναι πιθανώς ένα αυτόνομο σύστημα), οι απαιτήσεις επεκτασιμότητας του συστήματος δεν είναι τόσο τρομερές. Για κατανεμημένη κωδικοποίηση, μπορείτε να συνδέσετε το Ο [100] πελάτες απευθείας στη βάση δεδομένων σας και επιταχύνουν την κυκλοφορία τους για να εξισορροπήσουν την απόδοση κωδικοποίησης με την απόδοση του διακομιστή βάσης δεδομένων.
Εκτέλεση
Η εισαγωγή ενός μεμονωμένου διακομιστή JMS μπορεί να αλλάξει προβλήματα απόδοσης και όχι να τα λύσει. Για το λόγο αυτό, ένα σύστημα JMS θα πρέπει να σχεδιαστεί με πολλούς διακομιστές JMS (και συνεπώς πολλαπλές ουρές). Το σχήμα 4 δείχνει γιατί τα προβλήματα απόδοσης αλλάζουν αντί να επιλύονται. Απεικονίζει τα επίπεδα επεξεργασίας που απαιτούνται για έναν γενικό διακομιστή δεδομένων ώστε να ανταποκρίνεται σε αιτήματα σύνδεσης πελάτη:
Η ανταλλαγή δεδομένων μεταξύ πελάτη και διακομιστή είναι μια διαδικασία δύο τμημάτων, είτε πρόκειται για διακομιστή-πελάτη-βάση δεδομένων είτε διακομιστής-πελάτη-προς-JMS:
- Πρόσβαση δεδομένων
- Διαχείριση νήματος και υποδοχών, ομαδοποίησης και αποθήκευσης
Ένα JMS και ένας διακομιστής βάσης δεδομένων φαίνονται ακριβώς οι ίδιοι (Εικόνα 4). Διαχειρίζονται συνδέσεις υποδοχών, διαχείριση νημάτων και πρόσβαση στα δεδομένα του διακομιστή.
Με έναν μόνο διακομιστή JMS, πιθανά προβλήματα απόδοσης μετακινούνται απλώς από τον διακομιστή βάσης δεδομένων στον διακομιστή JMS. Εκτός από την πιθανή υποβάθμιση της απόδοσης που σχετίζεται με την εναλλαγή περιβάλλοντος στον διακομιστή βάσης δεδομένων σας, τα προβλήματα απόδοσης είναι πλέον δυνητικά μεγαλύτερα λόγω προβλημάτων απόδοσης JVM στον διακομιστή JMS.
Ένας μεμονωμένος διακομιστής JMS προσθέτει σημαντική πολυπλοκότητα στο σύστημά σας και μπορεί επίσης να εισαγάγει προβλήματα απόδοσης που σχετίζονται με τη σύνδεση πολλαπλών πελατών σε έναν μόνο διακομιστή. Ο αντίκτυπος πολλών διακομιστών JMS στη σχεδίαση του συστήματος και στη ροή δεδομένων μπορεί να σημαίνει τη διαφορά μεταξύ μιας επιτυχούς ή αποτυχημένης διάθεσης του συστήματος.
Συνοπτικά, οι δυνατότητες έναντι του δυνητικού αντίκτυπου JMS μοιάζουν έτσι:
Χαρακτηριστικά έναντι αντίκτυπου JMS
