집 > 기사 > Java > Java 원격 통신 기술 및 원리 분석에 대한 그래픽 소개

Java 원격 통신 기술 및 원리 분석에 대한 그래픽 소개

黄舟원래의: 2017-03-28 15:36:041276검색

분산 서비스 프레임워크에서 가장 기본적인 문제 중 하나는 원격 서비스의 통신 방법입니다. Java 분야에서는 RMI, MINA, ESB, Burlap, Hessian, SOAP, EJB, JMS 등 이들 용어는 어떤 관계가 있으며, 어떤 원칙에 기초하고 있는가? 이를 이해하는 것은 분산 서비스 프레임워크를 구현하기 위한 기본 지식이며, 고성능 요구 사항이 있는 경우 이를 이해하는 것이 필요하다. 이러한 기술의 메커니즘에 대한 깊은 이해.

1 기본 원리

네트워크 기계 간의 통신을 위해서는 먼저 컴퓨터 시스템의 네트워크 통신의 기본 원칙을 살펴봐야 합니다. 기본 수준에서 네트워크 통신이 수행해야 할 작업은 무엇입니까? 스트림 변환 한 컴퓨터에서 다른 컴퓨터로의 전송은 전송 프로토콜과 네트워크 IO를 기반으로 구현됩니다. 그중 가장 유명한 전송 프로토콜은 tcp, udp 등이며, tcp와 udp는 모두 소켓 개념을 기반으로 하며 특정 유형에 대해 확장됩니다. 전송 프로토콜 및 네트워크 IO에는 주로 bio, nio 및 aio가 포함되며, 모든 분산 애플리케이션 통신은 애플리케이션의 사용 편의성을 위해 일반적으로 일부를 제공합니다. 사용하기 쉬운 애플리케이션 계층 프로토콜에 더 가깝습니다.

2 메시지 모드

최종 분석에서 엔터프라이즈 애플리케이션 시스템은 데이터 처리이며, 여러 하위 시스템이 있는 엔터프라이즈 애플리케이션 시스템의 경우 기본 지원은 의심할 여지 없이 메시지 처리입니다. 객체와 달리 메시지는 본질적으로 데이터 구조입니다(물론 객체도 특수 메시지로 간주될 수 있습니다). 여기에는 소비자와 서비스 모두에서 식별할 수 있는 데이터가 포함되어 있습니다. 프로세스(머신) 간에 전달되는 서로 다른 위치에 저장되며 완전히 다른 여러 클라이언트에서 사용할 수 있습니다. 메시징은 플랫폼 독립성이 더 뛰어나고 동시 및 비동기 호출을 잘 지원할 수 있기 때문에 파일 전달 및 원격 프로시저 호출(RPC)보다 나은 것 같습니다.

웹 서비스와 RESTful의 경우 메시징 기술의 파생 또는 캡슐화로 볼 수 있습니다.

2.1 메시지 채널 모드

우리가 자주 사용하는 메시지 모드는 그림과 같이 메시지 채널 모드입니다.

메시지 채널은 클라이언트(소비자)와 서비스(생산자) 사이에 도입된 간접 레이어로, 둘 사이의 관계를 효과적으로 해소할 수 있습니다. 양측이 통신하는 데 필요한 메시지 형식과 메시지 처리 메커니즘 및 타이밍이 구현되는 한 소비자는 생산자를 "무지"할 수 있습니다. 실제로 이 모델은 여러 생산자와 소비자를 지원할 수 있습니다. 예를 들어, 여러 생산자가 메시지 채널에 메시지를 보내도록 할 수 있습니다. 소비자는 생산자를 모르기 때문에 어느 생산자가 메시지를 보냈는지 고려할 필요가 없습니다.

메시지 채널은 생산자와 소비자를 분리하여 생산자와 소비자를 임의로 확장할 수 있지만 채널 리소스의 위치를 알아야 하기 때문에 메시지 채널에 대한 각각의 종속성을 소개합니다. 채널에 대한 이러한 의존성을 완화하기 위해 Lookup 서비스를 도입하여 채널 리소스를 찾는 것을 고려할 수 있습니다. 예를 들어 JMS에서는 JNDI를 통해 메시지 채널 대기열을 얻을 수 있습니다. 완전한 유연성을 얻으려면 채널 관련 정보를 구성 파일에 저장할 수 있습니다. 조회 서비스는 먼저 구성 파일을 읽어 채널을 얻습니다.

메시지 채널은 일반적으로 대기열 형태로 존재합니다. 이 선입선출 데이터 구조는 의심할 여지 없이 이 메시지 처리 시나리오에 가장 적합합니다. Microsoft의 MSMQ, IBM MQ, JBoss MQ, 오픈 소스 RabbitMQ 및 Apache ActiveMQ는 모두 대기열을 통해 메시지 채널 모드를 구현합니다. 따라서 메시지 채널 모델을 사용하기로 결정한 경우, 품질 속성 관점에서 이 모델을 구현하는 다양한 제품에 대한 종합적인 분석과 트레이드오프를 수행하는 것이 더욱 필요합니다. 예를 들어 메시지 채널의 동시성 및 성능 지원, 메시지 채널이 오류 처리를 완전히 고려하는지 여부, 메시지 지속성, 재해 복구(장애 조치) 및 클러스터링에 대한 지원이 있습니다.

채널을 통해 전송되는 메시지는 중요한 비즈니스 데이터인 경우가 많기 때문에 채널이 실패 지점이나 보안 돌파 지점이 되면 시스템에 치명적인 영향을 미치게 됩니다.

여기서 jndi의 메커니즘도 언급됩니다. JNDI는 특정 구현에 따라 달라지므로 여기서는 jboss의 jndi 구현에 대해서만 설명할 수 있습니다.

향후 객체 인스턴스는 jboss jnp 서버에 바인딩되어 있으며, 원격 끝이 context.lookup() 메서드를 사용하여 원격 객체 인스턴스를 획득하고 호출을 시작할 때 jboss jndi의 구현 방법은 jnp 서버에서 객체 인스턴스를 획득하고 이를 직렬화하는 것입니다. 그런 다음 로컬로 역직렬화한 다음 로컬로 클래스를 호출합니다.

