[JAVA] gRPC sur Spring Boot avec grpc-spring-boot-starter

Cet article est le troisième jour du Calendrier de l'Avent BrainPad 2018.

Bonjour [@ nissy0409240] est (https://twitter.com/nissy0409240). Je suis ingénieur chez BrainPad. Cela fait moins d'un mois en 2018, Comment va tout le monde.

Bien que ce soit une affaire privée Cette année j'ai été autorisé à monter sur scène à PyCon 2018 Regarder le tour du chapeau de C.Ronaud à la Coupe du monde J'ai eu une expérience précieuse à la fois en public et en privé.

Fin 2018, lors de l'utilisation de gRPC avec Spring Boot, qui n'a rien à voir avec le contenu écrit ci-dessus, j'ai ajouté quelque chose d'extraordinaire et gRPC (car le nombre de phrases est trop petit) en premier lieu. Nous vous enverrons cette entrée.

Qu'est-ce que gRPC

Tout d'abord, parlons de ce qu'est gRPC. gRPC est un framework RPC créé par Google. Ceci seul est un état "quel désordre", donc je vais également expliquer le cadre RPC.

Le nom officiel du RPC pour le framework RPC est "Remote Procedure Call". Une fois traduit, il devient "appel de procédure à distance". Il vous permet d'appeler les méthodes décrites dans une application s'exécutant sur un autre serveur comme si elles s'exécutaient sur votre serveur.

Il est difficile d'obtenir une image avec seulement les lettres, alors jetons un coup d'œil à la figure dans le document de la famille de tête gPRC.

La figure ci-dessus montre une situation dans laquelle un client Ruby et un client Java appellent un service écrit en C ++.

Avantages de l'utilisation de gRPC

Dans gRPC, en décrivant le contenu de l'implémentation que le côté service veut fournir dans le fichier de définition appelé fichier .proto, le module de coopération nommé stub qui appelle l'implémentation du service du côté client est automatiquement généré. Par conséquent, le fichier de définition de spécification d'interface trouvé dans la liaison API est toujours reflété dans l'implémentation, vous pouvez donc profiter des avantages suivants.

--Il est possible de partager le type de données échangées entre l'appelant et l'appelé.

• Comme les tampons de protocole http2 + sont utilisés, il est possible d'améliorer les performances par liaison API. ――Il est possible de continuer avec le microservice quelle que soit la langue utilisée par l'appelant / l'appelé. --gRPC prend en charge plusieurs langages, et la plupart des principaux langages utilisés dans le développement Web sont déjà pris en charge.

Comment utiliser gRPC

Ajouter un module à pom.xml

Je voudrais vous présenter comment utiliser gRPC. Cependant, il est difficile de transmettre avec seulement les lettres, et c'est différent pour chaque langue, donc Cette fois, j'utiliserai Java 8 + Spring Boot et continuerai tout en déplaçant mes mains.

Tout d'abord, créez un modèle de produit à l'aide de Spring Initializer. Voici la composition du modèle avant sa création.

demo_protobuf

├── pom.xml
├── main
│   ├── java
│   │   └── com
│   │       └── example
│   │           └── demo_protobuf
│   │               └── DemoProtobufApplication.java
│   └── resources
│       └── application.properties
└── test
    └── java
        └── com
            └── example
                └── demo_protobuf
                    └── DemoProtobufApplicationTests.java

Ensuite, j'ai ajouté un module à pom.xml, ce qui était ridicule. Nous discuterons de l'ajout de modules plus tard, mais nous allons d'abord passer au fichier de définition.

Comment créer un fichier de définition

Créez un fichier de définition lorsque l'exécution est terminée. Cette fois, j'écrirai la définition dans le fichier src / main / proto / demo.proto. La composition du produit à ce stade est la suivante.

demo_protobuf

.
├── mvnw
├── mvnw.cmd
├── pom.xml
└── src
    ├── main
    │   ├── java
    │   │   └── com
    │   │       └── example
    │   │           └── demo_protobuf
    │   │               └── DemoProtobufApplication.java
    │   │           
    │   ├── proto
    │   │   └── demo.proto
    │   └── resources
    │       └── application.properties
    └── test
        └── java
            └── com
                └── example
                    └── demo_protobuf
                        └── DemoProtobufApplicationTests.java

Dans le demo.proto créé, écrivez comme suit.

demo.proto

syntax = "proto3";

option java_multiple_files = true;
option java_package = "com.example.fizzbuzz";
option java_outer_classname = "FizzBuzzProto";

package calc;

//Définit une combinaison de valeurs de retour et d'arguments pour un service appelé Math
service Math {
    rpc Math (MathRequest) returns (IntResponse);
}

//Définit le type et le nombre de valeurs de retour lorsque IntResponse est sélectionné
message IntResponse {
    int32 value = 1;
}

//Définit le type et le nombre d'arguments lors de la définition de MathRequest
message MathRequest {
    int32 x = 1;
    int32 y = 2;
}

Je suis sûr que certains d'entre vous l'ont épinglé, mais dans le fichier .proto "Quel service reçoit quel type de demande et quel type de valeur de retour est retourné" est écrit. Il décrit simplement le type de données que le fichier .proto échange.

Après l'écriture, exécutez mvn clean install. Après exécution, le code source sera généré comme suit. (En fait, plus de code sera généré, mais je vais l'omettre ici)

