Είμαι βέβαιος ότι ο τίτλος προκάλεσε μια υγιή αντίδραση - "Λοιπόν, άρχισε πάλι..." Αλλά επιτρέψτε μου να τραβήξω την προσοχή σας για 5-10 λεπτά και θα προσπαθήσω να μην απογοητεύσω τις προσδοκίες σας.
Η δομή του άρθρου θα είναι η εξής: λαμβάνεται μια στερεότυπη δήλωση και αποκαλύπτεται η «φύση» της εμφάνισης αυτού του στερεότυπου. Ελπίζω ότι αυτό θα σας επιτρέψει να δείτε την επιλογή του παραδείγματος ανταλλαγής δεδομένων στα έργα σας από μια νέα οπτική γωνία.
Για να είμαστε σαφείς σχετικά με το τι είναι το RPC, προτείνω να εξετάσουμε το πρότυπο . Με το REST δεν υπάρχει σαφήνεια. Και δεν πρέπει να είναι. Όλα όσα πρέπει να ξέρετε για το REST - δεν διακρίνεται από αυτό .
Τα αιτήματα RPC είναι πιο γρήγορα και πιο αποτελεσματικά, επειδή σας επιτρέπουν να κάνετε μαζικά αιτήματα.
Το θέμα είναι ότι στο RPC μπορείτε να καλέσετε πολλές διαδικασίες ταυτόχρονα σε ένα αίτημα. Για παράδειγμα, δημιουργήστε έναν χρήστη, προσθέστε ένα avatar σε αυτόν και, στο ίδιο αίτημα, εγγραφείτε σε ορισμένα θέματα. Μόνο ένα αίτημα, και πόσα οφέλη!
Πράγματι, εάν έχετε μόνο έναν κόμβο υποστήριξης, θα φαίνεται πιο γρήγορος με ένα αίτημα παρτίδας. Επειδή τρία αιτήματα REST θα απαιτήσουν τρεις φορές περισσότερους πόρους από έναν κόμβο για τη δημιουργία συνδέσεων.
Σημειώστε ότι το πρώτο αίτημα στην περίπτωση REST πρέπει να επιστρέψει το αναγνωριστικό χρήστη για να υποβληθούν επόμενα αιτήματα. Κάτι που επηρεάζει αρνητικά και το συνολικό αποτέλεσμα.
Αλλά τέτοιες υποδομές μπορούν να βρεθούν μόνο σε εσωτερικές λύσεις και Enterprise. Ως έσχατη λύση, σε μικρά έργα WEB. Αλλά οι ολοκληρωμένες λύσεις WEB, ακόμη και αυτές που ονομάζονται HighLoad, δεν αξίζει να δημιουργηθούν. Η υποδομή τους πρέπει να πληροί τα κριτήρια της υψηλής διαθεσιμότητας και φόρτου. Και η εικόνα αλλάζει.
Τα κανάλια δραστηριότητας υποδομής στο ίδιο σενάριο επισημαίνονται με πράσινο χρώμα. Παρατηρήστε πώς συμπεριφέρεται το RPC τώρα. Το αίτημα χρησιμοποιεί την υποδομή μόνο σε ένα σκέλος από το balancer στο backend. Ενώ το REST εξακολουθεί να χάνει στο πρώτο αίτημα, αναπληρώνει τον χαμένο χρόνο χρησιμοποιώντας ολόκληρη την υποδομή.
Αρκεί να μπουν στο σενάριο όχι δύο αιτήματα για εμπλουτισμό, αλλά, ας πούμε, πέντε ή δέκα... και η απάντηση στο ερώτημα "ποιος κερδίζει τώρα;" γίνεται ασαφές.
Предлагаю глянуть еще шире на проблему. На схеме видно, как используются каналы инфраструктуры, но инфраструктура не ограничивается каналами. Важной составляющей высоконагруженной инфраструктуры являются кэши. Давайте теперь получим какой-то артефакт пользователя. Несколько раз. Скажем 32 раза.
Δείτε πώς η υποδομή RPC έχει βελτιωθεί σημαντικά για να καλύψει τις απαιτήσεις υψηλού φορτίου. Το θέμα είναι ότι το REST χρησιμοποιεί την πλήρη ισχύ του πρωτοκόλλου HTTP, σε αντίθεση με το RPC. Στο παραπάνω διάγραμμα, αυτή η ισχύς πραγματοποιείται μέσω της μεθόδου αιτήματος - GET.
Οι μέθοδοι HTTP, μεταξύ άλλων, έχουν στρατηγικές προσωρινής αποθήκευσης. Μπορείτε να τα βρείτε στην τεκμηρίωση στο . Για το RPC, χρησιμοποιούνται αιτήματα POST, τα οποία δεν θεωρούνται ανίκανα, δηλαδή, οι επαναλαμβανόμενες επαναλήψεις των ίδιων αιτημάτων POST ενδέχεται να αποφέρουν διαφορετικά αποτελέσματα (για παράδειγμα, μετά την αποστολή κάθε σχολίου, θα εμφανίζεται ένα άλλο αντίγραφο αυτού του σχολίου) ().
Κατά συνέπεια, το RPC δεν μπορεί να χρησιμοποιήσει αποτελεσματικά τις κρυφές μνήμες υποδομής. Αυτό οδηγεί στην ανάγκη «εισαγωγής» κρυφής μνήμης λογισμικού. Το διάγραμμα δείχνει τον Redis σε αυτόν τον ρόλο. Η κρυφή μνήμη λογισμικού, με τη σειρά της, απαιτεί από τον προγραμματιστή να προσθέσει ένα επιπλέον επίπεδο κώδικα και αξιοσημείωτες αλλαγές στην αρχιτεκτονική.
Ας μετρήσουμε τώρα πόσα αιτήματα «γέννησαν» το REST και το RPC στην υπό εξέταση υποδομή;
αιτήσεις
Εισερχόμενα
στο backend
στο DBMS
σε μαλακή κρυφή μνήμη (Redis)
ΣΥΝΟΛΟ
ΠΕΡΙΦΕΡΕΙΑ
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Σε σύγκριση με το πρώτο σχήμα, η διαφορά είναι εντυπωσιακή. Τώρα το όφελος του REST γίνεται σαφές. Αλλά προτείνω να μην σταματήσουμε εκεί. Η αναπτυγμένη υποδομή περιλαμβάνει ένα CDN. Συχνά λύνει επίσης το ζήτημα της αντιμετώπισης επιθέσεων DDoS και DoS. Παίρνουμε:
Εδώ είναι που τα πράγματα γίνονται πολύ άσχημα για το RPC. Το RPC απλά δεν είναι ικανό να εκχωρήσει τον φόρτο εργασίας σε ένα CDN. Μπορούμε να βασιστούμε μόνο σε συστήματα για την αντιμετώπιση επιθέσεων.
Είναι δυνατόν να τελειώσουμε εδώ; Και πάλι όχι. Οι μέθοδοι HTTP, όπως αναφέρθηκε παραπάνω, έχουν τη δική τους «μαγεία». Και δεν είναι χωρίς λόγο ότι η μέθοδος GET χρησιμοποιείται ευρέως στο Διαδίκτυο. Σημειώστε ότι αυτή η μέθοδος είναι σε θέση να έχει πρόσβαση σε ένα τμήμα περιεχομένου, μπορεί να ορίσει συνθήκες που τα στοιχεία υποδομής μπορούν να ερμηνεύσουν πριν μεταφερθεί ο έλεγχος στον κώδικά σας κ.λπ. Όλα αυτά σας επιτρέπουν να δημιουργήσετε ευέλικτες, διαχειρίσιμες υποδομές που μπορούν να χειριστούν πραγματικά μεγάλες ροές αιτημάτων. Αλλά στο RPC αυτή η μέθοδος... αγνοείται.
Γιατί λοιπόν είναι τόσο επίμονος ο μύθος ότι τα αιτήματα παρτίδας (RPC) είναι ταχύτερα; Προσωπικά, μου φαίνεται ότι τα περισσότερα έργα απλά δεν φτάνουν σε ένα επίπεδο ανάπτυξης όπου το REST μπορεί να δείξει τη δύναμή του. Επιπλέον, σε μικρά έργα είναι πιο πρόθυμος να δείξει τις αδυναμίες του.
Η επιλογή REST ή RPC δεν είναι ηθελημένη επιλογή ενός ατόμου σε ένα έργο. Αυτή η επιλογή πρέπει να πληροί τις απαιτήσεις του έργου. Εάν ένα έργο είναι σε θέση να αποσπάσει ό,τι πραγματικά μπορεί από το REST, και το χρειάζεται πραγματικά, τότε το REST θα είναι μια εξαιρετική επιλογή.
Αλλά εάν, για να λάβετε όλα τα πλεονεκτήματα του REST, πρέπει να προσλάβετε ειδικούς devop για το έργο για γρήγορη κλιμάκωση της υποδομής, διαχειριστές για τη διαχείριση της υποδομής, έναν αρχιτέκτονα για να σχεδιάσει όλα τα επίπεδα της υπηρεσίας WEB... και το έργο , ταυτόχρονα, πουλάει τρεις συσκευασίες μαργαρίνη την ημέρα... Θα κολλούσα με RPC, γιατί... αυτό το πρωτόκολλο είναι πιο χρηστικό. Δεν θα απαιτήσει βαθιά γνώση του τρόπου λειτουργίας της κρυφής μνήμης και της υποδομής, αλλά θα εστιάσει τον προγραμματιστή σε απλές και κατανοητές κλήσεις στις διαδικασίες που χρειάζεται. Οι επιχειρήσεις θα είναι ευχαριστημένες.
Τα αιτήματα RPC είναι πιο αξιόπιστα επειδή μπορούν να εκτελέσουν ομαδικές αιτήσεις σε μία μόνο συναλλαγή
Αυτή η ιδιότητα του RPC είναι ένα σαφές πλεονέκτημα, γιατί Είναι εύκολο να διατηρήσετε τη βάση δεδομένων συνεπή. Αλλά με το REST γίνεται όλο και πιο περίπλοκο. Τα αιτήματα ενδέχεται να φτάνουν ασυνεπή σε διαφορετικούς κόμβους υποστήριξης.
Αυτό το «μειονέκτημα» του REST είναι η άλλη πλευρά του πλεονεκτήματος που περιγράφηκε παραπάνω - η ικανότητα αποτελεσματικής χρήσης όλων των πόρων υποδομής. Εάν η υποδομή είναι κακώς σχεδιασμένη, και ακόμη περισσότερο εάν η αρχιτεκτονική του έργου και ειδικότερα η βάση δεδομένων είναι κακώς σχεδιασμένα, τότε αυτό είναι πραγματικά μεγάλος πόνος.
Είναι όμως τα αιτήματα παρτίδας τόσο αξιόπιστα όσο φαίνονται; Ας δούμε μια περίπτωση: δημιουργούμε έναν χρήστη, εμπλουτίζουμε το προφίλ του με κάποια περιγραφή και του στέλνουμε ένα SMS με ένα μυστικό για την ολοκλήρωση της εγγραφής. Εκείνοι. τρεις κλήσεις σε ένα αίτημα παρτίδας.
Ας δούμε το διάγραμμα. Παρουσιάζει μια υποδομή με στοιχεία υψηλής διαθεσιμότητας. Υπάρχουν δύο ανεξάρτητα κανάλια επικοινωνίας με πύλες SMS. Μα... τι βλέπουμε; Κατά την αποστολή ενός SMS, εμφανίζεται ένα σφάλμα 503 - η υπηρεσία δεν είναι προσωρινά διαθέσιμη. Επειδή Η αποστολή SMS συσκευάζεται σε ένα αίτημα δέσμης και, στη συνέχεια, ολόκληρο το αίτημα πρέπει να επιστραφεί. Οι ενέργειες στο DBMS ακυρώνονται. Ο πελάτης λαμβάνει ένα σφάλμα.
Η επόμενη προσπάθεια είναι η κλήρωση. Είτε το αίτημα θα χτυπήσει ξανά τον ίδιο κόμβο και θα επιστρέψει ξανά ένα σφάλμα, είτε θα είστε τυχεροί και θα εκτελεστεί. Αλλά το κυριότερο είναι ότι τουλάχιστον μια φορά η υποδομή μας έχει ήδη λειτουργήσει μάταια. Υπήρχε φορτίο, αλλά κανένα κέρδος.
Εντάξει, ας φανταστούμε ότι καταπονηθήκαμε (!) και σκεφτήκαμε την επιλογή πότε το αίτημα μπορεί να ολοκληρωθεί εν μέρει με επιτυχία. Και τα υπόλοιπα θα προσπαθήσουμε να τα ολοκληρώσουμε ξανά μετά από κάποιο χρονικό διάστημα (Ποιο; Το μπροστινό αποφασίζει;). Όμως το λαχείο παρέμεινε το ίδιο. Το αίτημα για αποστολή SMS έχει 50/50 πιθανότητες να αποτύχει ξανά.
Συμφωνώ, από την πλευρά του πελάτη, η υπηρεσία δεν φαίνεται τόσο αξιόπιστη όσο θα θέλαμε... τι γίνεται με το REST;
Το REST χρησιμοποιεί ξανά τη μαγεία του HTTP, αλλά τώρα με κωδικούς απόκρισης. Όταν εμφανίζεται ένα σφάλμα 503 στην πύλη SMS, το backend μεταδίδει αυτό το σφάλμα στον εξισορροπητή. Ο εξισορροπητής λαμβάνει αυτό το σφάλμα και χωρίς να διακόψει τη σύνδεση με τον πελάτη, στέλνει το αίτημα σε άλλο κόμβο, ο οποίος επεξεργάζεται με επιτυχία το αίτημα. Εκείνοι. ο πελάτης λαμβάνει το αναμενόμενο αποτέλεσμα και η υποδομή επιβεβαιώνει τον υψηλό τίτλο της "υψηλής πρόσβασης". Ο χρήστης είναι ευχαριστημένος.
Και πάλι δεν είναι μόνο αυτό. Ο εξισορροπητής δεν έλαβε απλώς έναν κωδικό απόκρισης 503. Κατά την απόκριση, σύμφωνα με το πρότυπο, συνιστάται να παρέχετε αυτόν τον κωδικό με την κεφαλίδα "Επανάληψη-Μετά". Η κεφαλίδα καθιστά σαφές στον εξισορροπητή ότι δεν αξίζει να ενοχλήσετε αυτόν τον κόμβο σε αυτήν τη διαδρομή για ένα συγκεκριμένο χρονικό διάστημα. Και τα επόμενα αιτήματα για αποστολή SMS θα σταλούν απευθείας σε έναν κόμβο που δεν έχει προβλήματα με την πύλη SMS.
Όπως μπορούμε να δούμε, η αξιοπιστία του JSON-RPC είναι υπερεκτιμημένη. Πράγματι, είναι ευκολότερο να οργανωθεί η συνέπεια στη βάση δεδομένων. Αλλά η θυσία, σε αυτή την περίπτωση, θα είναι η αξιοπιστία του συστήματος στο σύνολό του.
Το συμπέρασμα είναι σε μεγάλο βαθμό παρόμοιο με το προηγούμενο. Όταν η υποδομή είναι απλή, το προφανές του JSON-RPC είναι σίγουρα ένα πλεονέκτημα. Εάν το έργο περιλαμβάνει υψηλή διαθεσιμότητα με υψηλό φορτίο, το REST φαίνεται σαν μια πιο σωστή, αν και πιο περίπλοκη, λύση.
Το όριο εισόδου στο REST είναι χαμηλότερο
Νομίζω ότι η παραπάνω ανάλυση, καταρρίπτοντας τα καθιερωμένα στερεότυπα για το RPC, έδειξε ξεκάθαρα ότι το όριο για την είσοδο στο REST είναι αναμφίβολα υψηλότερο από το RPC. Αυτό οφείλεται στην ανάγκη για βαθιά κατανόηση του τρόπου λειτουργίας του HTTP, καθώς και στην ανάγκη να έχουμε επαρκή γνώση σχετικά με τα υπάρχοντα στοιχεία υποδομής που μπορούν και πρέπει να χρησιμοποιηθούν σε έργα WEB.
Γιατί λοιπόν πολλοί άνθρωποι πιστεύουν ότι το REST θα είναι πιο απλό; Η προσωπική μου άποψη είναι ότι αυτή η φαινομενική απλότητα προέρχεται από τα REST που εκδηλώνονται. Εκείνοι. Το REST δεν είναι πρωτόκολλο αλλά έννοια... Το REST δεν έχει πρότυπο, υπάρχουν κάποιες οδηγίες... Το REST δεν είναι πιο περίπλοκο από το HTTP. Η φαινομενική ελευθερία και η αναρχία προσελκύουν «ελεύθερους καλλιτέχνες».
Φυσικά, το REST δεν είναι πιο περίπλοκο από το HTTP. Αλλά το ίδιο το HTTP είναι ένα καλά σχεδιασμένο πρωτόκολλο που έχει αποδείξει την αξία του εδώ και δεκαετίες. Εάν δεν υπάρχει βαθιά κατανόηση του ίδιου του HTTP, τότε το REST δεν μπορεί να κριθεί.
Αλλά για το RPC - μπορείτε. Αρκεί να πάρουμε τις προδιαγραφές του. Χρειάζεστε λοιπόν ? Ή είναι ακόμα δύσκολο REST; Εσύ αποφασίζεις.
Ελπίζω ειλικρινά να μην έχασα τον χρόνο σας.
Πηγή: www.habr.com