이 메커니즘을 통해 로컬에는 실제로 jboss의 객체 인스턴스에 바인딩된 클래스가 있어야 한다는 것을 알 수 있습니다. 그렇지 않으면 deserialization 중에 확실히 실패하고 원격 통신이 수행되어야 하는 작업을 수행하는 것입니다. JNDI만으로는 원격 통신이 불가능함을 알 수 있다.

그러나 JNDI는 ejb와 마찬가지로 투명한 원격 및 로컬 호출을 달성하는 데 사용할 수 있기 때문에 분산 서비스 프레임워크를 구현하는 데 있어 핵심 기술 포인트이기도 합니다. 예를 들어 데이터 소스).

2.2 게시자-구독자 모델

메시지 채널이 여러 소비자를 지원해야 하면 풀 모델과 푸시 모델이라는 두 가지 모델을 선택할 수 있습니다. 풀 모델은 메시지 소비자에 의해 시작되며, 이니셔티브는 소비자의 손에 있으며, 소비자는 자신의 상황에 따라 생산자에 대한 호출을 시작합니다. 그림과 같이:

풀 모델의 또 다른 구현은 상태가 변경될 때 생산자가 소비자에게 상태가 변경되었음을 알리는 것입니다. 그러나 알림을 받은 소비자는 전달된 소비자 개체를 호출하여 더 자세한 정보를 얻기 위해 콜백을 사용합니다.

메시지 기반 분산 시스템에서 풀 모델의 소비자는 일반적으로 Batch Job 형태로 미리 설정된 시간 간격에 따라 정기적으로 채널 상태를 듣습니다. 전달된 메시지가 발견되면 해당 메시지는 실제 프로세서(소비자로 간주될 수도 있음)로 전달되어 메시지를 처리하고 관련 서비스를 수행합니다.

모델을 추진하는 주도권이 생산자의 손에 있는 경우가 많고, 소비자는 수동적으로 생산자의 알림을 기다리므로 생산자는 소비자의 관련 정보를 알아야 합니다. 그림과 같이

푸시 모델의 경우 소비자는 생산자를 알 필요가 없습니다. 생산자가 소비자에게 알릴 때 전달되는 것은 생산자 자체가 아니라 메시지(또는 이벤트)인 경우가 많습니다. 동시에 생산자는 다양한 상황에 따라 다양한 소비자를 등록할 수도 있고, 캡슐화된 알림 로직의 다양한 상태 변화에 따라 다양한 소비자에게 알릴 수도 있습니다.

두 모델 모두 장점이 있습니다. 풀 모델의 장점은 소비자가 채널에 대한 의존도를 더욱 완화하고 백그라운드 작업을 통해 정기적으로 메시지 채널에 액세스할 수 있다는 것입니다. 단점은 Schedule 형태로 별도의 서비스 프로세스를 도입하고 실행해야 한다는 점이다. 푸시 모델의 경우 메시지 채널은 실제로 소비자 관찰의 주제로 사용됩니다. 메시지가 발견되면 소비자에게 메시지를 처리하라는 알림이 전달됩니다. 푸시 모델 또는 풀 모델에 관계없이 메시지 객체의 경우 관찰자 패턴과 유사한 메커니즘을 사용하여 생산자에 대한 소비자 구독을 구현할 수 있으므로 이 메커니즘을 게시자-구독자 패턴이라고 합니다. 그림:

일반적으로 게시자와 구독자는 변경 사항을 전파하는 데 사용되는 인프라(예: 메시지 채널)에 등록됩니다. 게시자는 채널에 메시지를 보낼 수 있도록 메시지 채널을 적극적으로 이해합니다. 메시지 채널이 메시지를 받으면 채널에 등록된 구독자를 적극적으로 호출하여 메시지 콘텐츠 소비를 완료합니다.

구독자의 경우 메시지를 처리하는 방법에는 두 가지가 있습니다. 한 가지 방법은 브로드캐스트 메커니즘입니다. 이때 메시지 채널의 메시지가 대기열에서 제거되면 메시지 개체도 복사되어 여러 구독자에게 메시지를 전달해야 합니다. 예를 들어, CRM 시스템에서 고객 정보를 얻고 전달된 고객 정보를 기반으로 해당 처리를 수행해야 하는 여러 하위 시스템이 있습니다. 이때 메시지 채널을 전파 채널이라고도 합니다. 또 다른 방법은 동기 방식을 따르는 선점 메커니즘으로, 동시에 한 명의 구독자만 메시지를 처리할 수 있습니다. 게시자-구독자 패턴을 구현하는 메시지 채널은 현재 유휴 구독자를 선택하고 메시지를 대기열에서 빼낸 후 구독자의 메시지 처리 메서드에 전달합니다.

현재 JMS 인터페이스 사양의 Topic 개체에 대해 제공되는 MessagePublisher 및 MessageSubscriber 인터페이스와 같이 게시자-구독자 패턴을 잘 지원할 수 있는 메시지 미들웨어가 많이 있습니다. RabbitMQ는 이 패턴의 자체 구현도 제공합니다. Microsoft의 MSMQ는 이벤트 메커니즘을 도입했지만 대기열이 메시지를 수신하면 구독자에게 알리기 위해 이벤트를 트리거할 수 있습니다. 그러나 엄밀히 말하면 게시자-구독자 패턴의 구현은 아닙니다. Microsoft MVP Udi Dahan을 주요 기여자로 하는 NServiceBus는 MSMQ 및 WCF를 추가로 패키지하고 이 모델을 잘 구현할 수 있습니다.

2.3 메시지 라우터 모드

메시지 채널 모드든 게시자-구독자 모드든 큐는 중추적인 역할을 합니다. 그러나 엔터프라이즈 애플리케이션 시스템에서는 시스템이 점점 더 복잡해지면 성능 요구 사항도 점점 더 높아질 것입니다. 이때 시스템은 여러 대기열의 동시 배포를 지원해야 할 수 있으며 다른 대기열을 배포해야 할 수도 있습니다. . 이러한 대기열은 정의에 따라 주문 처리 메시지, 로그 정보, 쿼리 작업 메시지 등 다양한 메시지를 수신할 수 있습니다. 현재로서는 메시지 생산자와 소비자가 메시지 전달 경로를 결정하는 책임을 맡는 것은 적절하지 않습니다. 실제로 S 단일 책임 원칙에 따르면 이러한 종류의 책임 할당은 비즈니스 논리의 재사용에 도움이 되지 않으며 생산자, 소비자 및 메시지 대기열 간의 결합을 유발하여 확장에 영향을 미칩니다. 체계.

