오랫동안 저는 RPC(즉, 원격 프로시저 호출)와 HTTP 호출의 차이를 파악하지 못했습니다. 여기서 웃게 해줘~순진해! 이 글에서는 C/S 아키텍처의 두 형태를 간략히 소개합니다. 우선 가장 본질적인 차이점, 즉 RPC는 주로 TCP/IP 프로토콜에 기반하고, HTTP 서비스는 주로 HTTP 프로토콜에 기반합니다. 우리는 모두 HTTP 프로토콜이 전송 계층 프로토콜 TCP 위에 있다는 것을 알고 있으니, 효율성 면에서는 RPC가 당연히 더 낫습니다! RPC 서비스와 HTTP 서비스에 대해 자세히 이야기해 보겠습니다.
OSI 네트워크 7계층 모델
RPC와 HTTP의 차이를 이야기하기 전에, OSI의 7계층 네트워크 구조 모델(실제로는 기본적으로 5계층)을 이해하는 것이 필요하다고 생각합니다. 이 모델은 다음 계층으로 나눌 수 있습니다: (위에서 아래까지)
- 첫 번째 계층: 애플리케이션 레이어입니다. 네트워크 내 통신 및 데이터 전송을 위한 인터페이스가 정의됩니다;
- 두 번째 층: 표현 계층. 전송 형식, 서로 다른 시스템에서 데이터의 인코딩 및 디코딩 명세 등을 정의합니다;
- 세 번째 층: 대화 층. 사용자 세션을 관리하고 사용자 간 논리 연결 설정 및 중단을 제어합니다.
- 네 번째 층: 수송 층. 네트워크 내 종단 간 데이터 전송을 관리하며;
- 레이어 5: 네트워크 계층. 네트워크 장치 간 데이터 전송 방식을 정의하세요;
- 여섯 번째 계층: 링크 계층. 위 네트워크 계층의 데이터 패킷은 물리적 계층 전송을 용이하게 하기 위해 데이터 프레임으로 캡슐화됩니다.
- 레이어 7: 물리 계층. 이 계층은 주로 이 이진 데이터를 전송하는 데 중점을 둡니다.
실용적으로는 5계층 프로토콜 구조에 프레젠테이션 계층과 세션 계층이 없습니다. 참고로 이들은 애플리케이션 계층과 병합됩니다. 애플리케이션 계층과 전송 계층에 집중해야 합니다. HTTP는 애플리케이션 계층 프로토콜이고, TCP는 전송 계층 프로토콜이기 때문입니다. 이제 네트워크 계층화 모델을 알게 되었으니, 왜 RPC 서비스가 HTTP 서비스보다 더 좋은지 더 잘 이해할 수 있게 되었습니다!
RPC 서비스
RPC 서비스는 세 가지 관점에서 소개됩니다: RPC 아키텍처, 동기식 비동기 호출, 그리고 인기 있는 RPC 프레임워크.
RPC 아키텍처
RPC 서비스의 기본 아키텍처에 대해 이야기해 봅시다. 부끄럽게도 그림을 훔쳐 드리겠습니다~ 완전한 RPC 아키텍처는 클라이언트, 서버, 클라이언트 스텁, 그리고 스텁으로 이해할 수 있는 서버 스텁이라는 네 가지 핵심 구성 요소를 분명히 포함하고 있습니다. 이 구성 요소들에 대해 따로 이야기해 봅시다:
- 고객, 즉 서비스를 호출하는 사람.
- 서버, 진짜 서비스 제공자.
- 클라이언트 스텁은 서버의 주소 메시지를 저장한 후, 클라이언트의 요청 매개변수를 네트워크 메시지로 포장한 후 네트워크를 통해 원격으로 서비스 당사자에게 전송합니다.
- 서버 측 스텁은 클라이언트가 보낸 메시지를 수신하고, 이를 압축 해제하며, 로컬 메서드를 호출합니다.
RPC는 대기업이 많은 시스템, 복잡한 사업 라인, 효율성 이점이 매우 중요하기 때문에 주로 대기업에서 사용됩니다. 이것은 실제 개발 단계에서 이루어지며, 프로젝트는 일반적으로 Maven을 사용해 관리됩니다. 예를 들어, 주문을 처리한 시스템 서비스가 있는데, 먼저 모든 인터페이스(특히 Java의 인터페이스)를 선언한 후 전체 프로젝트를 jar 패키지로 묶습니다. 왜 이런 짓을 하는 걸까요? 주요 목적은 클라이언트 측에서 jar 패키지의 크기를 줄이는 것입니다. 패키지가 출시될 때마다 너무 많은 jar 패키지가 항상 효율성에 영향을 미치기 때문입니다. 또한 클라이언트와 서버를 분리하여 코드 이식성을 향상시킵니다.
동기 및 비동기 호출
동기 통화란 무엇인가요? 비동기식 통화란 무엇인가요? 동기 호출은 클라이언트가 호출이 실행될 때까지 기다렸다가 결과를 반환하는 경우입니다. 비동기 호출은 클라이언트가 호출이 실행되고 결과를 반환하기를 기다리지 않고, 콜백 기능을 통해 반환 결과 알림을 받을 수 있음을 의미합니다. 고객이 결과에 신경 쓰지 않으면 일방적인 통화로 변할 수 있습니다. 이 과정은 Java의 호출 가능한 인터페이스와 유사한 점입니다. 비동기 실행을 할 때 실행 결과를 알아야 할 때는 호출 가능한 인터페이스를 사용할 수 있고, Future 클래스를 통해 비동기 실행 결과 정보를 얻을 수 있습니다. 실행 결과에 신경 쓰지 않는다면, 결과를 반환하지 않는 런 가능한 인터페이스를 사용하면 됩니다. 물론 콜러블도 가능하며, 미래를 얻을 필요는 없습니다.
인기 있는 RPC 프레임워크
여전히 많은 인기 있는 오픈 소스 RPC 프레임워크가 존재합니다. 다음은 세 가지 주요 인상입니다:
- gRPC는 구글이 최근 발표한 오픈 소스 소프트웨어로, 최신 HTTP 2.0 프로토콜을 기반으로 하며, 많은 일반적인 프로그래밍 언어를 지원합니다. HTTP 2.0은 바이너리 기반 HTTP 프로토콜의 업그레이드 버전이며, 주요 브라우저들이 현재 빠르게 이를 지원하고 있다는 것을 알고 있습니다. 이 RPC 프레임워크는 HTTP 프로토콜을 기반으로 하며, 그 기반은 Netty 프레임워크의 지원을 사용합니다.
- Thrift는 페이스북을 위한 오픈소스 프로젝트로, 주로 다국어 서비스 개발 프레임워크입니다. 정의한 IDL 정의 파일에 대해 서비스 코드 프레임워크를 자동으로 생성하는 코드 생성기가 있습니다. 사용자는 2차 개발만 수행하면 되며, 기본 RPC 통신은 투명합니다. 하지만 사용자에게는 특정 분야의 언어를 배우는 데 일정한 비용이 따릅니다.
- 더보는 알리바바 그룹에서 제공하는 잘 알려진 RPC 프레임워크 오픈 소스로, 많은 인터넷 기업과 기업용 애플리케이션에서 널리 사용되고 있습니다. 프로토콜과 직렬화 프레임워크 모두 플러그인이 가능합니다. 동일한 원격 인터페이스는 Java 인터페이스를 기반으로 하며, 개발이 용이하도록 스프링 프레임워크에 의존합니다. 단일 파일로 쉽게 패키징되어 독립적으로 실행할 수 있는데, 이는 현재 마이크로서비스 개념과 일치합니다.
몰래 이 그룹이 더 이상 더보를 많이 사용하지 않는다고 말해줄 수도 있죠,현재 더 널리 사용되는 것은 HSF라고 불립니다"너무 편안하다"로도 알려져 있습니다. 나중에 오픈 소스가 나올 수도 있으니 지켜보자.
HTTP 서비스
사실, 오래전부터 저는 기업 개발 모델을 HTTP 인터페이스 개발, 즉 흔히 RESTful(전형) 스타일의 서비스 인터페이스라고 부르는 것으로 특징지었습니다. 실제로 인터페이스가 적고 시스템 간 상호작용이 적은 정보 섬 문제를 해결하는 초기 단계에서 자주 사용되는 통신 방법입니다; 장점은 간단하고 직접적이며 개발하기 쉽습니다. 전송을 위해 이미 준비된 HTTP 프로토콜을 활용하세요. 우리가 회사에서 백그라운드 개발을 할 때는 주로 인터페이스를 개발했고, 입력과 출력이 무엇인지 엄격히 명시하는 큰 인터페이스 문서를 작성해야 했던 기억이 납니다. 각 인터페이스의 요청 방식과 요청 매개변수에서 주의해야 할 사항을 설명하세요. 예를 들어, 다음 예시를 들 수 있습니다:
올리기http://www.httpexample.com/restful/buyer/info/share
인터페이스는 JSON 문자열이나 XML 문서를 반환할 수 있습니다. 클라이언트는 이 반환된 정보를 처리하여 더 빠른 개발을 가능하게 합니다. 하지만 대기업에서는 내부 하위 시스템과 인터페이스가 많을 때 RPC 프레임워크의 장점이 드러납니다. 우선 긴 링크이며, http처럼 매번 3번 악수할 필요가 없어 네트워크 오버헤드가 줄어듭니다; 둘째, RPC 프레임워크는 일반적으로 등록 센터와 풍부한 모니터링 및 관리를 갖추고 있습니다; 게시, 오프라인 인터페이스, 동적 확장 등은 호출자에게 인지되지 않고 통합된 작업입니다.
요약
일반적으로 RPC 서비스는 주로 대기업을 위한 것이고, HTTP 서비스는 소규모 기업을 위한 것인데, 이는 RPC가 더 효율적이고 HTTP 서비스 개발 반복이 더 빠르기 때문입니다. 요컨대, 어떤 프레임워크를 선택할지는 시장에서 인기 있는 것에 의해 결정되는 것이 아니라, 전체 프로젝트를 완전히 평가하여 두 개발 프레임워크가 전체 프로젝트에 미치는 영향을 신중히 비교한 후, 최종적으로 프로젝트에 가장 적합한 것을 결정하는 것입니다. 우리는 RPC를 사용하기 위해 모든 프로젝트에 RPC를 사용하는 것이 아니라, 지역 상황에 맞게 적응하고 구체적인 상황을 분석해야 합니다.
|
게시됨 2019. 4. 1. 오후 2:02:45
|
|
|
|
