gRPC, pionnier de la com­mu­ni­ca­tion client/serveur de l’avenir

La tech­no­lo­gie de réseau progresse de plus en plus ra­pi­de­ment. Pour sa­tis­faire les exigences crois­santes des systèmes in­for­ma­tiques dis­tri­bués, un nouveau système, appelé gRPC, a été mis au point pour la gestion des appels Remote Procedure Calls. Le « g » re­pré­sente la con­tri­bu­tion con­si­dé­rable de Google au dé­ve­lop­pe­ment de ce protocole. Découvrez ici ce qu’est le gRPC, comment il fonc­tionne et où il est utilisé.

Le gRPC est un système d’appels Remote Procedure Call per­met­tant une com­mu­ni­ca­tion par­ti­cu­liè­re­ment efficace au sein d’ar­chi­tec­tures client/serveur dis­tri­buées grâce à des tech­no­lo­gies de procédés innovants. Tout comme son pré­dé­ces­seur le RPC, il fonc­tionne au niveau des processus. La ca­rac­té­ris­tique de la com­mu­ni­ca­tion inter-processus via gRPC est le principe de trans­pa­rence : la relation entre les instances (par­tiel­le­ment) éloignées se veut aussi étroite et simple qu’une com­mu­ni­ca­tion locale entre plusieurs processus internes d’une même machine.

Le gRPC a été mis au point par Google en 2015. Aujourd’hui, la Cloud Native Computing Foun­da­tion prend en charge la diffusion et le dé­ve­lop­pe­ment de cette technique de com­mu­ni­ca­tion. Le gRPC est Open Source, ce qui signifie que son texte source fait partie du domaine public, les tiers sont autorisés et même en­cou­ra­gés à le modifier et à en pour­suivre le dé­ve­lop­pe­ment.

Le gRPC traite de manière nor­ma­li­sée le transport de flux de données entre des or­di­na­teurs distants via le protocole HTTP/2. Les Protocol Buffers dé­ve­lop­pés par Google prennent en charge la struc­tu­ra­tion et le trai­te­ment des données. Ces derniers sont en­re­gis­trés sous forme de simples fichiers textes portant l’extension .proto.

Le gRPC est souvent entendu comme un framework. L’une des par­ti­cu­la­ri­tés d’un framework est qu’il met un cadre de pro­gram­ma­tion à dis­po­si­tion de ses dé­ve­lop­peurs, épargnant ainsi du temps et des efforts. La structure nor­ma­li­sée de gRPC intègre déjà dif­fé­rents éléments et fonctions qu’il n’est alors pas né­ces­saire de toujours re­pro­gram­mer. Le framework gRPC définit en outre des in­ter­faces nor­ma­li­sées pour des sources définies (par exemple bases de données).

Lors de la con­sul­ta­tion d’une base de données re­cher­chant un produit en stock (inventory), les premières étapes concrètes sont indiquées comme suit dans la syntaxe actuelle des Protocol Buffers (version : proto3) :

Le gRPC présente de nombreux avantages : cette tech­no­lo­gie est re­la­ti­ve­ment simple à mettre en œuvre, dans la mesure où elle utilise un IDL simple et très facile d’uti­li­sa­tion pour la création des fichiers .proto. De cette manière, même des pro­grammes anciens peuvent être fa­ci­le­ment complétés par une interface gRPC per­for­mante et il est ainsi possible de trans­fé­rer beaucoup plus ra­pi­de­ment des fichiers vo­lu­mi­neux.

Par ailleurs, le gRPC a fait l’objet de nombreux tests et est hautement évolutif, ce qui lui permet de mener à bien les com­mu­ni­ca­tions les plus complexes et ex­haus­tives, au sein d’ar­chi­tec­tures client/serveur con­nec­tées à l’échelle in­ter­na­tio­nale par exemple. HTTP/2 augmente ses per­for­mances, entre autres, grâce à ses capacités de mul­ti­plexage et de streaming bi­di­rec­tion­nel. Des com­pres­sions d’en-têtes sont également possibles lorsque le volume de données des requêtes et réponses doit être sig­ni­fi­ca­ti­ve­ment réduit dans le réseau.

La structure multi-couches et fortement nor­ma­li­sée du framework gRPC permet de réduire les efforts de pro­gram­ma­tion. De cette manière, les dé­ve­lop­peurs peuvent se con­cen­trer en priorité sur l’im­plé­men­ta­tion des méthodes. En cas de besoin, les pro­gram­meurs et dé­ve­lop­peurs de systèmes profitent du libre accès au code source et peuvent procéder eux-mêmes à des ajus­te­ments.

Les Protocol Buffers et les com­pi­la­teurs Protobuf cor­res­pon­dants per­met­tent par ailleurs une com­mu­ni­ca­tion sans limite : les divers systèmes d’ex­ploi­ta­tion, les com­po­sants variés des ar­chi­tec­tures client/serveur et les dif­fé­rents langages de pro­gram­ma­tion ne font plus obstacle à la com­mu­ni­ca­tion. Ainsi, un logiciel écrit en C peut com­mu­ni­quer avec le logiciel Java. Des com­pi­la­teurs Protobuf sont désormais dis­po­nibles pour de nombreux autres langages, par exemple pour C#, C++, Go, Objective-C, Java, Python, Node.js, Android Java, Swift, Ruby et PHP.

La flexi­bi­lité de gRPC présente également un gros avantage : il peut par exemple être utilisé de la même manière pour l’échange de données de mi­cro­ser­vices ou le partage de données d’ap­pli­ca­tions mobiles avec des serveurs. Autre point positif : le protocole permet l’im­plé­men­ta­tion de tech­no­lo­gies de sécurité modernes. Le gRPC dispose ainsi d’une fonction d’au­then­ti­fi­ca­tion intégrée et promeut l’uti­li­sa­tion de SSL/TLS pour l’au­then­ti­fi­ca­tion et le cryptage des échanges.