이 세 가지 객체(컴포넌트)는 이러한 책임을 맡는 데 적합하지 않기 때문에, 경로 선택 전달 기능을 특별히 담당하는 새로운 객체를 도입할 필요가 있습니다. 이것이 바로 메시지입니다. 라우터 패턴, 그림과 같이:

메시지 라우팅을 통해 라우팅 규칙을 구성하여 메시지 전달 경로를 지정하고 해당 생성자를 지정할 수 있습니다. 구체적인 소비자 소비. 예를 들어 라우팅 키워드를 지정하고 이를 사용하여 특정 대기열을 지정된 생산자(또는 소비자)에 바인딩합니다. 라우팅 지원은 메시지 전달 및 처리에 유연성을 제공하고 전체 시스템의 메시지 처리 기능을 향상시키는 데도 도움이 됩니다. 동시에 라우팅 개체는 메시지, 대기열 및 경로 주소 지정 간의 관계를 조정하는 중재자(Meditator)처럼 메시지 경로를 찾고 일치하는 논리를 효과적으로 캡슐화합니다.

3 애플리케이션 수준 프로토콜

원격 서비스 통신의 목표는 한 컴퓨터에서 요청을 시작하는 것이며, 다른 컴퓨터는 요청을 받은 후 이에 따라 요청을 처리하고 반환합니다. 요청 측에는 단방향 요청, 동기 요청, 비동기 요청 등의 요청 방법이 있습니다. 네트워크 통신의 원리에 따르면 이를 달성하기 위해 수행해야 할 작업은 요청을 스트림으로 변환하고 전송 프로토콜을 통해 원격 엔드에 전송합니다. 엔드 컴퓨터는 요청한 스트림을 수신한 후 처리가 완료된 후 결과를 스트림으로 변환하고 전송 프로토콜을 통해 호출 엔드에 반환합니다.

원리는 이렇지만 애플리케이션의 편의를 위해 업계에서는 이 원칙을 바탕으로 많은 애플리케이션 수준의 프로토콜을 출시해왔기 때문에 누구나 이런 하위 수준의 것, 일반적으로 애플리케이션을 직접 운영할 필요가 없습니다. -레벨 원격 통신 프로토콜은 다음을 제공합니다.

스트림 작업을 직접 수행하는 문제를 피하기 위해 사용하기 쉽고 적합한 표준 전송 형식을 제공합니다.
네트워크 통신 메커니즘의 구현은 전송 형식을 스트림으로 변환하고 특정 전송 프로토콜을 통해 원격 컴퓨터로 전송하는 것입니다. , 원격 컴퓨터는 이를 전송 형식으로 변환하여 저장하거나 특정 방법으로 사용하여 원격 컴퓨터에 알립니다.

그래서 애플리케이션 수준의 원격 통신 프로토콜을 배울 때 다음 질문을 가지고 공부할 수 있습니다.

전송을 위한 표준 형식이란 무엇입니까?
요청을 전송된 스트림으로 변환하는 방법은 무엇입니까?
스트림을 어떻게 수신하고 처리하나요?
전송 프로토콜은 무엇인가요?

그러나 애플리케이션 수준 원격 통신 프로토콜은 전송 프로토콜에서 크게 개선되지 않으며 주로 애플리케이션 계층에서 스트림을 생성하고 처리할 수 있도록 합니다. 이는 사용되는 언어나 표준에 더 가깝습니다. 일반적으로 Java 분야에서 잘 알려진 프로토콜은 RMI, XML-RPC, Binary-RPC, SOAP, CORBA, JMS입니다. 구체적으로 말하자면, 원격 통신을 위한 이러한 애플리케이션 수준 프로토콜을 살펴보세요.

3.1 RMI(Remote Method Invocation)

RMI는 Java에 맞게 맞춤화된 일반적인 원격 통신 프로토콜입니다. 우리 모두는 단일 VM에서 Java 객체 인스턴스 통신을 직접 호출하여 이를 달성할 수 있다는 것을 알고 있습니다. 물론 이 방법을 원격 통신에 사용할 수 있다면 가장 좋을 것입니다. 이 원격 통신 메커니즘을 RPC(Remote Procedure Call)라고 하며 RMI는 이러한 목표를 위해 탄생했습니다.

RMI는 스텁과 스켈레톤을 사용하여 원격 개체와 통신합니다. 스텁은 원격 개체의 클라이언트 프록시 역할을 하며 원격 개체에 대한 호출은 실제로 개체의 클라이언트 프록시 개체 스텁을 호출하여 완료됩니다. 이 메커니즘을 통해 RMI는 마치 작동합니다. 이는 로컬 작업입니다. TCP/IP 프로토콜인 경우 클라이언트는 서버에서 일부 메소드를 직접 호출합니다. 장점은 강력한 형식이고 컴파일 중에 오류를 확인할 수 있다는 점입니다. 단점은 JAVA 언어에만 기반할 수 있고 클라이언트와 서버가 긴밀하게 결합되어 있다는 것입니다.

RMI를 기반으로 한 완전한 원격 통신 프로세스의 원리를 살펴보겠습니다.

클라이언트가 요청을 시작하고 요청은 다음과 같습니다. RMI 클라이언트로 전달됩니다.

스텁 클래스는

에 따라 요청된 인터페이스를 직렬화합니다. 직렬화된 스트림을 서버에 소켓으로 연결합니다.

서버는 스트림을 수신하여 해당 skelton 클래스로 전달합니다.

skelton 클래스는 요청된 정보를 역직렬화하고 실제 처리 클래스를 호출합니다. 🎜>

처리 클래스가 처리를 완료한 후 결과는 skelton 클래스로 반환됩니다.

