dubbo의 본질: Jar 패키지, 분산 프레임워크, 원격 서비스 호출을 위한 분산 프레임워크.
1) 초보자를 위한 튜토리얼이기 때문에 분산 및 원격 서비스 호출이 무엇인지, 왜 분산 호출이 필요한지, 원격 호출이 필요한 이유를 이해하지 못하는 학생들이 많을 것입니다. 설명을 위해 간단히 비교표를 그려보겠습니다(그림 2의 그림 1 참조. 화판에 그린 것이므로 뿌리지 마십시오).
생각해보면 예전에는 모든 것이 같은 서버에 있었고 호출 방식도 직접적이고 자연스럽게 호출되어 문제가 없었습니다. 이제 수요 증가로 인해 많은 수가 분할되어 다른 서버에 배포되었습니다. 이전에 비해 모두 하나의 서버에 분산되었으므로 서비스 계층 서비스를 호출하는 웹 계층이 있습니까? 원격 통화가 되나요? 그렇다면 이전과 동일한 서버에서 어떻게 자연스럽게 메소드를 호출할 수 있을까요? dubbo가 해결해 드립니다. 아래는 더보의 장점입니다.
1. 로컬 메서드 호출과 마찬가지로 투명한 원격 메서드 호출에는 간단한 구성이 필요하며 API 침입이 필요하지 않습니다.
2. 소프트 로드 밸런싱 및 내결함성 메커니즘은 인트라넷의 F5와 같은 하드웨어 로드 밸런서를 대체하여 비용과 단일 포인트를 줄일 수 있습니다.
3. 자동 서비스 등록 및 검색은 더 이상 서비스 제공자 주소를 하드 코딩할 필요가 없습니다. 등록 센터는 인터페이스 이름을 기반으로 서비스 제공자의 IP 주소를 쿼리하고 서비스 제공자를 원활하게 추가하거나 삭제할 수 있습니다. (아래에 설명됨)
Dubbo는 애플리케이션에 투명하게 액세스하기 위해 전체 Spring 구성 방법을 사용합니다. Spring의 스키마 확장을 기반으로 Dubbo의 구성을 로드하려면 Spring만 사용하면 됩니다.
그의 아키텍처 다이어그램을 설명하기 전에 몇 가지 개념을 대중화해 보겠습니다.
노드 역할 설명:
공급자(생산자): 서비스를 노출하는 서비스 공급자.
Consumer: 원격 서비스를 호출하는 서비스 소비자입니다.
그림에 표시된 것처럼 web1234는 service1234의 서비스를 호출해야 하므로 web1234가 소비자이고 service1234가 생산자라는 것을 간단히 이해할 수 있습니다.
그러면 위의 내용에 따라 소비자가 생산자의 서비스를 호출하면 다음 그림과 같이 나오나요?
보면 어지러우신가요? 희미한가 아닌가? 희미한가 아닌가? 암튼 어지러웠는데, 좀 더 퍼트리면 어떡하지? , 그래서 우리는 그가 필요합니다:
Registry(등록 센터): 서비스 등록 및 검색을 위한 등록 센터입니다. Dubbo는 사육사를 추천합니다. 사육사는 무엇입니까? Zookeeper는 분산 시스템의 일관성 처리를 위한 프레임워크입니다. 자세한 내용은 이전 기사를 참조하세요. 이렇게 표현하면 ZooKeeper는 실제로 프레임워크이며 일관성 처리에 사용됩니다. 쉽게 말하면, ZooKeeper는 부동산 판매자(생산자)가 부동산 정보를 중개자(등록센터)에 올려주고, 부동산을 사고자 하는 사람(소비자)이 중개자로 가서 부동산 자원 목록을 얻는 것입니다. 그래서 우리의 그림은 다음과 같습니다:
훨씬 낫지 않나요? 부족하다면 모니터링 센터도 필요합니다. (무엇을 위해 사용하나요? 물론 모니터링을 위한 것입니다. 통화가 실패하면 어떻게 해야 하나요? 끊기면 어떻게 해야 하나요?): 모니터: 중요한 모니터링 센터 통화 횟수 및 서비스 통화 시간. (더 이상 그리지 않음)
그런 다음 Provider가 컨테이너에서 실행되는데, 이를 컨테이너 서비스라고 하며 컨테이너를 실행합니다. (더 이상 그리지 않음)
그림과 같은 최종 더보 아키텍처(0부터 시작):
관련 권장 사항:
Taobao Amoeba 아키텍처 MySQL 분산 데이터베이스 환경_MySQL
하루 평균 100개 WanPV 아키텍처의 네 번째 버전(분산 모니터링)_MySQL
위 내용은 더보+조키퍼 기본 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!