Parmi les points faibles de gRPC, on peut noter que : le test des in­ter­faces gRPC doit faire l’objet d’amé­lio­ra­tions sur la base de l’état actuel de dé­ve­lop­pe­ment. Les messages gRPC codés avec protobuf ne peuvent pas être lus par des humains. Lors de l’analyse du trafic de données et, notamment, lors de la recherche d’erreurs et des opé­ra­tions de dépannage (débogage), des instances sup­plé­men­taires doivent donc être utilisées pour re­trans­crire le code sous une forme com­pré­hen­sible et pour localiser les sources d’erreurs. D’autres in­con­vé­nients résultent de la mise en réseau d’ar­chi­tec­tures client/serveur dis­tri­buées. Le gRPC connecte des or­di­na­teurs à distance et est donc plus vul­né­rable que des systèmes locaux. Il dépend de l’accès à un réseau stable et per­for­mant. Les réseaux, le trafic de données, les pro­to­coles de trans­mis­sion ainsi que le client et le serveur ne doivent présenter aucun point d’attaque sus­cep­tible d’in­té­res­ser les pirates in­for­ma­tiques. Un autre in­con­vé­nient est que le gRPC ne prend pas en charge la mul­ti­dif­fu­sion.

De par ses nom­breuses pro­prié­tés positives, le gRPC s’impose comme une solution al­ter­na­tive con­cur­ren­tielle au REST (Re­pre­sen­ta­tio­nal State Transfer). Ce dernier est par­ti­cu­liè­re­ment adapté à l’exécution de services simples, tandis que le gRPC déploie au mieux ses capacités au sein d’in­ter­faces (API) et de services plus complexes. REST utilise gé­né­ra­le­ment le format de données JSON, pour l’échange de données entre les ap­pli­ca­tions. Il opère en mode texte et exploite ainsi les res­sources du réseau.

Le gRPC, à l’inverse, peut organiser un flux de données sen­si­ble­ment plus compact grâce aux Protocol Buffers et HTTP/2. De cette manière, les besoins en mémoire par sé­ria­li­sa­tion et bi­na­ri­sa­tion des données sont réduits de près de 70 % par rapport à JSON. Le streaming bi­di­rec­tion­nel assure également, par rapport à REST, le fonc­tion­ne­ment sans blocage de l’échange de données pour des per­for­mances et une vitesse d’exécution gran­de­ment amé­lio­rées.

À l’heure actuelle, la col­la­bo­ra­tion avec des ap­pli­ca­tions web gagnerait à être améliorée, car ces dernières ne sont souvent pas op­ti­mi­sées pour l’uti­li­sa­tion de Protocol Buffers, l’approche « le contrat d’abord » typique de gRPC, ainsi que les Contract First API du framework gRPC. Un in­con­vé­nient du travail avec des ap­pli­ca­tions web est qu’aucun service gRPC n’est encore ac­ces­sible di­rec­te­ment depuis un na­vi­ga­teur. Ce n’est pas un problème avec REST, puisque le protocole HTTP classique est pris en charge par tous les na­vi­ga­teurs, con­trai­re­ment au protocole HTTP/2 plus moderne. Toutefois, cette lacune peut être surmontée au prix d’un effort rai­son­nable, de sorte que le même service peut être utilisé pour une ap­pli­ca­tion Web et une ap­pli­ca­tion mobile. Une option dans ce domaine est le gRPC web. Les dé­ve­lop­peurs du gRPC tra­vail­lent sur d’autres solutions pour faciliter au maximum la com­pa­ti­bi­lité du gRPC avec les outils basés sur le web.

Le gRPC est plus par­ti­cu­liè­re­ment utilisé pour assurer une com­mu­ni­ca­tion inter-processus efficace au sein d’ar­chi­tec­tures client-serveur dis­tri­buées, exigeant une faible latence et un débit de trans­mis­sion élevé de données et de messages. Entre et au sein des centres de données distants, le gRPC est souvent utilisé pour in­ter­con­nec­ter des services ou des mi­cro­ser­vices. Comme les outils du gRPC prennent en charge la plupart des langages de dé­ve­lop­pe­ment courants, ils sont souvent utilisés dans des en­vi­ron­ne­ments mul­ti­lingues.

La vitesse, l’ef­fi­ca­cité et le mul­ti­lin­guisme fa­vo­ri­sent l’uti­li­sa­tion du gRPC avec les outils mobiles et pour la com­mu­ni­ca­tion entre ap­pli­ca­tions. Le gRPC régule en outre la dernière phase du trai­te­ment des données dis­tri­buées en con­nec­tant les appareils, les ap­pli­ca­tions mobiles et les na­vi­ga­teurs avec les services backend.

Per­for­mant, le streaming via HTTP/2 pré­des­tine le gRPC à la com­mu­ni­ca­tion point à point en temps réel. L’internet des objets (tech­no­lo­gies de maison in­tel­li­gente) bénéficie de procédés sobres en res­sources, car il se concentre de plus en plus sur la com­mu­ni­ca­tion de clients à faibles res­sources. De par ses nombreux avantages en matière de per­for­mance et sa sim­pli­cité de dé­ve­lop­pe­ment, cette tech­no­lo­gie de com­mu­ni­ca­tion pourrait devenir le leader de la com­mu­ni­ca­tion en nuage. Cela re­la­ti­vi­se­rait la do­mi­na­tion actuelle de REST. Ac­tuel­le­ment, le gRPC est également utilisé comme solution al­ter­na­tive au XML (Ex­ten­sible Markup Language).