Skelton 클래스는 결과를 직렬화하여 보냅니다. 소켓을 통해 클라이언트로의 스트림 끝에 있는

스텁은 스트림을 수신한 후 역직렬화되고 역직렬화된 Java 객체를 호출자에게 반환합니다.

원칙을 바탕으로 이전에 애플리케이션 수준 프로토콜을 학습하면서 나온 몇 가지 질문에 답해 보겠습니다.

전송 표준 형식은 무엇입니까? 은 Java ObjectStream입니다.
요청을 전송된 스트림으로 변환하는 방법은 무엇입니까? 요청된 Java 객체 정보를 Java 직렬화 메커니즘을 기반으로 스트림으로 변환합니다.
스트림을 어떻게 수신하고 처리하나요? 채택된 프로토콜에 따라 해당 청취 포트를 시작합니다. 스트림이 들어오면 Java 직렬화 메커니즘을 기반으로 스트림을 역직렬화하고 RMI 프로토콜에 따라 해당 처리 객체 정보를 얻어 호출하여 처리합니다. 처리가 완료되면 Java 직렬화 메커니즘을 기반으로 최종 결과도 반환됩니다.
전송 프로토콜은 무엇인가요? 소켓.

3.2 XML-RPC

RPC는 C/S 모드를 사용하며 http 프로토콜을 채택하고 서버에 요청을 보내고 서버가 결과를 반환할 때까지 기다립니다. 요청에는 일반적으로 "classname.methodname" 형식의 매개변수 세트와 텍스트 세트가 포함됩니다. 장점은 크로스 언어, 크로스 플랫폼이며 C 측과 S 측의 독립성이 더 크다는 점입니다. 단점은 객체를 지원하지 않고 컴파일러에서 오류를 확인할 수 없으며 런타임에만 확인할 수 있다는 것입니다. .

XML-RPC도 RMI와 유사한 원격 호출 프로토콜입니다. RMI와 차이점은 표준 xml 형식을 사용하여 요청된 정보(요청된 개체, 메서드, 매개 변수 등)를 정의한다는 것입니다. 이것의 이점은 언어 간 의사소통에도 사용될 수 있습니다.

XML-RPC 프로토콜의 원격 통신 프로세스를 살펴보겠습니다.

클라이언트는 요청을 시작하고 요청 정보를 다음과 같이 입력합니다. XML-RPC 프로토콜;

채우기가 완료된 후 xml은 스트림으로 변환되어 전송 프로토콜을 통해 전송됩니다. 요청된 정보를 받아 XML-RPC 프로토콜에 따라 처리합니다.

처리 후 XML에 따라 결과를 작성합니다. RPC 프로토콜을 작성하여 반환합니다.

이와 비슷하게 질문에 답해 보세요.

전송의 표준 형식은 무엇입니까?

표준 형식 XML.

요청을 전송된 스트림으로 변환하는 방법은 무엇입니까?
XML을 스트림으로 변환합니다.
스트림을 어떻게 수신하고 처리하나요?
리스닝 포트를 통해 요청된 스트림을 얻어 XML로 변환하고 프로토콜에 따라 요청된 정보를 얻어 처리한 후 결과를 XML로 작성하여 반환합니다.
전송 프로토콜은 무엇인가요?
http.
3.3 Binary-RPC
이름에서 알 수 있듯이 Binary-RPC는 XML-RPC와 유사하지만 차이점은 표준 전송 형식입니다. XML에서 변환됩니다.

마찬가지로 질문에 답해 보세요.

전송의 표준 형식은 무엇입니까?

표준 형식의 바이너리 파일입니다.

요청을 전송된 스트림으로 변환하는 방법은 무엇입니까?
바이너리 형식 파일을 스트림으로 변환합니다.
스트림을 어떻게 수신하고 처리하나요?
리스닝 포트를 통해 요청된 스트림을 가져와서 바이너리 파일로 변환하고, 프로토콜에 따라 요청된 정보를 가져와 처리한 후 결과를 XML로 작성하여 반환합니다.
전송 프로토콜은 무엇인가요?
http.
3.4 SOAP
SOAP는 원래 Simple Object Access Protocol을 의미하며 분산 환경을 위한 XML 기반의 정보 교환을 위한 경량 통신 프로토콜이라고 볼 수 있습니다. SOAP는 XML RPC의 고급 버전이며 둘 다 http+XML이라는 원칙은 동일합니다. 유일한 차이점은 둘이 정의한 XML 사양도 SOAP에서 채택한 서비스 호출 프로토콜 표준이라는 것입니다. Webservice이므로 여기에 더 이상 설명이 없습니다.

웹 서비스에서 제공하는 서비스는 웹 컨테이너를 기반으로 하며, 하위 계층은 일기 예보 서비스와 같은 원격 서비스 제공자와 유사합니다. 요청 응답 메커니즘이며 시스템 간 및 플랫폼 간입니다. 서비스를 제공하는 것은 서블릿을 통해서이다.

먼저 클라이언트는 서버로부터 WebService의 WSDL을 획득함과 동시에 클라이언트에 프록시 클래스(프록시 클래스)를 생성합니다. 이 프록시 클래스는 요청 및 응답을 담당합니다. 웹서비스 서버. XML 형식의 데이터 조각이 SOAP 형식의 데이터 스트림으로 캡슐화되어 서버로 전송되면 프로세스 개체가 생성되고 요청으로 수신된 SOAP 패킷이 구문 분석된 후 처리됩니다. 처리가 완료되면 계산 결과를 SOAP로 래핑한 후 해당 패키지를 Response로 클라이언트의 프록시 클래스(Proxy Class)에 전달합니다. 마찬가지로 프록시 클래스도 SOAP 패키지를 구문 분석하고 후속 작업을 수행합니다. 이것은 WebService가 실행되는 프로세스입니다.

웹 서비스는 일반적으로 5가지 레벨로 구분됩니다.

Http 전송 채널

XML 데이터 형식

SOAP 캡슐화 형식;

WSDL 설명

UDDI UDDI는 기업이 웹 서비스를 등록하고 검색하는 데 사용할 수 있는 디렉토리 서비스입니다.

3.5 JMS

JMS는 Java 분야에서 원격 통신을 달성하기 위한 수단이자 방법이지만 JMS 기반의 원격 통신은 RPC와는 다르지만 RPC의 효과는 다음과 같습니다. , 그러나 프로토콜 수준에서 정의되지 않았기 때문에 JMS가 RPC 프로토콜이라고 생각하지 않지만 실제로는 원격 통신 프로토콜이지만 다른 언어 시스템에서도 JMS와 유사한 것이 통합될 수 있는 메커니즘이 있습니다. 메시지 메커니즘은 일반적으로 동시성이 높고 분산된 분야에서 권장되는 통신 메커니즘입니다. 여기서 주요 문제는 내결함성입니다.

JMS는 Java 메시지 서비스입니다. JMS 클라이언트는 JMS 서비스를 통해 비동기 메시지를 전송할 수 있습니다. JMS는 지점 간(P2P) 및 게시/구독(Pub/Sub)의 두 가지 메시지 모델, 즉 지점 간 및 게시-구독 모델을 지원합니다.

JMS에서 원격 통신 과정을 살펴보겠습니다.

클라이언트는 요청을 JMS 규정을 준수하는 메시지로 변환합니다.

JMS API를 통해 메시지를 JMS 대기열 또는 주제에 넣습니다.

JMS 대기열인 경우 해당 대상으로 전송됩니다. 대기열. 주제인 경우 이 주제를 구독하는 JMS 대기열로 전송됩니다.

처리측에서는 JMS Queue를 순환하여 메시지를 획득한 후 메시지를 구문 분석하고 JMS 프로토콜에 따라 처리합니다.

이와 비슷하게 질문에 답해 보세요.

전송의 표준 형식은 무엇입니까? JMS에서 지정한 메시지입니다.
요청을 전송된 스트림으로 변환하는 방법은 무엇입니까? 메시지에 매개변수 정보를 입력합니다.
스트림을 어떻게 수신하고 처리하나요? JMS 대기열은 메시지를 수신한 후 처리된 후 전송 또는 멀티캐스트를 위해 메시지 형식으로 대기열에 배치됩니다.
전송 프로토콜은 무엇인가요? 제한이 없습니다.

JMS 기반으로 원격 비동기 호출을 구현하는 데 일반적으로 사용되는 방법 중 하나이기도 합니다.

4.1 RPC와 RMI

RPC는 교차 언어인 반면 RMI는 Java만 지원합니다.
RMI는 원격 객체 메소드를 호출하여 메소드가 Java 객체 및 기본 데이터 유형을 반환할 수 있도록 허용하는 반면 RPC는 객체 개념을 지원하지 않으며 RPC 서비스로 전송되는 메시지는 외부 데이터로 표시됩니다. 표현, XDR) 엔디안 클래스와 데이터 유형 구조 간의 차이점을 추상화하는 언어 표현입니다. XDR에서 정의한 데이터 유형만 전달할 수 있습니다. RMI는 객체 지향 Java RPC라고 할 수 있습니다.
메서드 호출 시 RMI에서 원격 인터페이스는 각 원격 메소드가 메소드 서명을 가질 수 있도록 합니다. 서버에서 메소드가 실행되지만 일치하는 서명이 원격 인터페이스에 추가되지 않으면 RMI 클라이언트에서 새 메소드를 호출할 수 없습니다. RPC에서 요청이 RPC 서버에 도착하면 요청에는 일반적으로 "classname.methodname" 형식의 매개변수 세트와 텍스트 값이 포함됩니다. 이는 요청된 메서드가 "methodname"이라는 클래스에 있음을 RPC 서버에 나타냅니다. 그런 다음 RPC 서버는 일치하는 클래스와 메서드를 검색하고 이를 해당 메서드 매개 변수 유형에 대한 입력으로 사용합니다. 여기의 매개변수 유형은 RPC 요청의 유형과 일치합니다. 일치가 성공하면 이 메서드가 호출되고 결과가 인코딩되어 클라이언트에 반환됩니다.
RPC 자체에는 사양이 없지만 기본 작동 메커니즘은 동일합니다. 즉, 직렬화/역직렬화+스텁+스켈레톤입니다. RPC입니다. 예: rmi .net-remoting ws/soap/rest hessian xmlrpc thrift potocolbuffer.
Java로 완전한 소켓 통신 인터페이스를 제공하지만 소켓을 사용하려면 클라이언트와 서버가 애플리케이션 수준 프로토콜을 사용하여 데이터를 인코딩하고 교환해야 합니다. 소켓을 대체하는 프로토콜은 프로시저 호출을 위한 통신 인터페이스를 추상화하는 RPC(원격 프로시저 호출)로, 프로그래머가 로컬 프로시저를 호출하는 것만큼 원격 프로시저를 호출하는 것을 편리하게 만듭니다. RPC 시스템은 XDR을 사용하여 원격 호출의 매개변수와 반환 값을 인코딩합니다. 하지만 RPC는 객체를 지원하지 않기 때문에 객체지향 원격 호출 RMI(Remote Method Invocation)는 불가피한 선택이 되었습니다. RMI를 사용하면 원격 개체를 호출하는 것이 로컬 개체를 호출하는 것만큼 편리합니다. RMI는 TCP/IP 프로토콜을 기반으로 구축된 원격 호출 방법인 JRMP(Java Remote Method Protocol) 통신 프로토콜을 사용합니다.

4.2 JMS 및 RMI

JMS 서비스를 사용하면 객체가 네트워크의 한 JVM에서 JVM의 다른 JVM으로 직접 비동기적으로 물리적으로 이동됩니다. (메시지 알림 메커니즘), RMI 객체는 로컬 JVM에 바인딩되어 있으며 함수 매개변수와 반환 값만 네트워크를 통해 전송됩니다(요청 응답 메커니즘).
RMI는 일반적으로 동기식입니다. 즉, 클라이언트가 서버의 메서드를 호출할 때 클라이언트를 계속 실행하기 전에 상대방이 돌아올 때까지 기다려야 합니다. 로컬 메소드를 호출하는 것은 다음과 같습니다. 마찬가지로 이것도 RMI의 기능입니다. JMS는 일반적으로 메시지를 한 지점에서 메시지 서버로 보낸 후 일반적으로 누가 메시지를 사용하는지 신경 쓰지 않습니다. 따라서 일반적으로 RMI 애플리케이션은 긴밀하게 결합되는 반면 JMS 애플리케이션은 비교적 느슨하게 결합됩니다.

