비 gRPC 개발자의 gRPC 프라이머

요즘 gRPC에 대해 계속 듣습니다. 기존 추세가 치솟는 것인지 우연의 일치인지 확실하지 않습니다. 어쨋든 컨셉까지 파헤쳐본적이 없어서 지금이 딱 ​​좋을때라고 생각했습니다.

gRPC의 상위 수준 보기

gRPC는 Google에서 만든 RPC 프레임워크입니다. 흥미롭게도 초기 "g"는 "google"이 아니라 "general(목적)"을 의미합니다.

따라서 gRPC는 RPC 스타일의 통신이 필요한 모든 상황에서 사용할 수 있는 RPC 프레임워크입니다.

일반적으로 우리는 서비스 간의 통신에 대해 이야기하고 있습니다.

gRPC는 서비스 인터페이스 정의, 통신 형식, 인증, 상태 확인 등과 같이 서비스 간 통신에 필요한 모든 지루한 작업을 처리합니다.

하지만 그러기 위해서는 먼저 선행 작업을 수행해야 합니다.

잠깐만요...RPC가 뭔데

이전 단락에서 알 수 없는 용어를 접하셨을 수도 있다는 점을 이해합니다.

따라서 RPC는 서비스 간 호출을 수행하는 기술(및 RESTful API가 인계받기 전에 매우 널리 사용됨)입니다.

이 경우 서비스 A는 서비스 B를 호출하지만 코드 판독기 관점에서 이것은 동일한 시스템에 있는 것처럼 보입니다.

모든 고품질 추상화와 마찬가지로 RPC는 네트워크 통신을 수행하는 데 필요한 낮은 수준의 세부 정보를 숨기는 데 큰 역할을 합니다.

RPC에는 REST와 다른 규칙 및 의미 체계도 있습니다. 예를 들어 RPC에서는 다음과 같은 호출을 볼 수 있습니다.

POST /addNewProduct

몸으로

{"company_id": 2}

REST에서는 다음과 같은 작업을 수행합니다.

POST /products

같은 몸으로.

아래는 RPC 클라이언트-서버 통신을 보여주는 geekstogeeks에서 빌려온 멋진 다이어그램입니다.

프로토콜 버퍼

프로토콜 버퍼는 gRPC 프레임워크에서 가장 많이 사용되는 엔터티입니다. 그들은 gRPC를 활용하기 위해 "우리가 해야 할 선행 작업"의 일부입니다.

그들이 하는 일은 통신의 양쪽 끝에서 데이터를 직렬화 및 역직렬화하는 것입니다. 다음과 같은 구조체와 유사한 형식으로 선언할 수 있습니다.

message Point {
  int32 x = 1;
  int32 y = 2;
}

쉽죠?

가장 좋은 점은 프로토콜 버퍼가 바이너리로 직렬화된다는 것입니다. 이는 (다른 이점 중에서도) 더 작은 크기(JSON과 같은 텍스트 형식과 비교)와 더 빠른 전송을 의미합니다.

지원되는 언어

gRPC는 공식적으로 대부분의 주요 프로그래밍 언어를 지원합니다. 이 문서를 작성하는 시점에 해당are:

C/C++
C#
Dart
Go
Java
Kotlin/JVM
Node.js
Objective-C
PHP
Python
Ruby

어디에서 시작합니까

grpc.io 외에도 무료 리소스를 찾는 데 어려움을 겪었습니다. 두 가지를 고를 수 있다면 다음과 같습니다.



몇 달러를 지불할 의사가 있다면 스테판 마렉course은 실망시키지 않을 것입니다.

결론

짧은 글 읽어주셔서 감사합니다. gRPC는 (마이크로)서비스로 작업하는 경우 권장하는 매우 흥미로운 프레임워크입니다.