목차
공식 주소 : https://dubbo.apache.org/zh/
Dubbo는 SpringXML 구성 및 클라이언트 구성을 지원합니다. 레지스트리는 Zookeeper 및 Redis를 지원합니다. 기본 레지스트리는 Zookeeper입니다. 최신 버전은 2.7이며 3.0은 개발 중입니다.
배경
이 기사에서는 웹 사이트 애플리케이션의 진화를 소개합니다.
인터넷의 발달로 웹 사이트 애플리케이션의 규모가 계속 확장되고 기존의 수직 애플리케이션 아키텍처는 더 이상 이에 대처할 수 없습니다. 분산 서비스 아키텍처와 모바일 컴퓨팅 아키텍처가 필수적이며 질서있는 진화를 보장하기 위해 거버넌스 시스템이 시급히 필요합니다. 건축의.
단일 애플리케이션 아키텍처
웹 사이트 트래픽이 매우 적을 때 하나의 애플리케이션 만 필요하고 모든 기능이 함께 배포되어 배포 노드와 비용이 절감됩니다. 이때 추가, 삭제, 수정 및 확인 작업을 단순화하는 데 사용되는 데이터 액세스 프레임 워크 (ORM)가 핵심입니다.
수직 애플리케이션 아키텍처
방문 횟수가 점진적으로 증가하면 단일 애플리케이션을 머신에 추가함으로써 발생하는 가속도는 점점 더 작아지고 효율성을 높이는 방법 중 하나는 애플리케이션을 관련없는 여러 애플리케이션으로 분할하여 효율성을 높이는 것입니다. 이때 프론트 엔드 페이지 개발을 가속화하는 데 사용되는 웹 프레임 워크 (MVC)가 핵심입니다.
분산 서비스 아키텍처
수직적 애플리케이션이 많아지면 애플리케이션 간의 상호 작용이 불가피하며, 핵심 비즈니스는 독립적 인 서비스로 추출되고 안정적인 서비스 센터가 점차 형성되어 프론트 엔드 애플리케이션이 변화하는 시장 요구에보다 빠르게 대응할 수 있습니다. 이때 비즈니스 재사용 및 통합을 개선하기위한 분산 서비스 프레임 워크 (RPC)가 핵심입니다.
모바일 컴퓨팅 아키텍처
서비스가 늘어날수록 용량 평가 및 소규모 서비스 자원 낭비 등의 문제가 점차 나타나고 있으며, 이때 클러스터 활용도를 높이기 위해서는 접속 압력에 따라 실시간으로 클러스터 용량을 관리 할 수있는 디스패치 센터를 추가해야합니다. 이때 머신 활용도를 높이는 데 사용되는 리소스 스케줄링 및 거버넌스 센터 (SOA)가 핵심입니다.
수요
이 기사에서는 Dubbo가 해결하고자하는 요구 사항을 소개합니다.
대규모 서비스 이전에 애플리케이션은 RMI 또는 Hessian과 같은 도구를 통해 원격 서비스를 간단히 노출 및 참조하고, 서비스의 URL 주소를 구성하여 호출하고, F5와 같은 하드웨어를 통해 부하 분산을 수행 할 수 있습니다.
서비스가 많아지면 서비스 URL 구성 관리가 매우 어려워지고 F5 하드웨어로드 밸런서의 단일 지점 압력도 증가합니다. 이때 서비스의 위치를 투명하게 만들기 위해 서비스를 동적으로 등록하고 검색하는 서비스 등록 센터가 필요합니다. 또한 소비자 측에서 서비스 제공 업체 주소 목록을 확보함으로써 소프트로드 밸런싱 및 장애 조치를 달성하고 F5 하드웨어로드 밸런서에 대한 의존도를 줄이고 비용의 일부를 줄일 수 있습니다.
추가 개발시 서비스 간의 종속성이 잘못 추적되고 복잡해지며 어떤 응용 프로그램이 어떤 응용 프로그램보다 먼저 시작되어야하는지도 불분명합니다. 아키텍트는 응용 프로그램의 아키텍처 관계를 완전히 설명 할 수 없습니다. 이때 아키텍트가 관계를 명확히 할 수 있도록 애플리케이션 간의 종속성 그래프를 자동으로 그려야합니다.
그러면 서비스에 대한 호출이 점점 더 많아지고 서비스 용량의 문제가 드러납니다.이 서비스는 얼마나 많은 기계 지원이 필요합니까? 기계를 언제 추가해야합니까? 이러한 문제를 해결하기위한 첫 번째 단계는 서비스의 일일 통화량과 응답 시간을 용량 계획의 참조 지표로 계산하는 것입니다. 둘째, 동적으로 가중치를 조정해야합니다. 온라인으로 특정 기계의 가중치를 높이고 증가 과정에서 응답 시간의 변화를 기록하고 응답 시간이 임계 값에 도달 할 때까지 이때 방문 횟수를 기록하고, 그런 다음 이것을 사용하여 방문 수에 컴퓨터 수를 곱하여 총 용량을 되돌립니다.
위는 Dubbo의 가장 기본적인 요구 사항입니다.
건축물
더보 아키텍처
노드 역할 설명
| 마디 | 역할 설명 |
|---|---|
Provider |
서비스를 노출하는 서비스 제공자 |
Consumer |
원격 서비스를 호출하는 서비스 소비자 |
Registry |
서비스 등록 및 검색을위한 레지스트리 |
Monitor |
서비스 호출 횟수와 호출 시간을 세는 모니터링 센터 |
Container |
서비스 실행 컨테이너 |
통화 관계 설명
- 서비스 컨테이너는 서비스 제공자의 시작,로드 및 실행을 담당합니다.
- 서비스 제공자가 시작하면 등록 센터에 제공하는 서비스를 등록합니다.
- 서비스 소비자가 시작되면 필요한 서비스에 대한 레지스트리를 구독합니다.
- 등록 센터는 서비스 제공자 주소 목록을 소비자에게 반환합니다. 변경 사항이있는 경우 등록 센터는 긴 연결을 기반으로 변경 데이터를 소비자에게 푸시합니다.
- 서비스 소비자는 소프트로드 밸런싱 알고리즘에 따라 공급자 주소 목록에서 호출 할 공급자를 하나 선택하고 호출이 실패하면 다른 공급자를 선택하여 호출합니다.
- 서비스 소비자와 공급자는 통화 횟수와 통화 시간을 메모리에 누적하고 1 분마다 모니터링 센터에 통계 데이터를 보냅니다.
Dubbo 아키텍처에는 연결성, 견고성, 확장 성 및 미래 아키텍처로의 업그레이드 가능성과 같은 특성이 있습니다.
연결성
- 등록 센터는 디렉토리 서비스에 해당하는 서비스 주소의 등록 및 검색을 담당합니다. 서비스 공급자와 소비자는 시작시 등록 센터와 만 상호 작용하고 등록 센터는 요청을 전달하지 않으므로 부담이 적습니다.
- 모니터링 센터는 각 서비스가 호출 된 횟수, 호출 시간 등을 계산합니다. 통계는 메모리에 먼저 수집되어 1 분마다 모니터링 센터 서버로 전송되고 보고서에 표시됩니다.
- 서비스 제공자는 등록 센터에 제공하는 서비스를 등록하고 감시 센터에 통화 시간을보고합니다.이 시간에는 네트워크 오버 헤드가 포함되지 않습니다.
- 서비스 소비자는 등록 센터에서 서비스 제공자 주소 목록을 가져 와서로드 알고리즘에 따라 제공자에게 직접 전화를 걸고 동시에 감시 센터에 호출 시간을보고합니다.이 시간에는 네트워크 오버 헤드가 포함됩니다.
- 등록 센터, 서비스 공급자 및 서비스 소비자는 모니터링 센터를 제외하고 모두 수명이 긴 연결입니다.
- 레지스트리는 긴 연결을 통해 서비스 공급자의 존재를 인식하고 서비스 공급자가 다운되면 레지스트리는 즉시 이벤트를 푸시하여 소비자에게 알립니다.
- 등록 센터와 모니터링 센터가 모두 다운되어 이미 실행중인 공급자와 소비자에게 영향을주지 않습니다. 소비자는 공급자 목록을 로컬로 캐시합니다.
- 등록 센터와 모니터링 센터는 모두 선택 사항이며 서비스 소비자는 서비스 공급자에 직접 연결할 수 있습니다.
견고 함
- 모니터링 센터의 가동 중지 시간은 사용에 영향을 미치지 않지만 일부 샘플링 데이터가 손실됩니다.
- 데이터베이스가 다운 된 후에도 레지스트리는 여전히 캐시를 통해 서비스 목록 쿼리를 제공 할 수 있지만 새 서비스를 등록 할 수는 없습니다.
- 등록 센터 피어-투-피어 클러스터, 하나가 다운되면 자동으로 다른 클러스터로 전환됩니다.
- 레지스트리가 완전히 다운 된 후에도 서비스 공급자와 서비스 소비자는 여전히 로컬 캐시를 통해 통신 할 수 있습니다.
- 서비스 제공 업체는 상태 비 저장 상태이므로 서비스 제공 업체가 다운 된 후에도 사용에 영향을주지 않습니다.
- 서비스 공급자가 모두 다운되면 서비스 소비자 응용 프로그램을 사용할 수 없으며 무기한 다시 연결되고 서비스 공급자가 복구 될 때까지 기다립니다.
확장 성
- 레지스트리는 머신 배포 인스턴스를 동적으로 추가 할 수있는 피어 투 피어 클러스터이며 모든 클라이언트가 자동으로 새 레지스트리를 검색합니다.
- 서비스 공급자는 상태 비 저장이며 머신 배포 인스턴스를 동적으로 추가 할 수 있으며 레지스트리는 새로운 서비스 공급자 정보를 소비자에게 푸시합니다.
업그레이드 가능성
서비스 클러스터의 규모가 더욱 확대되고 IT 거버넌스 구조가 더욱 업그레이드되면 동적 배포와 모바일 컴퓨팅이 필요하며 기존 분산 서비스 아키텍처는 저항을 가져 오지 않습니다. 다음 그림은 향후 가능한 아키텍처입니다.
노드 역할 설명
| 마디 | 역할 설명 |
|---|---|
Deployer |
자동 배포 서비스를위한 로컬 에이전트 |
Repository |
웨어 하우스는 서비스 응용 프로그램 릴리스 패키지를 저장하는 데 사용됩니다. |
Scheduler |
디스패치 센터는 액세스 압력에 따라 서비스 공급자를 자동으로 늘리거나 줄입니다. |
Admin |
통합 관리 콘솔 |
Registry |
서비스 등록 및 검색을위한 레지스트리 |
Monitor |
서비스 호출 횟수와 호출 시간을 세는 모니터링 센터 |
용법
Dubbo에 대한 간단하고 실용적인 소개
로컬 서비스 Spring 구성
local.xml :
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
<property name=“xxxService” ref=“xxxService” />
</bean>
원격 서비스 Spring 구성
로컬 서비스를 기반으로 원격을 완료하려면 간단한 구성 만 수행하면됩니다.
- 위의
local.xml구성을 두 부분으로 분할하고 서비스 공급자에 서비스 정의 부분을remote-provider.xml배치하고 서비스 소비자에 서비스 참조 부분을 배치합니다remote-consumer.xml. - 그리고 공급자 측에서 노출 된 서비스 구성을
<dubbo:service>늘리고 소비자 측에서 참조 서비스 구성을 늘리십시오<dubbo:reference>.
remote-provider.xml :
<!-- 和本地服务一样实现远程服务 -->
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />
<!-- 增加暴露远程服务配置 -->
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” />
remote-consumer.xml :
<!-- 增加引用远程服务配置 -->
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” />
<!-- 和本地服务一样使用远程服务 -->
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
<property name=“xxxService” ref=“xxxService” />
</bean>