4.3 웹 서비스 및 RMI

RMI는 tcp 프로토콜을 통해 직렬화 가능한 Java 개체를 전송하며 Java 가상 머신, 바인딩 언어 및 클라이언트에서만 사용할 수 있습니다. 클라이언트와 클라이언트 모두 서버는 자바여야 합니다. Webservice에는 이러한 제한이 없습니다. Webservice는 언어 및 플랫폼에 관계없이 http 프로토콜을 통해 xml 텍스트 파일을 전송합니다.

4.4 웹 서비스와 JMS

웹 서비스는 원격 서비스 호출에 중점을 두고, jms는 정보 교환에 중점을 둡니다.

대부분의 경우 Webservice는 두 시스템(Consumer Producer) 간의 직접적인 상호 작용인 반면, jms는 대부분의 경우 3자 시스템 상호 작용(Consumer Producer)입니다. 물론 JMS는 소비자나 생산자가 브로커 역할을 하는 한 요청-응답 모드 통신을 구현할 수도 있습니다.

JMS는 클라이언트와 서비스 제공자를 완전히 분리하는 비동기식 호출을 달성할 수 있으며 트래픽 피크를 견딜 수 있습니다. WebService 서비스는 일반적으로 동기식으로 호출되며 복잡한 개체 변환이 필요합니다. SOAP와 비교할 때 이제 JSON과 REST는 모두입니다. 좋은 http 아키텍처 솔루션입니다.

JMS는 Java 플랫폼의 메시지 사양입니다. 일반적으로 jms 메시지는 xml이 아니라 Java 객체입니다. 분명히 jms는 이기종 시스템을 고려하지 않습니다. 직설적으로 말하면 JMS는 Java가 아닌 것을 고려하지 않습니다. 그러나 다행스럽게도 대부분의 jms 제공자(즉, JMS의 다양한 구현 제품)는 이질적인 문제를 해결했습니다. WebService의 크로스 플랫폼과 비교하면 각각 고유한 장점이 있습니다.

5가지 선택적 구현 기술

현재 Java 필드를 사용하여 원격 통신을 위한 프레임워크나 라이브러리를 구현할 수 있습니다. 잘 알려진 기술로는 JBoss-Remoting, Spring-Remoting, Hessian, Burlap이 있습니다. , XFire(Axis) , ActiveMQ, Mina, Mule, EJB3 등 각각에 대해 간략하게 소개하고 평가하겠습니다. 실제로 분산 서비스 프레임워크를 구축하려면 이러한 사항에 대한 매우 깊은 이해가 필요합니다. 분산 서비스 프레임워크 실제로 분산 분야와 애플리케이션 수준 분야의 문제 해결이 포함됩니다.

물론 원격 네트워크 통신 원리(전송 프로토콜+Net IO)를 기반으로 자체 통신 프레임워크나 라이브러리를 구현할 수도 있습니다.

그러면 이러한 원격 통신 프레임워크나 라이브러리를 이해할 때 연구에 어떤 질문을 던질 것인가요?

는 어떤 프로토콜을 기반으로 하나요?
요청을 시작하는 방법은 무엇입니까?
요청을 프로토콜에 맞는 형식으로 변환하는 방법은 무엇입니까?
전송에는 어떤 전송 프로토콜을 사용하나요?
응답자는 요청을 받기 위해 어떤 메커니즘을 사용합니까?
스트림을 전송 형식으로 복원하는 방법은 무엇입니까?
처리 후 어떻게 대응하나요?

5.1 Spring-Remoting

Spring-Remoting은 Java 분야에서 Spring이 제공하는 원격 통신 프레임워크입니다. 이 프레임워크를 기반으로 일반 Spring Bean도 쉽게 사용할 수 있습니다. 특정 원격 프로토콜에서 Published로 변환되면 Spring Bean을 원격 호출 Bean으로 구성할 수도 있습니다.

은 어떤 프로토콜을 기반으로 하나요? 원격 통신 프레임워크인 Spring은 여러 원격 통신 라이브러리를 통합하여 rmi, http+io, xml-rpc, bin-rpc 등과 같은 여러 프로토콜을 지원합니다.
요청을 시작하는 방법은 무엇입니까? Spring에서는 원격 호출 Bean에 프록시 구현을 사용하므로 요청은 전적으로 서비스 인터페이스 호출을 통해 시작됩니다.
요청을 프로토콜에 맞는 형식으로 변환하는 방법은 무엇입니까? Spring은 요청된 객체 정보를 프로토콜에 따라 스트림으로 변환합니다. 예를 들어 Spring Http Invoker는 Spring 자체에서 정의한 프로토콜을 기반으로 구현되며, 전송 프로토콜은 http이며 요청 정보는 java를 기반으로 변환됩니다. 직렬화 메커니즘. 스트림 전송.
전송에는 어떤 전송 프로토콜이 사용되나요? rmi, http 등과 같은 다중 전송 프로토콜을 지원합니다.
응답자는 요청을 받기 위해 어떤 메커니즘을 사용합니까? 응답자는 요청을 받기 위해 프로토콜 방식을 따릅니다. 사용자의 경우 스프링 구성 방법을 통해 일반 스프링 빈을 응답자 또는 서버로 구성하기만 하면 됩니다.
스트림을 전송 형식으로 복원하는 방법은 무엇입니까? 프로토콜에 따라 복원합니다.
처리 후 어떻게 대응하나요? 처리 후 바로 복귀할 수 있으며, spring-remoting은 프로토콜 방식에 따라 해당 직렬화를 수행합니다.

5.2 Hessian

Hessian은 caucho에서 제공하는 바이너리-RPC 기반의 원격 통신 라이브러리입니다.

