sangheee
commented
2 years ago Introduction to gRPC
- inter-process communication에는 1.synchronous request-response style의 message passing과 2.asynchronous event-driven style이 있다.
- 현대의 cloud native application 또는 MSA에 1.synchronous style을 적용할 경우, HTTP protocol을 통해 발생하는 network call로 accessable and changeable resources collection으로 application이나 service를 모델링할 수 있다.
- cons of RESTful service: quite bulky, inefficient, and error-prone for building inter-process communication.
- gRPC는 RESTful보다 highly scalable, loosely coupled
- gRPC는 synchronous request-response style 뿐만 아니라 asynchronous or streaming mode 도 가능
What is gRPC
> gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. (https://grpc.io/) - gRPC는 분산된 heterogeneous applications를 마치 local function call로 connect, invoke, operate, and debug할 수 있게 하는 inter-process communication technology이다. - gRPC application 개발 첫 단계는 **service interface**를 정의하는 것이다. - service interface definition: how your service can be consumed by consumers, what methods you allow the consumers to call remotely, what method parameters and message formats to use when invoking those methods, and so on. - _interface definition language_(IDL) 를 사용하여 서비스 정의 - server definition을 사용해 `server-skeleton`과 `client-stub`을 만들 수 있다. - client-stub은 서로 다른 프로그래밍 언어에 대한 low-level communication을 감추고 추상화한다. - service interface definition에서 지정한 methodsms client side에서 local function 호출만큼 쉽게 원경 호출 가능하다. ### use case of microservice implemented with gRPC
- `ProtuctInfo.proto` file에 service definition을 지정하며, 이는 server와 client의 코드를 생성하는데 사용된다.
- input parameter, return type을 지정하여 _service에 노출되는 method를_ service interface definition에 정의
#### Service Definition
- gRPC는 service interfae를 정의하기 위한 IDL로 [protocol buffers](https://developers.google.com/protocol-buffers)를 사용한다.
- 프로토콜 버퍼는 언어에 구애받지 않고, 플랫폼 중립적이며, 확장 가능한 structued data serialization 메커니즘이다.
- service interface definition은 `.proto` 확장자를 가진 일반 텍스트 파일에 지정된다.
- procol buffer를 사용한 service definition 정의에는 *remote method, input/output parameters, parameter들의 type(or message format) 지정*이 포함된다.
```protobuf
// ProductInfo.proto
syntax = "proto3"; // protocol buffer version that we use
package ecommerce; // package name to prevent name clashes between protocol message types and to genereate code
service ProductInfo { // defining the service interface of a gRPC service
rpc addProduct(Product) returns (ProductID); // remote method to add a product that returns the product ID as the response
rpc getProduct(ProductID) returns (Product);
}
message Product { // definition of the message format/type of Product
string id = 1;
string name = 2;
string description = 3;
}
message ProductID {
string value = 1;
}
```
- package에 version을 함께 지정할 수 있어 major change가 있으면 이를 인지하게 할 수 있음
- field holds unique field numbers that are used to identify your fields in the message binary format
- service는 원격 호출 가능한 methods의 collection
- service definition을 정의했으면 protocol buffer compiler **`protoc`**를 사용해 server-/client-side code + regular protocol buffer code(populating, serializing, retrieving your message type)를 생성할 수 있다
#### gRPC Server
- gRPC server는 client call을 처리하기 위해 gRPC server를 실행
1. service definition으로 생성된 service base class service skeleton을 override하여 **service logic 구현**
2. run a gRPC server to listen for requests from clients and return the service responses
```golang
// gRPC server-side implementation of ProductInfo service with Go
import ( ...
"context"
pb "github.com/grpc-up-and-running/samples/ch02/productinfo/go/proto"
"google.golang.org/grpc"
...
)
// ProductInfo implementation with Go
// Add product remote method
func (s *server) AddProduct(ctx context.Context, in *pb.Product) ( *pb.ProductID, error) {
// business logic !!!!여기에 service logic!!!!!
}
// Get product remote method
func (s *server) GetProduct(ctx context.Context, in *pb.ProductID) ( *pb.Product, error) {
// business logic !!!!여기에 service logic!!!!!
}
```
```golang
// run a gRPC server
func main() {
lis, _ := net.Listen("tcp", port)
s := grpc.NewServer() pb.RegisterProductInfoServer(s, &server{})
if err := s.Serve(lis); err != nil { log.Fatalf("failed to serve: %v", err)
}
}
```
#### gRPC Client
- server definition으로 생성되는 client-stub은 server와 동일한 method를 제공한다.
- client stub은 이를 sever side로 가는 network call을 호출하는 remote function으로 변환한다.
- gRPC service definition이 언어 종속적이지 않으므로 지원하는 모든 종류의 client/server를 생성할 수 있다.
```java
// Create a channel using remote server address
ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 8080)
.usePlaintext(true)
.build();
// Initialize blocking stub using the channel
ProductInfoGrpc.ProductInfoBlockingStub stub =
ProductInfoGrpc.newBlockingStub(channel);
// Call remote method using the blocking stub
StringValue productID = stub.addProduct(
Product.newBuilder()
.setName("Apple iPhone 11")
.setDescription("Meet Apple iPhone 11." +
"All-new dual-camera system with " +
"Ultra Wide and Night mode.")
.build());
```
- the simple steps involved in a client-side implementation **involve setting up a connection with the remote server, attaching the client stub with that connection, and invoking the remote method using the client stub.**
#### Client–Server Message Flow
- on the client side
- gRPC client가 gRPC service를 호출하면, client-side gRPC library는 HTTP/2를 통해 전송되는 remote procedure call protocol buffer format을 marshaling
- on the server side
- request unmarshaling, 각 procedure call은 protocol buffer를 사용하여 실행된다.
Evolution of Inter-Process Communication
- Conventional RPC
- SOAP(Simple Object Access Protocol)
- REST
- key limitations of RESTful services that hinder the ability to use them for modern microservices-based applications
- Inefficient text-based message protocols
- text-based 프로토콜을 기반으로 구축돼 JSON같은 사람이 읽을 수 있는 textual format을 활용하는데, service-to-service communication에서는 human-readable textual format이 불필요하고 비효율적이다.
- lack of well-defined and strongly typed service definitions
- 이로 인해 비호환성(incompatibilities), 런타임 오류 및 상호 운용성(interperability) 문제가 발생
- 또한 REST는 protocol에 포함되지 않기 때문에 구현단계에 적용하기가 까다로워 실제 RESTful이라고 하는 것들은 그저 netwrok로 노출되는 HTTP 서비스에 불과하다.
Why gRPC
advantages of gRPC
- protocolbuffer-based binary protocol 사용
- service definition을 먼저 정의하고 그 다음 세부 구현을하기 때문에 gRPC offers a simple but consistent, reliable, and scalable application development experience.
- It’s polyglot
disadvantages of gRPC
- external-facing services에는 부적합할지도?
- gRPC의 contract-driven, strongly typed 특성은 flexibility를 저해할 수 있으며, consumer 권한이 더 적다. (gRPC gateway가 이 문제를 극복하기 위해 설계됨)
- schema modification이 복잡
- service definition에 급격한 변화가 생기면 server와 client의 code를 재생성해야함
- 그러나 대부분 gRPC service definition 변경은 breaking change가 아니면 version간 상위/하위 호환된다.
alexgituser
gRPC: Up and Running (Building Cloud Native Applications with Go and Java for Docker and Kubernetes) cloud native와 MSA의 등장으로 application간의 inter-process communication technologies를 사용한 network 연결이 필요
읽을 거리: