Depuis longtemps, je n’ai pas réussi à faire la différence entre RPC (c’est-à-dire appel de procédure à distance) et appels HTTP. Permettez-moi de rire ici~ Naïf ! Cet article présente brièvement les deux formes d’architecture C/S, tout d’abord, leur différence la plus essentielle : le RPC est principalement basé sur le protocole TCP/IP, tandis que le service HTTP est principalement basé sur le protocole HTTP ; nous savons tous que le protocole HTTP repose sur le protocole de couche transport TCP, donc en termes d’efficacité, le RPC est bien sûr meilleur ! Parlons en détail des services RPC et des services HTTP.
Modèle réseau OSI à sept couches
Avant de parler de la différence entre RPC et HTTP, je pense qu’il est nécessaire de comprendre le modèle de structure réseau à sept couches de l’OSI (même s’il est en pratique essentiellement composé de cinq couches), qui peut être divisé en les couches suivantes : (de haut en bas)
- La première couche : la couche application. Des interfaces pour la communication et la transmission de données dans le réseau sont définies ;
- La deuxième couche : la couche de représentation. Définir le format de transmission, les spécifications d’encodage et de décodage des données dans différents systèmes, etc. ;
- La troisième couche : la couche conversation. Gérer les sessions utilisateurs et contrôler l’établissement et l’interruption des connexions logiques entre les utilisateurs.
- La quatrième couche : la couche de transport. Il gère la transmission de données de bout en bout dans le réseau ;
- Couche 5 : Couche réseau. Définir comment les données sont transférées entre les dispositifs réseau ;
- Sixième couche : couche liaison. Les paquets de données de la couche réseau ci-dessus sont encapsulés dans des trames de données pour faciliter la transmission de la couche physique.
- Couche 7 : Couche physique. Cette couche consiste principalement à transmettre ces données binaires.
En pratique, il n’existe pas de couche de présentation ni de couche session dans la structure protocolaire à cinq couches. Il faut préciser qu’ils se fusionnent avec la couche application. Nous devrions nous concentrer sur la couche application et la couche de transport. Parce que HTTP est un protocole de couche application, tandis que TCP est un protocole de couche transport. Eh bien, maintenant que nous connaissons le modèle de superposition réseau, nous pouvons mieux comprendre pourquoi les services RPC sont meilleurs que les services HTTP !
Services RPC
Les services RPC sont introduits sous trois angles : l’architecture RPC, les appels synchrones asynchrones et les frameworks RPC populaires.
Architecture RPC
Parlons de l’architecture de base des services RPC. Permettez-moi de vous emparer honteusement d’une image~ Nous pouvons clairement voir qu’une architecture RPC complète contient quatre composants principaux, à savoir Client, Serveur, Client Stub et Server Stub, qui peuvent être compris comme un stub. Parlons séparément de ces composants :
- Client, l’appelant du service.
- Le serveur, le vrai fournisseur de services.
- Le stub client stocke le message d’adresse du serveur, puis empaquete les paramètres de requête du client dans un message réseau, avant de les envoyer à distance à la partie du service via le réseau.
- Le stub côté serveur reçoit les messages envoyés par le client, décompresse les messages et appelle des méthodes locales.
La RPC est principalement utilisée dans les grandes entreprises, car les grandes entreprises disposent de nombreux systèmes, de lignes d’activité complexes et des avantages d’efficacité sont très importants. Cela se fait dans le cadre du développement réel, et les projets sont généralement gérés via Maven. Par exemple, nous avons un service système qui traite les ordres, déclare d’abord toutes ses interfaces (ici spécifiquement l’interface en Java), puis empaquete l’ensemble du projet dans un package jar. Pourquoi faire ça ? Le but principal est de réduire la taille du package jar côté client, car à chaque fois qu’un package est publié, trop de packages jar affectent toujours l’efficacité. Il découple également le client et le serveur pour améliorer la portabilité du code.
Appels synchrones et asynchrones
Qu’est-ce que l’appel synchrone ? Qu’est-ce qu’un appel asynchrone ? Un appel synchrone est lorsque le client attend que l’appel soit terminé et retourne le résultat. Les appels asynchrones signifient que le client n’attend pas que l’appel s’exécute pour retourner le résultat, mais peut tout de même recevoir la notification du retour via la fonction de rappel. Si le client ne se soucie pas du résultat, cela peut devenir un appel à sens unique. Ce processus est quelque peu similaire aux interfaces appelables et exécutables en Java : lorsque nous exécutons de manière asynchrone, si nous devons connaître le résultat de l’exécution, nous pouvons utiliser l’interface appelable, et obtenir les informations de résultat de l’exécution asynchrone via la classe Future. Si vous ne vous souciez pas du résultat d’exécution, vous pouvez simplement utiliser l’interface exécutable car elle ne renvoie pas le résultat, bien sûr, appelable est aussi possible, nous n’avons pas besoin d’avoir le futur.
Cadre RPC populaire
Il existe encore de nombreux frameworks RPC open source populaires. Voici trois points forts :
- gRPC est un logiciel open source récemment annoncé par Google, basé sur le dernier protocole HTTP 2.0, et prend en charge de nombreux langages de programmation courants. Nous savons que HTTP 2.0 est une version améliorée du protocole HTTP basée sur le binaire, et que les principaux navigateurs le supportent actuellement à un rythme soutenu. Ce cadre RPC est basé sur le protocole HTTP, et le cadre sous-jacent utilise le support du cadre Netty.
- Thrift est un projet open source pour Facebook, principalement un cadre de développement de services multi-langages. Il dispose d’un générateur de code pour générer automatiquement un cadre de code de service pour le fichier de définition IDL qu’il définit. Les utilisateurs n’ont qu’à effectuer un développement secondaire avant cela, et la communication RPC sous-jacente est transparente. Cependant, pour les utilisateurs, il existe toujours un certain coût pour apprendre la langue d’un domaine spécifique.
- Dubbo est un framework RPC bien connu, open source, développé par le groupe Alibaba, largement utilisé dans de nombreuses entreprises Internet et applications d’entreprise. Les protocoles et les cadres de sérialisation peuvent être branchés. La même interface distante est basée sur l’interface Java et repose sur le framework spring pour un développement facile. Il peut être facilement empaqueté en un seul fichier et exécuté indépendamment, ce qui est cohérent avec le concept actuel de microservices.
Je te disais en secret que le groupe n’utilise plus beaucoup le dubbo,Celui qui est plus couramment utilisé aujourd’hui s’appelle HSF, également appelé « si confortable ». Il pourrait y avoir de l’open source plus tard, alors attendons de voir.
Service HTTP
En fait, il y a longtemps, j’ai toujours caractérisé le modèle de développement d’entreprise comme le développement d’interfaces HTTP, ce que nous appelons souvent des interfaces de service de type RESTful. En effet, c’est une méthode de communication souvent utilisée aux premiers stades de la résolution d’îlots d’information dans le cas de peu d’interfaces et d’interactions entre systèmes moindres ; Les avantages sont simples, directs et faciles à développer. Utilisez le protocole HTTP prêt à l’emploi pour la transmission. Nous nous souvenons que lorsque nous faisions du développement en arrière-plan dans l’entreprise auparavant, nous développions principalement des interfaces, et nous devions aussi écrire un grand document d’interface, indiquant strictement l’entrée et la sortie. Expliquez la méthode de requête de chaque interface et les points à surveiller dans les paramètres de la requête. Par exemple, l’exemple suivant :
PUBLIERhttp://www.httpexample.com/restful/buyer/info/share
L’interface peut renvoyer une chaîne JSON ou un document XML. Le client traite ensuite ces informations retournées, permettant un développement plus rapide. Cependant, pour les grandes entreprises, lorsqu’il existe de nombreux sous-systèmes internes et de nombreuses interfaces, les avantages du cadre RPC sont mis en valeur : tout d’abord, il s’agit d’un long lien, et il n’est pas nécessaire de serrer la main trois fois comme pour http à chaque fois, réduisant ainsi la charge du réseau ; deuxièmement, le cadre RPC dispose généralement d’un centre d’enregistrement et d’un suivi et d’une gestion riches ; La publication, les interfaces hors ligne, l’expansion dynamique, etc., sont des opérations non perceptives et unifiées pour l’appelant.
résumé
De manière générale, les services RPC sont principalement destinés aux grandes entreprises, tandis que les services HTTP sont principalement destinés aux petites entreprises, car le RPC est plus efficace et les itérations de développement des services HTTP seront plus rapides. En résumé, le type de cadre choisi ne dépend pas de ce qui est populaire sur le marché, mais d’évaluer l’ensemble du projet dans son ensemble, afin de comparer soigneusement l’impact des deux cadres de développement sur l’ensemble du projet, et finalement de décider ce qui convient le mieux au projet. Nous ne devons pas utiliser le RPC pour chaque projet juste pour le plaisir, mais nous nous adapter aux conditions locales et analyser la situation spécifique.
|
Publié sur 01/04/2019 14:02:45
|
|
|
|
