Je suis sûr que le titre a provoqué une réaction saine - "Eh bien, ça a recommencé..." Mais laissez-moi capter votre attention pendant 5 à 10 minutes et j'essaierai de ne pas décevoir vos attentes.
La structure de l'article sera la suivante : un énoncé stéréotypé est pris et la « nature » de l'émergence de ce stéréotype est révélée. J'espère que cela vous permettra d'envisager le choix du paradigme d'échange de données dans vos projets sous un nouvel angle.
Afin d'être clair sur ce qu'est RPC, je propose de considérer la norme . Avec REST, il n'y a pas de clarté. Et ça ne devrait pas être le cas. Tout ce que vous devez savoir sur REST - il est impossible de le distinguer de .
Les requêtes RPC sont plus rapides et plus efficaces car elles vous permettent d'effectuer des requêtes par lots.
Le fait est que dans RPC, vous pouvez appeler plusieurs procédures à la fois en une seule requête. Par exemple, créez un utilisateur, ajoutez-lui un avatar et, dans la même demande, abonnez-le à certains sujets. Une seule demande, et quel bénéfice !
En effet, si vous n’avez qu’un seul nœud backend, cela paraîtra plus rapide avec une requête batch. Parce que trois requêtes REST nécessiteront trois fois plus de ressources d'un nœud pour établir des connexions.
Notez que la première requête dans le cas de REST doit renvoyer l'ID utilisateur pour que les requêtes suivantes puissent être effectuées. Ce qui affecte également négativement le résultat global.
Mais de telles infrastructures ne peuvent être trouvées que dans les solutions internes et Enterprise. En dernier recours, dans les petits projets WEB. Mais les solutions WEB à part entière, et même celles appelées HighLoad, ne valent pas la peine d'être construites. Leur infrastructure doit répondre à des critères de haute disponibilité et de charge. Et la situation change.
Les canaux d’activité d’infrastructure dans le même scénario sont marqués en vert. Remarquez comment RPC se comporte maintenant. La requête utilise l'infrastructure sur une seule étape, de l'équilibreur au backend. Bien que REST soit toujours perdant lors de la première requête, il rattrape le temps perdu en utilisant l'ensemble de l'infrastructure.
Il suffit d'inscrire dans le scénario non pas deux demandes d'enrichissement, mais, disons, cinq ou dix... et la réponse à la question « qui gagne maintenant ? devient flou.
Je propose d'examiner le problème de manière encore plus large. Le diagramme montre comment les canaux d'infrastructure sont utilisés, mais l'infrastructure ne se limite pas aux canaux. Les caches constituent un élément important d’une infrastructure à charge élevée. Obtenons maintenant une sorte d'artefact utilisateur. À plusieurs reprises. Disons 32 fois.
Découvrez comment l'infrastructure RPC s'est considérablement améliorée pour répondre aux exigences de charge élevée. Le fait est que REST utilise toute la puissance du protocole HTTP, contrairement à RPC. Dans le diagramme ci-dessus, ce pouvoir est réalisé via la méthode de requête - GET.
Les méthodes HTTP, entre autres, ont des stratégies de mise en cache. Vous pouvez les trouver dans la documentation à l'adresse . Pour RPC, des requêtes POST sont utilisées, qui ne sont pas considérées comme idempotentes, c'est-à-dire que des répétitions répétées des mêmes requêtes POST peuvent renvoyer des résultats différents (par exemple, après l'envoi de chaque commentaire, une autre copie de ce commentaire apparaîtra) ().
Par conséquent, RPC est incapable d’utiliser efficacement les caches d’infrastructure. Cela conduit à la nécessité d’« importer » des caches logiciels. Le diagramme montre Redis dans ce rôle. Le cache logiciel, à son tour, nécessite que le développeur ajoute une couche supplémentaire de code et des changements notables dans l'architecture.
Comptons maintenant combien de requêtes REST et RPC ont « donné naissance » dans l'infrastructure considérée ?
demandes
Boîte de réception
vers le back-end
au SGBD
vers le cache logiciel (Redis)
TOTAL
REST
1 / 32 *
1
1
0
3/35
RPC
32
32
1
31
96
Par rapport au premier schéma, la différence est frappante. L’avantage de REST devient désormais évident. Mais je suggère de ne pas s'arrêter là. L'infrastructure développée comprend un CDN. Souvent, cela résout également le problème de la lutte contre les attaques DDoS et DoS. On a:
C’est là que les choses se gâtent vraiment pour RPC. RPC n'est tout simplement pas capable de déléguer la charge de travail à un CDN. Nous ne pouvons compter que sur des systèmes pour contrer les attaques.
Est-il possible d'en finir ici ? Et encore une fois, non. Les méthodes HTTP, comme mentionné ci-dessus, ont leur propre « magie ». Et ce n’est pas pour rien que la méthode GET est largement utilisée sur Internet. Notez que cette méthode est capable d'accéder à un élément de contenu, de définir des conditions que les éléments d'infrastructure peuvent interpréter avant que le contrôle ne soit transféré à votre code, etc. Tout cela vous permet de créer des infrastructures flexibles et gérables, capables de gérer des flux de demandes très importants. Mais dans RPC, cette méthode... est ignorée.
Alors pourquoi le mythe selon lequel les requêtes par lots (RPC) sont plus rapides est-il si persistant ? Personnellement, il me semble que la plupart des projets n'atteignent tout simplement pas un niveau de développement où REST puisse montrer sa force. De plus, dans les petits projets, il est plus disposé à montrer ses faiblesses.
Le choix de REST ou RPC n'est pas un choix volontaire d'un individu dans un projet. Ce choix doit répondre aux exigences du projet. Si un projet est capable d'extraire tout ce qu'il peut de REST et qu'il en a vraiment besoin, alors REST sera un excellent choix.
Mais si, pour bénéficier de tous les avantages de REST, vous avez besoin d'embaucher des spécialistes DevOps pour que le projet fasse évoluer rapidement l'infrastructure, des administrateurs pour gérer l'infrastructure, un architecte pour concevoir toutes les couches du service WEB... et le projet , en même temps, vend trois paquets de margarine par jour... Je resterais avec RPC, parce que... ce protocole est plus utilitaire. Cela ne nécessitera pas une connaissance approfondie du fonctionnement des caches et de l'infrastructure, mais concentrera le développeur sur des appels simples et compréhensibles aux procédures dont il a besoin. Les affaires seront heureuses.
Les requêtes RPC sont plus fiables car elles peuvent exécuter des requêtes par lots en une seule transaction
Cette propriété de RPC est un avantage certain, car Il est facile de maintenir la cohérence de la base de données. Mais avec REST, cela devient de plus en plus compliqué. Les requêtes peuvent arriver de manière incohérente aux différents nœuds backend.
Cet « inconvénient » de REST est le revers de son avantage décrit ci-dessus : la capacité d'utiliser efficacement toutes les ressources de l'infrastructure. Si l’infrastructure est mal conçue, et encore plus si l’architecture du projet et la base de données en particulier sont mal conçues, alors c’est vraiment très pénible.
Mais les requêtes par lots sont-elles aussi fiables qu’il y paraît ? Regardons un cas : nous créons un utilisateur, enrichissons son profil avec une description et lui envoyons un SMS avec un secret pour finaliser son inscription. Ceux. trois appels dans une seule demande groupée.
Regardons le diagramme. Il présente une infrastructure avec des éléments à haute disponibilité. Il existe deux canaux de communication indépendants avec des passerelles SMS. Mais... que voit-on ? Lors de l'envoi d'un SMS, l'erreur 503 se produit - le service est temporairement indisponible. Parce que L'envoi de SMS est conditionné dans une requête groupée, puis l'intégralité de la requête doit être annulée. Les actions dans le SGBD sont annulées. Le client reçoit une erreur.
Le prochain essai est la loterie. Soit la requête frappera le même nœud encore et encore et renverra une erreur, soit vous aurez de la chance et elle sera exécutée. Mais l'essentiel est qu'au moins une fois, notre infrastructure a déjà fonctionné en vain. Il y avait une charge, mais aucun profit.
D'accord, imaginons que nous nous sommes mis à rude épreuve (!) et avons réfléchi à l'option lorsque la demande peut être partiellement complétée avec succès. Et nous essaierons de compléter le reste après un certain temps (lequel ? Le front décide-t-il ?). Mais la loterie est restée la même. La demande d'envoi de SMS a 50/50 de chances d'échouer à nouveau.
D'accord, du côté client, le service ne semble pas aussi fiable qu'on le souhaiterait... qu'en est-il de REST ?
REST utilise à nouveau la magie du HTTP, mais désormais avec des codes de réponse. Lorsqu'une erreur 503 se produit sur la passerelle SMS, le backend diffuse cette erreur à l'équilibreur. L'équilibreur reçoit cette erreur et, sans rompre la connexion avec le client, envoie la requête à un autre nœud, qui traite avec succès la requête. Ceux. le client obtient le résultat attendu et l'infrastructure confirme son titre élevé de « hautement accessible ». L'utilisateur est content.
Et encore une fois, ce n'est pas tout. L'équilibreur n'a pas seulement reçu un code de réponse de 503. Lors de la réponse, selon la norme, il est conseillé de fournir ce code avec l'en-tête « Retry-After ». L'en-tête indique clairement à l'équilibreur qu'il ne vaut pas la peine de perturber ce nœud sur cette route pendant une durée spécifiée. Et les prochaines demandes d'envoi de SMS seront envoyées directement à un nœud qui n'a aucun problème avec la passerelle SMS.
Comme nous pouvons le constater, la fiabilité de JSON-RPC est surfaite. En effet, il est plus simple d’organiser la cohérence dans la base de données. Mais le sacrifice, dans ce cas, sera la fiabilité du système dans son ensemble.
La conclusion est largement similaire à la précédente. Lorsque l’infrastructure est simple, l’évidence du JSON-RPC est définitivement un plus. Si le projet implique une haute disponibilité avec une charge élevée, REST semble être une solution plus correcte, bien que plus complexe.
Le seuil d’entrée à REST est inférieur
Je pense que l'analyse ci-dessus, démystifiant les stéréotypes établis sur le RPC, a clairement montré que le seuil d'entrée dans REST est sans aucun doute plus élevé que dans RPC. Cela est dû à la nécessité d'une compréhension approfondie du fonctionnement de HTTP, ainsi qu'à la nécessité d'avoir des connaissances suffisantes sur les éléments d'infrastructure existants qui peuvent et doivent être utilisés dans les projets WEB.
Alors pourquoi beaucoup de gens pensent que REST sera plus simple ? Mon opinion personnelle est que cette apparente simplicité vient du REST qui se manifeste. Ceux. REST n'est pas un protocole mais un concept... REST n'a pas de standard, il existe quelques lignes directrices... REST n'est pas plus compliqué que HTTP. La liberté et l’anarchie apparentes attirent les « artistes libres ».
Bien entendu, REST n’est pas plus compliqué que HTTP. Mais HTTP lui-même est un protocole bien conçu qui a fait ses preuves au fil des décennies. S'il n'y a pas de compréhension approfondie de HTTP lui-même, alors REST ne peut pas être jugé.
Mais à propos de RPC, vous le pouvez. Il suffit de prendre sa spécification. Alors as-tu besoin ? Ou est-ce que c'est encore un REST délicat ? Tu décides.
J'espère sincèrement que je n'ai pas perdu votre temps.
Source: habr.com