는 어떤 프로토콜을 기반으로 하나요? Binary-RPC 프로토콜을 기반으로 구현되었습니다.
요청을 시작하는 방법은 무엇입니까? 요청은 Hessian 자체에서 제공하는 API를 통해 시작되어야 합니다.
요청을 프로토콜에 맞는 형식으로 변환하는 방법은 무엇입니까? Hessian은 사용자 정의 직렬화 메커니즘을 통해 요청 정보를 직렬화하여 바이너리 스트림을 생성합니다.
전송에는 어떤 전송 프로토콜이 사용되나요? Hessian은 HTTP 프로토콜을 기반으로 전송합니다.
응답자는 요청을 받기 위해 어떤 메커니즘을 사용합니까? 응답자는 Hessian에서 제공하는 API를 기반으로 요청을 받습니다.
스트림을 전송 형식으로 복원하는 방법은 무엇입니까? Hessian은 자체 직렬화 메커니즘에 따라 요청 정보를 역직렬화하고, 사용자에게 전달되면 이미 해당 요청 정보 객체입니다.
처리 후 어떻게 대응하나요? 처리 후 바로 반환하고, Hessian은 결과 객체를 직렬화하여 호출측으로 전송합니다.

5.3 Burlap

Burlap도 caucho에서 제공합니다. 헤센과 차이점은 XML-RPC 프로토콜을 기반으로 한다는 점입니다.

은 어떤 프로토콜을 기반으로 하나요? XML-RPC 프로토콜을 기반으로 구현되었습니다.
요청을 시작하는 방법은 무엇입니까? Burlap에서 제공하는 API를 기준으로 작성되었습니다.
요청을 프로토콜에 맞는 형식으로 변환하는 방법은 무엇입니까? 요청 정보를 프로토콜에 맞는 XML 형식으로 변환하고 스트림으로 변환하여 전송합니다.
전송에는 어떤 전송 프로토콜이 사용되나요? Http 프로토콜.
응답자는 요청을 받기 위해 어떤 메커니즘을 사용합니까? HTTP 요청을 수신합니다.
스트림을 전송 형식으로 복원하는 방법은 무엇입니까? XML-RPC 프로토콜에 따라 복원합니다.
처리 후 어떻게 대응하나요? 반환 결과는 XML로 작성되어 Burlap에 의해 호출측으로 반환됩니다.

5.4 XFire, Axis

XFire와 Axis는 WebService의 구현 프레임워크로 WebService는 완전한 SOA 아키텍처 구현 표준이라고 볼 수 있으므로 XFire와 Axis를 사용하는 것은 또한 웹서비스 방식을 사용한다는 뜻이기도 합니다.

은 어떤 프로토콜을 기반으로 하나요? SOAP 프로토콜을 기반으로 합니다.
요청을 시작하는 방법은 무엇입니까? 원격 서비스 대리권을 받은 후 직접 통화하세요.
요청을 프로토콜에 맞는 형식으로 변환하는 방법은 무엇입니까? 요청 정보를 SOAP 프로토콜을 따르는 XML 형식으로 변환한 후 프레임워크에서 전송할 수 있도록 스트림으로 변환합니다.
전송에는 어떤 전송 프로토콜이 사용되나요? Http 프로토콜.
응답자는 요청을 받기 위해 어떤 메커니즘을 사용합니까? HTTP 요청을 수신합니다.
스트림을 전송 형식으로 복원하는 방법은 무엇입니까? SOAP 프로토콜에 따라 복원합니다.
처리 후 어떻게 대응하나요? 반환 결과는 XML로 작성되어 프레임워크에 의해 호출 측에 반환됩니다.

5.5 ActiveMQ

ActiveMQ는 JMS와 같은 메시지 메커니즘을 기반으로 원격 통신을 구현하는 것이 좋습니다. 메시지 메커니즘 자체로 JMS 기반의 원격 통신 구현이 가능하며 동기/비동기/단방향 호출 등을 쉽게 구현할 수 있으며 내결함성 측면에서도 메시지 메커니즘이 좋은 선택입니다. Erlang이 내결함성을 갖추기 위한 중요한 기반입니다.

은 어떤 프로토콜을 기반으로 하나요? JMS 프로토콜을 기반으로 합니다.
요청을 시작하는 방법은 무엇입니까? 요청하려면 JMS API를 따르세요.
요청을 프로토콜에 맞는 형식으로 변환하는 방법은 무엇입니까? 확실하지는 않습니다. 바이너리 스트림인 것 같습니다.
전송에는 어떤 전송 프로토콜이 사용되나요? 소켓, http 등 다중 전송 프로토콜을 지원합니다.
응답자는 요청을 받기 위해 어떤 메커니즘을 사용합니까? 프로토콜을 준수하는 포트를 수신합니다.
스트림을 전송 형식으로 복원하는 방법은 무엇입니까? 질문 3과 동일합니다.
처리 후 어떻게 대응하나요? JMS API에 따라 메시지를 생성하고 JMS 대기열에 씁니다.

5.6 Mina

Mina는 Apache에서 제공하는 통신 프레임워크입니다. 앞서 언급한 프레임워크나 라이브러리는 기본적으로 BIO를 기반으로 합니다. Mina는 NIO를 사용하면 동시성이 증가하면 BIO에 비해 성능이 크게 향상되며 Java 성능 향상은 NIO와 OS의 긴밀한 통합과 밀접한 관련이 있습니다.

은 어떤 프로토콜을 기반으로 하나요? 순수 소켓+NIO 기준입니다.
요청을 시작하는 방법은 무엇입니까? 미나가 제공하는 클라이언트 API를 통해.
요청을 프로토콜에 맞는 형식으로 변환하는 방법은 무엇입니까? Mina는 Java 직렬화 메커니즘을 따라 요청 객체를 직렬화합니다.
전송에는 어떤 전송 프로토콜이 사용되나요? 소켓, http 등 다중 전송 프로토콜을 지원합니다.
응답자는 요청을 받기 위해 어떤 메커니즘을 사용합니까? NIO 모드에서 프로토콜 포트를 수신합니다.
스트림을 전송 형식으로 복원하는 방법은 무엇입니까? Java 직렬화 메커니즘에 따라 요청 개체를 역직렬화합니다.
처리 후 어떻게 대응하나요? 반품은 Mina API를 따르세요.

MINA는 NIO이므로 비동기 호출을 지원한다는 것은 놀라운 일이 아닙니다.

