La plupart des composants de communication inter-systèmes qui utilisent REST sérialisent leur charge utile en JSON. À l’heure actuelle, JSON ne dispose pas d’une norme de validation de schéma largement utilisée : JSON Schema n’est pas répandu. La validation de schéma standard permet de déléguer la validation à une bibliothèque tierce et d’en finir avec elle. Sans celui-ci, il faut se rabattre sur la validation manuelle dans le code. Pire, nous devons garder le code de validation synchronisé avec le schéma.
XML a une validation de schéma prête à l’emploi : un document XML peut déclarer une grammaire à laquelle il doit se conformer. SOAP, étant basé sur XML, en bénéficie également.
D’autres alternatives de sérialisation ont une option de validation de schéma : par exemple, Avro, Kryo et Protocol Buffers. Chose intéressante, gRPC utilise Protobuf pour offrir RPC sur des composants distribués :
gRPC est un cadre d’appel de procédure à distance (RPC) open source hautes performances moderne qui peut s’exécuter dans n’importe quel environnement. Il peut connecter efficacement les services dans et entre les centres de données avec une prise en charge enfichable pour l’équilibrage de charge, le traçage, la vérification de l’état et l’authentification. Il est également applicable dans le dernier kilomètre de l’informatique distribuée pour connecter les appareils, les applications mobiles et les navigateurs aux services backend.
– Pourquoi gRPC ?
De plus, le protocole est un binaire mécanisme de sérialisation, économisant beaucoup de bande passante. Ainsi, gRPC est une excellente option pour la communication inter-système. Mais si tous vos composants parlent gRPC, comment de simples clients peuvent-ils les appeler ? Dans cet article, nous allons créer un service gRPC et montrer comment l’appeler depuis cURL.
Un service gRPC simple
La documentation gRPC est exhaustive, voici donc un résumé :
- gRPC est une infrastructure d’appel de procédure à distance.
- Il fonctionne dans un large éventail de langues.
- Il s’appuie sur Protocol Buffers :
Les tampons de protocole sont le mécanisme extensible indépendant de la langue et de la plate-forme de Google pour la sérialisation des données structurées – pensez XML, mais plus petit, plus rapide et plus simple. Vous définissez comment vous souhaitez que vos données soient structurées une fois, puis vous pouvez utiliser un code source spécial généré pour écrire et lire facilement vos données structurées vers et depuis une variété de flux de données et en utilisant une variété de langages.
- Il fait partie du portefeuille de la CNCF et est actuellement en phase d’incubation.
Configurons notre service gRPC. Nous utiliserons Java, Kotlin, Spring Boot et un projet d’intégration gRPC Spring Boot dédié. La structure du projet contient deux projets : un pour le modèle et un pour le code. Commençons par le projet modèle.
Je ne voulais pas quelque chose de compliqué. Réutiliser un exemple simple suffit : la requête envoie une chaîne, et la réponse la préfixe avec Hello. Nous concevons ce modèle dans un fichier de schéma Protobuf dédié :
syntax = "proto3"; //1
package ch.frankel.blog.grpc.model; //2
option java_multiple_files = true; //3
option java_package = "ch.frankel.blog.grpc.model"; //3
option java_outer_classname = "HelloProtos"; //3
service HelloService { //4
rpc SayHello (HelloRequest) returns (HelloResponse) {
}
}
message HelloRequest { //5
string name = 1; //6
}
message HelloResponse { //7
string message = 1; //6
}- Version de la définition de Protobuf
- Emballer
- Configuration spécifique à Java
- Définition des services
- Définition de la demande
- Définition du champ : D’abord vient le type, puis le nom, et enfin, l’ordre.
- Définition de la réponse
Nous utiliserons Maven pour générer le code standard Java :
<project>
<dependencies>
<dependency>
<groupId>io.grpc</groupId> <!--1-->
<artifactId>grpc-stub</artifactId>
<version>${grpc.version}</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId> <!--1-->
<artifactId>grpc-protobuf</artifactId>
<version>${grpc.version}</version>
</dependency>
<dependency>
<groupId>jakarta.annotation</groupId> <!--1-->
<artifactId>jakarta.annotation-api</artifactId>
<version>1.3.5</version>
<optional>true</optional>
</dependency>
</dependencies>
<build>
<extensions>
<extension>
<groupId>kr.motd.maven</groupId> <!--2-->
<artifactId>os-maven-plugin</artifactId>
<version>1.7.1</version>
</extension>
</extensions>
<plugins>
<plugin>
<groupId>org.xolstice.maven.plugins</groupId> <!--3-->
<artifactId>protobuf-maven-plugin</artifactId>
<version>${protobuf-plugin.version}</version>
<configuration>
<protocArtifact>com.google.protobuf:protoc:${protobuf.version}:exe:${os.detected.classifier}</protocArtifact>
<pluginId>grpc-java</pluginId>
<pluginArtifact>io.grpc:protoc-gen-grpc-java:${grpc.version}:exe:${os.detected.classifier}</pluginArtifact>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>compile-custom</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>- Dépendances au moment de la compilation
- Renifler des informations sur le système d’exploitation ; utilisé dans le plugin suivant
- Générer du code Java à partir du
protodéposer.
Après compilation, la structure devrait ressembler à ceci :
Nous pouvons empaqueter les classes dans un JAR et l’utiliser dans un projet d’application Web. Ce dernier est en Kotlin, mais uniquement parce que c’est mon langage JVM préféré.
Nous n’avons besoin que d’une dépendance de démarrage Spring Boot spécifique pour intégrer les points de terminaison gRPC à Spring Boot :
<dependency>
<groupId>net.devh</groupId>
<artifactId>grpc-server-spring-boot-starter</artifactId>
<version>2.14.0.RELEASE</version>
</dependency>Voici le bit significatif:
@GrpcService //1
class HelloService : HelloServiceImplBase() { //2
override fun sayHello(
request: HelloRequest, //2
observer: StreamObserver<HelloResponse> //3
) {
with(observer) {
val reply = HelloResponse.newBuilder() //2
.setMessage("Hello ${request.name}") //4
.build()
onNext(reply) //5
onCompleted() //5
}
}
}- Le
grpc-server-spring-boot-starterdétecte l’annotation et opère sa magie. - Classes de référence générées dans le projet ci-dessus
- La signature de la méthode permet une
StreamObserverparamètre. La classe vient degrpc-stub.jar. - Obtenez la requête et préfixez-la pour créer le message de réponse.
- Jouez les événements.
Nous pouvons maintenant démarrer l’application Web avec ./mvnw spring-boot:run.
Tester le service gRPC
L’idée derrière la publication est qu’il est impossible d’accéder au service gRPC avec des outils réguliers. Pour tester, il nous faut tout de même un outil dédié. J’ai trouvé grpcurl. Installons-le et utilisons-le pour répertorier les services disponibles :
grpcurl --plaintext localhost:9090 list #1-2- Répertorier tous les services gRPC disponibles sans Vérification TLS.
- Pour éviter les conflits entre gRPC et d’autres canaux, par exemple REST, Spring Boot utilise un autre port.
ch.frankel.blog.grpc.model.HelloService #1
grpc.health.v1.Health #2
grpc.reflection.v1alpha.ServerReflection #2- Le service gRPC que nous avons défini
- Deux services supplémentaires fournis par le démarreur personnalisé
Nous pouvons également plonger dans la structure du service :
grpcurl --plaintext localhost:9090 describe ch.frankel.blog.grpc.model.HelloServiceservice HelloService {
rpc SayHello ( .ch.frankel.blog.grpc.model.HelloRequest ) returns ( .ch.frankel.blog.grpc.model.HelloResponse );
}Enfin, nous pouvons appeler le service avec des données :
grpcurl --plaintext -d '{"name": "John"}' localhost:9090 ch.frankel.blog.grpc.model.HelloService/SayHello{
"message": "Hello John"
}Accéder au service gRPC avec des outils réguliers
Imaginons que nous ayons une application côté client JavaScript standard qui doit accéder au service gRPC. Quelles seraient les alternatives ?
L’approche générale passe par grpc-web:
Une implémentation JavaScript de gRPC pour les clients de navigateur. Pour plus d’informations, y compris un démarrage rapide, consultez la documentation gRPC-web.
Les clients gRPC-web se connectent aux services gRPC via un proxy spécial ; par défaut, gRPC-web utilise Envoy.
À l’avenir, nous nous attendons à ce que gRPC-web soit pris en charge dans des frameworks Web spécifiques à un langage pour des langages tels que Python, Java et Node. Pour plus de détails, consultez la feuille de route.
– grpc-web
La description indique une seule limitation : cela ne fonctionne que pour JavaScript (pour l’instant). Cependant, il y en a un autre. C’est assez intrusif. Vous devez obtenir le proto fichier, générer du code passe-partout et faire en sorte que votre code l’appelle. Vous devez le faire pour chaque type de client. Pire, si le fichier proto change, vous devez régénérer le code client dans chacun d’eux.
Une alternative existe cependant si vous utilisez une API Gateway. Je décrirai comment le faire avec Apache APISIX, mais peut-être que d’autres passerelles peuvent faire de même. grpc-transcode est un plugin qui permet de transcoder les appels REST vers gRPC et inversement.
La première étape consiste à enregistrer le fichier proto dans Apache APISIX :
curl http://localhost:9180/apisix/admin/protos/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d "{ \"content\": \"$(sed 's/"/\\"/g' ../model/src/main/proto/model.proto)\" }"La deuxième étape consiste à créer une route avec le plugin ci-dessus :
curl http://localhost:9180/apisix/admin/routes/1 -H 'X-API-KEY:...