.
├── mvnw
├── mvnw.cmd
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   │   └── com
│   │   │       └── example
│   │   │           └── demo_protobuf
│   │   │               └── DemoProtobufApplication.java
│   │   ├── proto
│   │   │   └── demo.proto
│   │   └── resources
│   │       └── application.properties
│   └── test
│       └── java
│           └── com
│               └── example
│                   └── demo_protobuf
│                       └── DemoProtobufApplicationTests.java
└── target
    └── generated-sources
        ├── annotations
        └── protobuf
            ├── grpc-java
            │   └── com
            │       └── example
            │           └── fizzbuzz
            │               └── MathGrpc.java
            └── java
                └── com
                    └── example
                        └── fizzbuzz
                            ├── FizzBuzzProto.java
                            ├── IntResponse.java
                            ├── IntResponseOrBuilder.java
                            ├── MathRequest.java
                            └── MathRequestOrBuilder.java

Régénération de code

Mais ici, j'ai réalisé que j'avais fait une erreur. Même si j'ai arrêté d'essayer d'utiliser FizzBuzz au début et que j'ai changé pour Math J'ai généré du code avec FizzBuzz. Souhaitez-vous supprimer le référentiel et le recréer? Ce n'est pas vrai.

Réécrivez la démo.proto créée comme suit

demo.proto

syntax = "proto3";

option java_multiple_files = true;
option java_package = "com.example.math";
option java_outer_classname = "MathProto";

package calc;

//Définit une combinaison de valeurs de retour et d'arguments pour un service appelé Math
service Math {
    rpc Math (MathRequest) returns (IntResponse);
}

//Définit le type et le nombre de valeurs de retour lorsque IntResponse est sélectionné
message IntResponse {
    int32 value = 1;
}

//Définit le type et le nombre d'arguments lors de la définition de MathRequest
message MathRequest {
    int32 x = 1;
    int32 y = 2;
}

Exécutez mvn clean install.

.
├── mvnw
├── mvnw.cmd
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   │   └── com
│   │   │       └── example
│   │   │           └── demo_protobuf
│   │   │               └── DemoProtobufApplication.java
│   │   ├── proto
│   │   │   └── demo.proto
│   │   └── resources
│   │       └── application.properties
│   └── test
│       └── java
│           └── com
│               └── example
│                   └── demo_protobuf
│                       └── DemoProtobufApplicationTests.java
└── target
    └── generated-sources
        ├── annotations
        └── protobuf
            ├── grpc-java
            │   └── com
            │       └── example
            │           └── math
            │               └── MathGrpc.java
            └── java
                └── com
                    └── example
                        └── math
                            ├── MathProto.java
                            ├── IntResponse.java
                            ├── IntResponseOrBuilder.java
                            ├── MathRequest.java
                            └── MathRequestOrBuilder.java

Le code sous cible a été retravaillé. Vous pouvez également voir que cette méthode est bonne lorsque vous souhaitez mettre à jour demo.proto.

Tout ce que vous avez à faire est d'hériter du code généré et de créer le service et le client.

Ce que je suis resté bloqué lors de l'ajout d'un module à pom.xml

Depuis que j'ai abordé une série de flux, je voudrais vous présenter ce dans quoi je suis resté coincé ici. Pour faire simple, "Soyez prudent car le groupId du module est différent du contenu qui apparaît dans le référentiel Maven."

Qu'est-ce que le référentiel Maven en premier lieu? Comme beaucoup d'entre vous le savent peut-être, il s'agit d'un site qui doit vous dire quoi écrire lors de l'importation de middleware. Dans d'autres exemples de langage, PyPi de Python est similaire.

Et il existe de nombreux outils de démarrage, tout-en-un, qui prennent en charge le framework Spring Boot. Par exemple, utilisez Spring Boot Security Starter lors de la création d'un module d'authentification.

Jusqu'à présent, lors de l'utilisation de gRPC avec Spring Boot, il était écrit comme suit.

pom.xml

<!-- https://mvnrepository.com/artifact/org.lognet/grpc-spring-boot-starter -->
<dependency>
    <groupId>org.lognet</groupId>
    <artifactId>grpc-spring-boot-starter</artifactId>
    <version>2.3.2</version>
</dependency>

Cependant, lorsque la dernière version de ce module a été mise à jour vers la série 3, le groupId est passé de "org.lognet" à "org.github.lognet", donc non seulement la version mais aussi le groupId ont dû être modifiés. J'ai fait.

référentiel grpc-spring-boot-starter a également les mêmes informations que ci-dessus.

Par conséquent, il est nécessaire de décrire comme suit à partir de maintenant.

pomxml

<dependency>
    <groupId>io.github.lognet</groupId>
    <artifactId>grpc-spring-boot-starter</artifactId>
    <version>3.0.0</version>
</dependency>

Veuillez noter que si le groupId n'est pas corrigé, l'erreur suivante se produira au moment de mvn install.

[ERROR] Failed to execute goal on project demo_protobuf: Could not resolve dependencies for project com.example:demo_protobuf:jar:1.16.1: Failure to find org.lognet:grpc-spring-boot-starter:jar:3.0.0 in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

Conclusion

Bien que la structure soit un peu étrange, je voudrais remplacer cette entrée dans l'espoir qu'elle aidera ceux qui sont accros à la publication d'informations avec quelques entrées japonaises accompagnées d'un message d'erreur. Je suis désolé que le texte soit désorganisé, mais merci de rester avec nous jusqu'à la fin.

référence

https://qiita.com/nozaq/items/9cd9bf7ee6118779bda9 http://redj.hatenablog.com/entry/2017/10/13/084423 https://github.com/LogNet/grpc-spring-boot-starter https://kengotoda.gitbooks.io/what-is-maven/primer/maven-repository.html