Java 빅 데이터 - RPC

RPC 와 Http 서비스의 차이 점:https://blog.csdn.net/wangyunpeng0319/article/details/78651998
RPC 는 주로 TCP / IP 프로 토 콜 을 바탕 으로 하 는 것 이 고 HTTP 서 비 스 는 주로 HTTP 프로 토 콜 을 바탕 으로 하 는 것 입 니 다. 우 리 는 모두 HTTP 프로 토 콜 이 전송 층 프로 토 콜 TCP 위 에 있다 는 것 을 알 고 있 기 때문에 효율 적 으로 볼 때 RPC 는 당연히 한 수 위 입 니 다.
세 가지 측면 에서 RPC: RPC 구조, 동기 비동기 호출 및 유행 하 는 RPC 프레임 워 크 를 소개 합 니 다.
RPC 구조:
네 개의 핵심 구성 요 소 는 각각 Client 입 니 다. ,Server, Client Stub 및 Server Stub, 이 Stub 는 존 근 으로 이해 할 수 있 습 니 다.
 
RPC 는 주로 대형 기업 에 사용 되 는데 대형 기업 안에 시스템 이 많 고 업무 라인 이 복잡 하 며 효율 적 인 장점 이 매우 중요 하기 때문에 이때 RPC 의 장점 이 비교적 뚜렷 하 다.실제 개발 에 서 는 이렇게 하 는데 프로젝트 는 보통 Maven 으로 관리 합 니 다.예 를 들 어 우 리 는 주문 서 를 처리 하 는 시스템 서 비 스 를 가지 고 있 습 니 다. 먼저 그의 모든 인터페이스 (여기 가 바로 자바 중의 interface 를 말 합 니 다. 그 다음 에 전체 프로젝트 를 하나의 jar 가방 으로 포장 하고 서버 쪽 에서 이 두 개의 라 이브 러 리 를 도입 한 다음 에 해당 하 는 기능 을 실현 합 니 다. 클 라 이언 트 쪽 도 이 두 개의 라 이브 러 리 를 도입 하면 호출 할 수 있 습 니 다.왜 그 랬 어 요?주로 클 라 이언 트 쪽 jar 가방 의 크기 를 줄 이기 위해 서 입 니 다. 포장 이 발 표 될 때마다 jar 가방 이 너무 많 으 면 효율 에 영향 을 주기 때 문 입 니 다.또한 클 라 이언 트 와 서버 를 결합 시 켜 코드 의 이식 성 을 높 인 다. 

클 라 이언 트 (Client), 서비스의 호출 자.

서버 (Server), 진정한 서비스 제공 자.

클 라 이언 트 는 서버 의 주소 메 시 지 를 저장 하고 클 라 이언 트 의 요청 파 라 메 터 를 네트워크 메시지 로 포장 한 다음 에 네트워크 를 통 해 원 격 으로 서비스 측 에 보 냅 니 다.

서버 캐 시 루트 는 클 라 이언 트 가 보 낸 메 시 지 를 받 아 메 시 지 를 해제 하고 로 컬 방법 을 호출 합 니 다.

서버 서비스 제공:

package cn.itcast.bigdata.rpc;

public interface LoginServiceInterface {
	
	public static final long versionID=1L;
	
	public String login(String username,String password);
	

}


package cn.itcast.bigdata.rpc.impl;

import cn.itcast.bigdata.rpc.LoginServiceInterface;

public class LoginServiceImpl implements LoginServiceInterface{

	@Override
	public String login(String username, String password) {
		
		System.out.println(username + "     ，    ");
		
		
		return username + "successfully loged in , welcome......";
	}

}

서버 게시 서비스:

package cn.itcast.bigdata.rpc.publish;

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.ipc.RPC;
import org.apache.hadoop.ipc.RPC.Builder;
import org.apache.hadoop.ipc.RPC.Server;

import cn.itcast.bigdata.rpc.ClientNameNodeProtocol;
import cn.itcast.bigdata.rpc.LoginServiceInterface;
import cn.itcast.bigdata.rpc.impl.LoginServiceImpl;
import cn.itcast.bigdata.rpc.impl.NameNodeNameSystem;

public class publish {

	public static void main(String[] args) throws Exception {

		Builder builder = new RPC.Builder(new Configuration());
		builder.setBindAddress("localhost").setPort(13144).setProtocol(LoginServiceInterface.class)
				.setInstance(new LoginServiceImpl());
		Server server1 = builder.build();
		System.out.println("server1   .....");
		server1.start();

		Builder builder2 = new RPC.Builder(new Configuration());
		builder2.setBindAddress("master").setPort(1314)
				.setProtocol(ClientNameNodeProtocol.class)
				.setInstance(new NameNodeNameSystem());
		Server server2 = builder2.build();
		System.out.println("server2   .....");
		server2.start();

	}


}

클 라 이언 트 호출 서비스:

package cn.itcast.bigdata.rpc;


/**
 * hdfs    namenode               ——  
 * @author
 *
 */
public interface ClientNameNodeProtocol {
	
	public static final long versionID = 100L;
	
	public String getMetaData(String path);

}

package cn.itcast.bigdata.rpc;

public interface LoginServiceInterface {
	
	public static final long versionID=1L;
	
	public String login(String username,String password);
	

}

동기 호출 과 비동기 호출
동기 호출 이란 무엇 입 니까?비동기 호출 이란 무엇 입 니까? 클 라 이언 트 가 호출 이 완료 되 기 를 기다 리 고 결 과 를 되 돌려 주 는 것 이다. 클 라 이언 트 가 호출 실행 이 완료 되 기 를 기다 리 지 않 고 결 과 를 되 돌려 주 는 통 지 를 받 을 수 있 습 니 다.클 라 이언 트 가 결과 에 관심 이 없다 면 일방적인 호출 이 될 수 있 습 니 다.이 과정 은 자바 의 callable 와 runnable 인터페이스 와 유사 하 다. 우리 가 비동기 실행 을 할 때 실행 결 과 를 알 아야 한다 면 callable 인 터 페 이 스 를 사용 할 수 있 고 Future 류 를 통 해 비동기 실행 결과 정 보 를 얻 을 수 있다.실행 결과 에 관심 이 없다 면 runnable 인 터 페 이 스 를 직접 사용 하면 된다. 결 과 를 되 돌려 주지 않 기 때문이다. 물론 callable 도 가능 하 다. 우 리 는 Future 를 얻 지 않 으 면 된다.
유행 하 는 RPC 프레임 워 크
현재 유행 하 는 오픈 소스 RPC 프레임 은 비교적 많다.다음은 세 가 지 를 중점적으로 소개 한다.

gRPC 는 구 글 이 최근 발표 한 오픈 소스 소프트웨어 로 최신 HTTP 2.0 프로 토 콜 을 기반 으로 하고 흔히 볼 수 있 는 많은 프로 그래 밍 언어 를 지원 합 니 다.HTTP 2.0 은 바 이 너 리 를 기반 으로 한 HTTP 프로 토 콜 업그레이드 버 전 으로 현재 브 라 우 저 들 이 빠 른 속도 로 지원 하고 있다 는 것 을 알 고 있 습 니 다.이 RPC 프레임 워 크 는 HTTP 프로 토 콜 을 기반 으로 이 루어 졌 으 며, 하부 에 서 는 Netty 프레임 워 크 의 지원 을 사용 했다.

Thrift 는 페 이 스 북 의 오픈 소스 프로젝트 로 주로 언어 를 뛰 어 넘 는 서비스 개발 구조 이다.정 의 된 IDL 정의 파일 에 대해 서비스 코드 프레임 워 크 를 자동 으로 생 성 하 는 코드 생 성기 가 있 습 니 다.사용 자 는 그 전에 2 차 개발 만 하면 되 고, 밑바닥 RPC 통신 등에 대해 서 는 투명 하 다.그러나 이것 은 사용자 에 게 특정 분야 의 언어 라 는 특성 을 배 워 야 하기 때문에 일정한 비용 이 든다.

Dubbo 는 알 리 그룹 이 기원 한 유명한 RPC 프레임 워 크 로 많은 인터넷 회사 와 기업 응용 에서 널리 사용 된다.협의 와 직렬 화 프레임 워 크 를 모두 삽입 할 수 있 는 것 은 그 뚜렷 한 특색 이다.같은 원 격 인 터 페 이 스 는 자바 인 터 페 이 스 를 기반 으로 하고 스프링 프레임 워 크 를 바탕 으로 개발 이 편리 하 다.단일 파일 로 편리 하 게 포장 할 수 있 고 독립 프로 세 스 가 실행 되 며 현재 의 마이크로 서비스 개념 과 일치 합 니 다.

HTTP 서비스
사실은 오래전 에 저 는 기업 개발 모델 에 대해 HTTP 인터페이스 개발, 즉 우리 가 흔히 말 하 는 RESTful 스타일 의 서비스 인터페이스 로 규정 해 왔 습 니 다.확실히 인터페이스 가 많 지 않 고 시스템 과 시스템 의 상호작용 이 비교적 적은 상황 에서 정보 고도 초기 에 자주 사 용 했 던 통신 수단 을 해결한다.장점 은 간단 하고 직접적 이 며 개발 이 편리 하 다 는 것 이다.기 존의 http 프로 토 콜 을 이용 하여 전송 합 니 다.우 리 는 예전 에 학부 실습 이 회사 에서 백 스테이지 개발 을 할 때 주로 인터페이스의 개발 을 했 고 인터페이스 문 서 를 크게 써 서 입 출력 이 무엇 인지 엄 격 히 표시 해 야 한 다 는 것 을 기억 합 니 다.모든 인터페이스의 요청 방법 과 요청 매개 변수 가 주의해 야 할 사항 등 을 분명히 말 하 세 요.예 를 들 어 다음 예: POST http://www.httpexample.com/restful/buyer/info/share 인 터 페 이 스 는 JSON 문자열 이나 XML 문 서 를 되 돌려 줄 수 있 습 니 다.그리고 클 라 이언 트 가 이 되 돌아 오 는 정 보 를 처리 하면 비교적 신속하게 개발 할 수 있다.그러나 대기업 의 경우 내부 시스템 이 많 고 인터페이스 가 매우 많은 상황 에서 RPC 프레임 워 크 의 장점 이 나타난다. 먼저 긴 링크 이다. 매번 통신 할 때마다 http 처럼 세 번 악 수 를 하지 않 아 도 되 고 네트워크 비용 을 줄 일 수 있다.그 다음으로 RPC 프레임 워 크 는 일반적으로 등록 센터 가 있 고 풍부 한 모니터링 관리 가 있다.발표, 오프라인 인터페이스, 동적 확장 등 은 호출 자 에 게 감지 되 지 않 고 통일 화 된 조작 이 라 고 할 수 있다.
총결산
RPC 서비스 와 HTTP 서 비 스 는 아직도 많은 차이 점 이 존재 한다. 일반적으로 RPC 서 비 스 는 주로 대형 기업 을 대상 으로 하 는 것 이 고 HTTP 서 비 스 는 주로 소기 업 을 대상 으로 하 는 것 이다. RPC 효율 이 높 고 HTTP 서비스 개발 의 교체 가 빠 르 기 때문이다.한 마디 로 하면 어떤 구 조 를 선택 하 느 냐 는 시장 에서 유행 하 는 것 에 따라 결정 되 는 것 이 아니 라 전체 프로젝트 에 대해 완전한 평 가 를 하고 두 가지 개발 구조 가 전체 프로젝트 에 미 친 영향 을 자세히 비교 한 다음 에 무엇이 이 프로젝트 에 가장 적합 한 지 결정 해 야 한다.RPC 를 사용 하기 위해 모든 항목 에 RPC 를 사용 하지 말고 지역 에 맞 게 구체 적 인 상황 을 구체 적 으로 분석 해 야 한다.