여기서는 크게 네 부분으로 구성됩니다.
● 공급자: 서비스를 노출하는 서비스 공급자
프로토콜: 공급자와 공급자를 담당합니다. 소비자 공급자 간의 프로토콜 상호 작용 데이터
서비스: 인터페이스와 구현으로 이해될 수 있는 실제 비즈니스 서비스 정보
컨테이너: Dubbo의 운영 환경
● 소비자: 원격 서비스를 호출하는 서비스 소비자
프로토콜: 공급자와 공급자 간의 관계를 담당
클러스터: 공급자 측 목록 정보를 인식하는 소비자 프로토콜 상호 작용 데이터
프록시: 소비자의 인터페이스 호출 로직을 대신하는 공급자의 서비스 호출 프록시로 이해될 수 있습니다.
● 레지스터: 등록 센터, 다음 용도로 사용됩니다. 서비스 검색 및 라우팅 구성 및 기타 작업, 공급자 및 소비자가 여기에 등록됩니다
● 모니터: 호출 빈도, 성공 및 실패 횟수 등 공급자와 소비자에 대한 데이터 통계에 사용됩니다.
● 공급자 측이 시작되고, 컨테이너는 서비스 정보를 로드하고 프로토콜을 통해 등록 센터에 등록하는 역할을 담당합니다.
● 소비자 측이 시작되고, 공급자 목록을 듣고 공급자 정보를 감지합니다. 공급자가 변경되면 적시에 등록 센터를 통해 통보됩니다. 소비자에게 알림
● 소비자는 프록시 모듈을 통해 요청을 시작합니다.
● 소비자는 호출할 실제 공급자를 선택하기 위해 클러스터 모듈을 사용합니다. 소비자는 소비자의 프로토콜을 사용하여 공급자에게 정보를 보냅니다.
● 소비자 정보는 프로토콜 모듈을 통해 처리됩니다.
● 마지막으로 공급자의 서비스에 의해 처리됩니다.
전체 호출 과정은 다음과 같습니다.
● 소비자는 인터페이스를 통해 수행합니다. 메소드 호출은 소비자 측에서 Proxy로 균일하게 전달되고 ProxyFactory를 통해 프록시 객체가 생성됩니다. 여기에서 jdk의 기술이 사용됩니다● 필터 모듈에 넘겨져 통합 필터링 요청을 합니다
● 다음으로 가장 중요한 Invoker 호출 로직
○ Directory를 통해 구성 정보를 읽고, 최종적으로 list 메소드를 통해 모든 Invoker를 얻습니다
○ Cluster 모듈을 통해 선택한 특정 라우팅 규칙에 따라 Invoker 목록 선택
○ LoadBalance 모듈을 통해 로드 밸런싱 정책에 따라 특정 Invoker 선택 요청 처리
○ 실행 중 오류가 발생하면 재시도 메커니즘 Consumer 단계에서 구성되면 실행이 재시도됩니다
● 계속해서 Filter를 통과하여 실행 기능 전후를 캡슐화하고 Invoker는 특정 실행 프로토콜을 선택합니다
● 클라이언트는 인코딩 및 시퀀싱을 수행한 후 데이터
● 제공자의 서버 계층에 도달하여 수신된 데이터를 디코딩하고 직렬화
● 내보내기를 사용하여 실행자를 선택
● 필터가 제공자 측 필터링을 수행하고 호출자 실행자에 도달
● 패스 호출자가 특정 구현을 호출 3. Dubbo의 전체적인 디자인
범례 설명 :
● 사진에서 왼쪽 연한 파란색 배경은 서비스 소비자가 사용하는 인터페이스이며, 오른쪽의 밝은 녹색 배경은 서비스 제공자가 사용하는 인터페이스입니다. 중앙 축에 있는 인터페이스는 양쪽에서 사용됩니다. ● 그림은 위에서 아래로 10개의 레이어로 나누어져 있습니다. 오른쪽의 검은색 화살표는 레이어 간의 종속 관계를 나타내며 서비스와 재사용이 가능합니다. 구성 레이어는 API이고, 다른 모든 레이어는 SPI입니다.
● 그림의 녹색 블록은 확장 인터페이스이고, 파란색 블록은 각 레이어를 연결하는 데 사용되는 구현 클래스만 보여줍니다.● 그림의 파란색 점선은 그림은 초기화 프로세스입니다. 즉, 시작 시 어셈블리 체인입니다. 빨간색 실선은 런타임 호출 체인입니다. 하위 클래스는 상속입니다. 해당 줄의 텍스트는 호출 메서드입니다.
Dubbo 소스 코드의 전체적인 디자인은 호출 링크와 매우 유사합니다. 그러나 여기서는 인터페이스의 일부 특정 구현과 왼쪽의 보다 자세한 계층적 구분을 볼 수 있으며, 후속 소스 코드 분석에서 더 중요한 모듈 구현에 중점을 둘 것입니다.
다음은 레이어에서 소개됩니다
1. 비즈니스 로직 레이어
● 서비스 비즈니스 레이어: 인터페이스 및 구현 클래스와 같은 비즈니스 코드 포함
2. RPC 레이어: 원격 프로시저 호출 레이어
● ServiceConfig 및 ReferenceConfig를 사용하여 외부 세계에 구성을 제공합니다. 핵심에서는 구성 클래스를 직접 초기화하고 구성 파일을 구문 분석할 수도 있습니다.
● 프록시 서비스 프록시 계층은 생산자이든 소비자이든 관계없이 전체 프로세스가 상위 계층에 투명합니다. , 비즈니스 레이어는 원격 호출에 무관심
● 등록 등록 센터 레이어, 서비스 URL을 중심으로 서비스 주소 등록 및 검색을 캡슐화
● 클러스터 라우팅 레이어(클러스터 내결함성 레이어), 여러 개의 라우팅 및 로드 밸런싱 제공 Invoker를 중심으로 등록 센터를 연결합니다.
● 모니터 모니터링 레이어, 호출 횟수, 실패 상황, 호출 시간, 기타 통계 정보 등 RPC 호출과 관련된 정보가 이 레이어에서 수집됩니다. 프로토콜 원격 호출 계층은 서비스 노출이든 서비스 참조이든 RPC 호출을 캡슐화하며 프로토콜의 주요 기능 입구이며 Dubbo의 모든 모델은 Invoker
3에 더 가깝습니다. : 원격 데이터 전송 계층
● 요청 및 응답 모드를 캡슐화하고 요청을 동기식에서 비동기식으로 변환하는 교환 정보 교환 계층
● 전송 네트워크 전송 계층은 Netty 및 mina와 같은 네트워크 전송 인터페이스를 하나의 네트워크 전송 인터페이스로 통합합니다
● 전체 프레임워크에서 데이터 전송의 직렬화 및 역직렬화를 관리하는 직렬화 데이터 직렬화 계층 Change
위 내용은 Java Dubbo 아키텍처의 전반적인 설계 방식은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!