6 RPC 프레임워크 개발 및 현황

RPC(Remote Procedure Call)는 간단히 말하면, 애플리케이션이 로컬 메소드를 호출하는 것처럼 원격 메소드를 호출할 수 있도록 하는 프로토콜입니다. 프로세스 또는 서비스는 분산 서비스, 분산 컴퓨팅, 원격 서비스 호출 등과 같은 다양한 시나리오에 적용될 수 있습니다. RPC에 대해 말하면 업계에는 Dubbo, Thrift, gRPC, Hprose 등과 같은 우수한 오픈 소스 RPC 프레임워크가 많이 있습니다. RPC의 특징과 일반적인 원격 호출 방법, 그리고 몇 가지 뛰어난 오픈 소스 RPC 프레임워크를 간략하게 소개하겠습니다.

다른 원격 호출 방식에 비해 RPC, HTTP, RMI, Web Service 모두 원격 호출을 완료할 수 있지만 구현 방식과 초점이 다릅니다.

6.1 RPC 및 HTTP

HTTP(HyperText Transfer Protocol)는 표준 의미 체계를 사용하여 지정된 리소스(사진, 인터페이스 등)에 액세스하는 애플리케이션 계층 통신 프로토콜입니다. 네트워크의 서버는 계약 내용을 식별할 수 있습니다. HTTP 프로토콜은 원격 요청을 완료하고 요청 결과를 반환할 수 있는 리소스 액세스 프로토콜입니다.

HTTP의 장점은 단순성, 사용 용이성, 강력한 이해성 및 언어 독립성입니다. Weibo를 비롯한 원격 서비스 호출에 널리 사용됩니다. HTTP의 단점은 프로토콜 헤더가 더 무겁고 일반 요청과 특정 서버 사이의 링크가 길다는 것입니다. 여기에는 DNS 확인, Nginx 프록시 등이 포함될 수 있습니다.

RPC는 프로토콜 사양입니다. HTTP는 RPC의 구현으로 간주될 수도 있고, HTTP는 RPC의 전송 프로토콜로 적용될 수도 있습니다. RPC 서비스는 상대적으로 자동화 수준이 높고, 강력한 서비스 관리 기능을 구현할 수 있으며, 언어와 결합하면 더욱 친숙하고 성능도 뛰어납니다. HTTP에 비해 RPC의 단점은 상대적으로 복잡하고 학습 비용이 약간 높다는 것입니다.

6.2 RPC 및 RMI

RMI(Remote Method Invocation)는 Java 언어의 원격 메소드 호출을 의미합니다. RMI의 각 메소드에는 메소드 서명이 있습니다. 원격 메소드 호출. RMI는 Java 언어에서만 사용할 수 있습니다. RMI는 객체 지향 Java RPC로 생각할 수 있습니다.

6.3 RPC 및 웹 서비스

웹 서비스는 웹을 기반으로 서비스를 게시, 쿼리, 호출하는 아키텍처 방식으로, 서비스 관리 및 사용에 중점을 둡니다. 웹 서비스는 일반적으로 WSDL을 통해 서비스를 설명하고 SOAP를 사용하여 HTTP를 통해 서비스를 호출합니다.

RPC는 원격 액세스 프로토콜인 반면 웹 서비스는 RPC를 통해 서비스 호출을 할 수도 있으므로 동일한 RPC 프레임워크와 비교하기에는 웹 서비스가 더 적합합니다. RPC 프레임워크가 서비스 검색 및 관리를 제공하고 HTTP를 전송 프로토콜로 사용하는 경우 이는 실제로 웹 서비스입니다.

웹 서비스에 비해 RPC 프레임워크는 흐름 제어, SLA 관리 등을 포함하여 서비스에 대해 보다 세밀한 거버넌스를 수행할 수 있으며 마이크로서비스 및 분산 컴퓨팅에서 더 큰 이점을 갖습니다.

RPC는 HTTP 프로토콜을 기반으로 할 수도 있고 TCP 프로토콜을 기반으로 할 수도 있습니다. 웹 서비스는 HTTP 프로토콜을 기반으로 하는 RPC로 크로스 플랫폼 성능이 좋지만 TCP 프로토콜 기반의 RPC만큼 성능이 좋지 않습니다. RPC 성능에 직접적인 영향을 미치는 두 가지 측면이 있습니다. 하나는 전송 방법이고 다른 하나는 직렬화입니다.

우리 모두 알고 있듯이 TCP는 전송 계층 프로토콜이고, HTTP는 애플리케이션 계층 프로토콜이며, 전송 계층은 애플리케이션 계층보다 낮습니다. 데이터 전송 측면에서는 계층이 낮을수록 빠릅니다. 따라서 일반적으로 TCP는 HTTP Quick보다 빨라야 합니다.

7 요약

원격 통신 분야에는 여전히 관련된 지식 포인트가 많이 있습니다. 예를 들면 다음과 같습니다. 통신 프로토콜(소켓/tcp/http/udp/rmi /xml -rpc 등), 메시지 메커니즘, 네트워크 IO(BIO/NIO/AIO), 멀티스레드, 로컬 호출 및 원격 호출 투명 솔루션(Java 클래스로더, 동적 프록시, 단위 테스트 등 포함) , 비동기 및 동기 호출, 네트워크 통신 처리 메커니즘(자동 재연결, 브로드캐스트, 예외, 풀 처리 등), Java 직렬화(다양한 프로토콜의 비공개 직렬화 메커니즘 등), 다양한 프레임워크의 구현 원리(전송 형식, 방법 전송 형식을 스트림으로 변환하는 방법, 요청 정보를 전송 형식으로 변환하는 방법, 스트림을 수신하는 방법, 스트림을 전송 형식으로 복원하는 방법 등) 중 어느 것을 능숙해야 하는지 실제 필요에 따라 결정됩니다.원칙을 이해해야만 쉽게 선택할 수 있습니다.필요에 따라 개인 원격 통신 프로토콜을 만들 수도 있습니다. 분산 응용 프로그램을 사용하려면 위에서 언급한 지식 포인트 정도는 상대적으로 잘 이해해야 한다고 생각합니다.