Για πολύ καιρό, δεν έχω καταλάβει τη διαφορά μεταξύ κλήσεων RPC (δηλαδή κλήσης απομακρυσμένης διαδικασίας) και κλήσεων HTTP. Παρακαλώ επιτρέψτε μου να γελάσω εδώ~Αφελής! Αυτό το άρθρο παρουσιάζει εν συντομία τις δύο μορφές αρχιτεκτονικής C/S, πρώτα απ 'όλα, την πιο ουσιαστική διαφορά τους, δηλαδή, το RPC βασίζεται κυρίως στο πρωτόκολλο TCP/IP, ενώ η υπηρεσία HTTP βασίζεται κυρίως στο πρωτόκολλο HTTP, όλοι γνωρίζουμε ότι το πρωτόκολλο HTTP βρίσκεται πάνω από το πρωτόκολλο επιπέδου μεταφοράς TCP, οπότε όσον αφορά την αποτελεσματικότητα, το RPC είναι φυσικά καλύτερο! Ας μιλήσουμε αναλυτικά για τις υπηρεσίες RPC και τις υπηρεσίες HTTP.
Μοντέλο επτά επιπέδων δικτύου OSI
Πριν μιλήσω για τη διαφορά μεταξύ RPC και HTTP, πιστεύω ότι είναι απαραίτητο να κατανοήσουμε το μοντέλο δομής δικτύου επτά επιπέδων του OSI (αν και είναι βασικά πέντε επίπεδα στην πράξη), το οποίο μπορεί να χωριστεί στα ακόλουθα επίπεδα: (από πάνω προς τα κάτω)
- Το πρώτο στρώμα: στρώμα εφαρμογής. Ορίζονται διεπαφές για επικοινωνία και μετάδοση δεδομένων στο δίκτυο.
- Το δεύτερο επίπεδο: το επίπεδο αναπαράστασης. Καθορισμός της μορφής μετάδοσης, των προδιαγραφών κωδικοποίησης και αποκωδικοποίησης δεδομένων σε διαφορετικά συστήματα κ.λπ.
- Το τρίτο επίπεδο: το επίπεδο συνομιλίας. Διαχειριστείτε τις περιόδους λειτουργίας των χρηστών και ελέγξτε τη δημιουργία και τη διακοπή των λογικών συνδέσεων μεταξύ των χρηστών.
- Το τέταρτο στρώμα: το στρώμα μεταφοράς. Διαχειρίζεται τη μετάδοση δεδομένων από άκρο σε άκρο στο δίκτυο.
- Επίπεδο 5: Επίπεδο δικτύου. Καθορίστε τον τρόπο μεταφοράς δεδομένων μεταξύ συσκευών δικτύου.
- Έκτο επίπεδο: στρώμα συνδέσμου. Τα πακέτα δεδομένων του παραπάνω επιπέδου δικτύου είναι ενθυλακωμένα σε πλαίσια δεδομένων για να διευκολύνουν τη μετάδοση του φυσικού επιπέδου.
- Επίπεδο 7: Φυσικό επίπεδο. Αυτό το επίπεδο αφορά κυρίως τη μετάδοση αυτών των δυαδικών δεδομένων.
Στην πρακτική εφαρμογή, δεν υπάρχει επίπεδο παρουσίασης και επίπεδο συνεδρίας στη δομή πρωτοκόλλου πέντε επιπέδων. Πρέπει να πούμε ότι συγχωνεύονται με το επίπεδο εφαρμογής. Θα πρέπει να επικεντρωθούμε στο επίπεδο εφαρμογής και στο επίπεδο μεταφοράς. Επειδή το HTTP είναι ένα πρωτόκολλο επιπέδου εφαρμογής, ενώ το TCP είναι ένα πρωτόκολλο επιπέδου μεταφοράς. Λοιπόν, τώρα που γνωρίζουμε το μοντέλο διαστρωμάτωσης δικτύου, μπορούμε να καταλάβουμε καλύτερα γιατί οι υπηρεσίες RPC είναι καλύτερες από τις υπηρεσίες HTTP!
Υπηρεσίες RPC
Οι υπηρεσίες RPC εισάγονται από τρεις οπτικές γωνίες: αρχιτεκτονική RPC, σύγχρονες ασύγχρονες κλήσεις και δημοφιλή πλαίσια RPC.
Αρχιτεκτονική RPC
Ας μιλήσουμε για τη βασική αρχιτεκτονική των υπηρεσιών RPC. Επιτρέψτε μου να κλέψω ντροπιαστικά μια εικόνα~ Μπορούμε να δούμε ξεκάθαρα ότι μια πλήρης αρχιτεκτονική RPC περιέχει τέσσερα βασικά στοιχεία, δηλαδή Client, Server, Client Stub και Server Stub, τα οποία μπορούν να γίνουν κατανοητά ως στέλεχος. Ας μιλήσουμε για αυτά τα στοιχεία ξεχωριστά:
- Πελάτης, ο καλών της υπηρεσίας.
- Server, ο πραγματικός πάροχος υπηρεσιών.
- Το στέλεχος πελάτη αποθηκεύει το μήνυμα διεύθυνσης του διακομιστή και, στη συνέχεια, συσκευάζει τις παραμέτρους αίτησης του πελάτη σε ένα μήνυμα δικτύου και, στη συνέχεια, το στέλνει στον εξυπηρετητή απομακρυσμένα μέσω του δικτύου.
- Το στέλεχος από την πλευρά του διακομιστή λαμβάνει μηνύματα που αποστέλλονται από τον πελάτη, αποσυμπιέζει τα μηνύματα και καλεί τοπικές μεθόδους.
Το RPC χρησιμοποιείται κυρίως σε μεγάλες επιχειρήσεις, επειδή οι μεγάλες επιχειρήσεις έχουν πολλά συστήματα, πολύπλοκες επιχειρηματικές γραμμές και τα πλεονεκτήματα απόδοσης είναι πολύ σημαντικά. Αυτό γίνεται στην πραγματική ανάπτυξη και η διαχείριση των έργων γίνεται γενικά με τη χρήση maven. Για παράδειγμα, έχουμε μια υπηρεσία συστήματος που επεξεργάζεται παραγγελίες, δηλώνει πρώτα όλες τις διεπαφές της (εδώ συγκεκριμένα τη διεπαφή σε Java) και στη συνέχεια συσκευάζει ολόκληρο το έργο σε ένα πακέτο jar. Γιατί να το κάνετε αυτό; Ο κύριος σκοπός είναι να μειωθεί το μέγεθος της συσκευασίας του βάζου από την πλευρά του πελάτη, επειδή κάθε φορά που απελευθερώνεται ένα πακέτο, πάρα πολλά πακέτα βάζων θα επηρεάζουν πάντα την απόδοση. Επίσης, αποσυνδέει τον πελάτη και τον διακομιστή για να βελτιώσει τη φορητότητα του κώδικα.
Σύγχρονες και ασύγχρονες κλήσεις
Τι είναι η Σύγχρονη Κλήση; Τι είναι η ασύγχρονη κλήση; Μια σύγχρονη κλήση είναι όταν ο υπολογιστής-πελάτης περιμένει να ολοκληρωθεί η εκτέλεση της κλήσης και επιστρέφει το αποτέλεσμα. Οι ασύγχρονες κλήσεις σημαίνουν ότι ο πελάτης δεν περιμένει να εκτελεστεί η κλήση και να επιστρέψει το αποτέλεσμα, αλλά μπορεί να λάβει την ειδοποίηση για το αποτέλεσμα επιστροφής μέσω της λειτουργίας επανάκλησης. Εάν ο πελάτης δεν ενδιαφέρεται για το αποτέλεσμα, μπορεί να μετατραπεί σε μονόδρομη κλήση. Αυτή η διαδικασία είναι κάπως παρόμοια με τις διεπαφές με δυνατότητα κλήσης και εκτέλεσης στην Java, όταν εκτελούμε ασύγχρονα, εάν πρέπει να γνωρίζουμε το αποτέλεσμα της εκτέλεσης, μπορούμε να χρησιμοποιήσουμε τη διεπαφή με δυνατότητα κλήσης και μπορούμε να λάβουμε τις πληροφορίες αποτελέσματος της ασύγχρονης εκτέλεσης μέσω της κλάσης Future. Εάν δεν σας ενδιαφέρει το αποτέλεσμα εκτέλεσης, μπορείτε απλώς να χρησιμοποιήσετε τη διεπαφή με δυνατότητα εκτέλεσης επειδή δεν επιστρέφει το αποτέλεσμα, φυσικά, είναι επίσης δυνατή η κλήση, δεν χρειάζεται να πάρουμε το μέλλον.
Δημοφιλές πλαίσιο RPC
Υπάρχουν ακόμα πολλά δημοφιλή πλαίσια RPC ανοιχτού κώδικα. Ακολουθούν τρία κύρια σημεία:
- Το gRPC είναι ένα λογισμικό ανοιχτού κώδικα που ανακοινώθηκε πρόσφατα από την Google, βασισμένο στο πιο πρόσφατο πρωτόκολλο HTTP 2.0 και υποστηρίζει πολλές κοινές γλώσσες προγραμματισμού. Γνωρίζουμε ότι το HTTP 2.0 είναι μια αναβαθμισμένη έκδοση του πρωτοκόλλου HTTP που βασίζεται σε δυαδικό αρχείο και τα μεγάλα προγράμματα περιήγησης το υποστηρίζουν επί του παρόντος με γρήγορους ρυθμούς. Αυτό το πλαίσιο RPC βασίζεται στο πρωτόκολλο HTTP και το υποκείμενο χρησιμοποιεί την υποστήριξη του πλαισίου Netty.
- Το Thrift είναι ένα έργο ανοιχτού κώδικα για το Facebook, κυρίως ένα πλαίσιο ανάπτυξης διαγλωσσικών υπηρεσιών. Διαθέτει μια γεννήτρια κώδικα για την αυτόματη δημιουργία ενός πλαισίου κώδικα υπηρεσίας για το αρχείο ορισμού IDL που ορίζει. Οι χρήστες χρειάζεται μόνο να πραγματοποιήσουν δευτερεύουσα ανάπτυξη πριν από αυτήν και η υποκείμενη επικοινωνία RPC είναι διαφανής. Ωστόσο, για τους χρήστες, εξακολουθεί να υπάρχει ένα συγκεκριμένο κόστος για την εκμάθηση της γλώσσας ενός συγκεκριμένου τομέα.
- Το Dubbo είναι ένα πολύ γνωστό πλαίσιο RPC ανοιχτού κώδικα από τον Όμιλο Alibaba, το οποίο χρησιμοποιείται ευρέως σε πολλές εταιρείες Διαδικτύου και εταιρικές εφαρμογές. Τόσο τα πρωτόκολλα όσο και τα πλαίσια σειριοποίησης μπορούν να συνδεθούν. Η ίδια απομακρυσμένη διεπαφή βασίζεται στη διεπαφή Java και βασίζεται στο πλαίσιο ελατηρίου για εύκολη ανάπτυξη. Μπορεί εύκολα να συσκευαστεί σε ένα μόνο αρχείο και να εκτελεστεί ανεξάρτητα, κάτι που συνάδει με την τρέχουσα έννοια των μικροϋπηρεσιών.
Σας λέω κρυφά ότι η ομάδα δεν χρησιμοποιεί πια πολύ dubbo,Αυτό που χρησιμοποιείται πιο συχνά τώρα ονομάζεται HSF, γνωστό και ως «τόσο άνετο». Μπορεί να υπάρξει ανοιχτός κώδικας αργότερα, οπότε ας περιμένουμε να δούμε.
Υπηρεσία HTTP
Στην πραγματικότητα, πριν από πολύ καιρό, πάντα χαρακτήριζα το μοντέλο ανάπτυξης της επιχείρησης ως ανάπτυξη διεπαφής HTTP, που είναι αυτό που συχνά ονομάζουμε διεπαφές υπηρεσιών τύπου RESTful. Πράγματι, είναι μια μέθοδος επικοινωνίας που χρησιμοποιείται συχνά στο αρχικό στάδιο της επίλυσης νησίδων πληροφοριών στην περίπτωση λίγων διεπαφών και λιγότερης αλληλεπίδρασης μεταξύ συστημάτων. Τα πλεονεκτήματα είναι απλά, άμεσα και εύκολα στην ανάπτυξη. Χρησιμοποιήστε το έτοιμο πρωτόκολλο HTTP για μετάδοση. Θυμόμαστε ότι όταν κάναμε ανάπτυξη παρασκηνίου στην εταιρεία πριν, αναπτύξαμε κυρίως διεπαφές και έπρεπε επίσης να γράψουμε ένα μεγάλο έγγραφο διεπαφής, υποδεικνύοντας αυστηρά ποια ήταν η είσοδος και η έξοδος. Εξηγήστε τη μέθοδο αιτήματος κάθε διεπαφής και τα θέματα που πρέπει να προσέξετε στις παραμέτρους αιτήματος. Για παράδειγμα, το ακόλουθο παράδειγμα:
ΘΈΣΗhttp://www.httpexample.com/restful/buyer/info/share
Η διασύνδεση μπορεί να επιστρέψει μια συμβολοσειρά JSON ή ένα έγγραφο XML. Στη συνέχεια, ο πελάτης επεξεργάζεται αυτές τις επιστρεφόμενες πληροφορίες, επιτρέποντας ταχύτερη ανάπτυξη. Ωστόσο, για μεγάλες επιχειρήσεις, όταν υπάρχουν πολλά εσωτερικά υποσυστήματα και πολλές διεπαφές, εμφανίζονται τα πλεονεκτήματα του πλαισίου RPC, πρώτα απ 'όλα, είναι ένας μακρύς σύνδεσμος και δεν χρειάζεται να κάνετε χειραψία 3 φορές όπως το http κάθε φορά, μειώνοντας τα γενικά έξοδα δικτύου. Δεύτερον, το πλαίσιο RPC έχει γενικά ένα κέντρο εγγραφής και πλούσια παρακολούθηση και διαχείριση. Η δημοσίευση, οι διεπαφές εκτός σύνδεσης, η δυναμική επέκταση κ.λπ., είναι μη αντιληπτικές και ενοποιημένες λειτουργίες για τον καλούντα.
περίληψη
Σε γενικές γραμμές, οι υπηρεσίες RPC είναι κυρίως για μεγάλες επιχειρήσεις, ενώ οι υπηρεσίες HTTP είναι κυρίως για μικρές επιχειρήσεις, επειδή το RPC είναι πιο αποτελεσματικό και οι επαναλήψεις ανάπτυξης υπηρεσιών HTTP θα είναι πιο γρήγορες. Εν ολίγοις, το είδος του πλαισίου που θα επιλέξετε δεν καθορίζεται από το τι είναι δημοφιλές στην αγορά, αλλά από την πλήρη αξιολόγηση ολόκληρου του έργου, ώστε να συγκρίνετε προσεκτικά τον αντίκτυπο των δύο πλαισίων ανάπτυξης σε ολόκληρο το έργο και τελικά να αποφασίσετε ποιο είναι το καταλληλότερο για το έργο. Δεν πρέπει να χρησιμοποιούμε RPC για κάθε έργο για χάρη της χρήσης RPC, αλλά να προσαρμοζόμαστε στις τοπικές συνθήκες και να αναλύουμε τη συγκεκριμένη κατάσταση.
|
Δημοσιεύτηκε στις 1/4/2019 2:02:45 μ.μ.
|
|
|
|
