자, 이전 기사의 에세이에 대해 계속 이야기 해 봅시다. 이전 기사에서는 모든 마이크로 서비스 구성을 업데이트하고 다시 시작하지 않고 구성을 업데이트하려면 Spring Cloud 구성에만 의존 할 수 있다고 언급했습니다. 그러나 한 서비스에서 다른 서비스에서 게시물 요청을 보내야합니다.
우리는 그것을 견딜 수 있습니까? 이것은 이전 구성 센터의 이전 부족보다 훨씬 낫습니다. 그렇다면 서비스에 정보를 제공하기 위해 사후 요청을 서비스에 하나씩 발송하는 방법을 어떻게 계속 피할 수 있습니까? 구성 정보가 변경되었으며 제 시간에 메모리에서 구성 정보를 수정해야합니다.
현재 메시지 대기열의 게시 구독 모델을 잊어서는 안됩니다. 모든 서비스는이 이벤트를 구독합니다. 이 이벤트가 변경되면 모든 마이크로 서비스에 메모리 구성 정보를 업데이트하도록 알릴 수 있습니다. 현재 버스 메시지 버스가 해결할 수 있습니다. 모든 마이크로 서비스 업데이트를 트리거하려면 SpringCloud Config 서버 측에서 새로 고침 만 발행하면됩니다.
다음 아키텍처 다이어그램에서 볼 수 있듯이 :
Spring Cloud Bus는 RabbitMQ의 자동 구성을 지원하는 것 외에도 현재 널리 사용되는 Kafka도 지원합니다. 이 기사에서는 Kafka 지역 환경을 구축하고 Spring Cloud Bus를 사용하여 Kafka를 지원하여 메시지 버스의 기능을 구현하는 데 사용합니다.
Kafka는 Scala를 사용하여 구현되며 LinkedIn의 활성 스트리밍 및 운영 데이터 처리를위한 파이프 라인으로 사용되며 현재 많은 인터넷 회사에서 데이터 스트리밍 파이프 라인 및 메시지 시스템으로 널리 사용됩니다.
Kafak 아키텍처 다이어그램은 다음과 같습니다.
Kafka는 메시지 게시/구독 모드를 기반으로 구현 된 메시징 시스템입니다. 주요 디자인 목표는 다음과 같습니다.
1. 메시지 지속성 : 시간 복잡성 O (1)에 메시지 지속성 기능을 제공하며 TB 수준 이상의 데이터조차도 일정한 시간 복잡성으로 액세스 성능을 보장 할 수 있습니다.
2. 높은 처리량 : 저렴한 상용 기계에서 초당 100k 이상의 처리량을 지원할 수 있습니다.
3. 분산 : 지원 메시지 파티셔닝 및 분산 소비, 파티션 내 메시지 순서를 보장합니다.
4. 크로스 플랫폼 : 다양한 기술 플랫폼 (예 : Java, PHP, Python 등)을 가진 고객을 지원합니다.
5. 실시간 : 실시간 데이터 처리 및 오프라인 데이터 처리 지원
6. 확장 성 : 수평 확장을 지원합니다
Kafka와 관련된 몇 가지 기본 개념 :
1. 브로커 : Kafka 클러스터에는 브로커라고하는 하나 이상의 서버가 포함되어 있습니다.
2. Topic : 논리적으로 Rabbit의 대기열 대기열과 유사하며 Kafka 클러스터에 게시 된 각 메시지에는 주제가 있어야합니다. (다른 주제가 다른 메시지는 별도로 저장됩니다. 주제의 논리적 메시지는 하나 이상의 브로커에 저장되지만 사용자는 데이터가 저장된 위치에 대한 관심을 가지지 않고 데이터를 생성하거나 소비하기 위해 메시지의 주제를 지정하면됩니다.
3. 파티션 : 파티션은 물리적 개념의 파티션입니다. 시스템 처리량을 제공하기 위해 각 주제는 물리적으로 하나 이상의 파티션으로 나뉘며 각 파티션은 폴더 (해당 파티션의 메시지 내용 및 색인 파일 저장)에 해당합니다.
4. 프로듀서 : 메시지 제작자, 메시지 제작 및 Kafka Broker로 보내는 책임.
5. 소비자 : 메시지 소비자, Kafka 브로커에게 메시지를 읽고 처리하는 클라이언트.
6. 소집기 그룹 : 각 소비자는 특정 그룹에 속합니다 (각 소비자는 그룹으로 지정할 수 있으며 지정되지 않으면 기본 그룹에 속함). 이 그룹은 그룹의 여러 회원이 소비하는 메시지와 같은 기능을 구현하는 데 사용될 수 있습니다.
Kafka 아키텍처 다이어그램에서 Kafka는 Zookeeper 지원이 필요하다는 것을 알 수 있습니다. Zookeeper가 Kafka 구성의 위치를 지정해야합니다. Zookeeper를 통해 몇 가지 신뢰성 보장을 제공하며 중개인의 마스터이자 노예입니다. 또한 Kafka 메시지가 주제 형식으로 구성되어 있음을 알아야합니다. 생산자는 주제 양식 메시지를 보내고 소비자는 그룹에 따라 나뉘어 지므로 소비자 그룹은 모두 동일한 주제 양식 메시지가 필요합니다. 서버 측면에서는 일부 파편을 만들기 때문에 주제가 다른 파편에 배포 될 수 있으므로 여러 시스템을 확장하고 배포 할 수 있습니다. 카프카는 자연스럽게 분포되어 있습니다. 여기에서 데모를 위해 기본 구성 만 사용하고 Windows에서 작은 데모를 만들면됩니다.
우리는 주로 메시지 버스의 기능을 구현하는 Kafka의 Spring Cloud Bus의 지원에 중점을 둡니다. 특정 Kafka 및 RabbitMQ 메시지 대기열의 경우 직접 배울 정보를 찾기를 바랍니다. 일부 개념 지원을 통해 우리는 데모를합니다.
다음과 같이 : 먼저, 테스트를 용이하게하기 위해 새로운 SpringCloud-Config-Client1 모듈을 작성하십시오. 소개 된 종속성은 다음과 같습니다.
<pectionency> <groupId> org.springframework.boot </groupid> <artifactid> 스프링-부트-스타터-승인기 </artifactid> </dependency> <groupid> org.springframework.boot </groupid> <artifactid> spring-boot-starter-web </arepifactid> <groupid> org.springframework.cloud </groupid> <artifactid> spring-cloud-starter-config </artifactid> <bersion> 1.4.0. release </version> </dependency> <groupid> org.springframwork.cloud </groupid> <artifactid> spring-cloudtarter- </arricefactid> <버전> 1.3.5. release </version> </dependency> <pectionement> <groupId> org.springframework.cloud </groupid> <artifactid> Spring-Cloud-Starter-Bus-Kafka </artifactid> <버전> 1.3.2. Release </version> </dependency>
다음으로 Client1의 구성 파일은 Bootstrap.yml로 변경되어야합니다.이 구성 형식이 선호되기 때문입니다. 이전 에세이에서 언급했듯이 Client1의 구성은 다음과 같습니다.
서버 : 포트 : 7006Spring : 응용 프로그램 : 이름 : Cloud-Config Cloud : Config :#시작하는 데 사용되는 환경은 무엇입니까? Dev는 개발 환경을 나타냅니다. 이것은 창고에있는 파일의 접미사와 관련이 있습니다. 예를 들어, 창고 구성 파일의 이름 지정 형식은 Cloud-Config-Dev.Properties이므로 프로필은 DEV 프로필을 작성해야합니다. DEV Discovery : Enabled : True#이 이름은 Config Server 측의 서비스 이름이며 맹목적으로 쓸 수 없습니다. Service-ID : Config-Server#Register Center Eureka : Client : Service-URL : DefaultZone : http : // localhost : 8888/eureka/, http : // localhost : 8889/eureka/#권한을 가져와야합니까? 기본값은 사실입니다. False가없는 경우 구성 센터 서버 관리에서 업데이트 된 컨텐츠를 가져올 수 없습니다 : 보안 : 활성화 : False
그런 다음 다음과 같이 수업을 시작하십시오.
@springbootApplication@enablediscoveryClientPublic class client1application {public static void main (String [] args) {springApplication.Run (client1Application.class, args); }}그런 다음 클라이언트의 TestController 사본을 Client1에 할당하면 코드는 다음과 같습니다.
@restcontroller // 여기의 속성이 업데이트 될 수 있습니다. GIT의 구성 센터가 변경되면 새로 고침해야합니다. 이 주석이 없으면 구성을 시간 @RefreshScopePublic 클래스 TestController {@Value ( "$ {name}") 개인 문자열 이름으로 업데이트 할 수 없습니다. @Value ( "$ {age}") 개인 정수 시대; @requestmapping ( "/test") public string test () {return this.name+this.age; }}그런 다음 이전 에세이의 모듈의 구성 서버에 다음 구성을 추가하십시오.
#이 허가를 받아야 할 권한이 필요하고 기본값은 사실입니다. False가없는 경우 구성 센터 서버 관리에서 업데이트 된 컨텐츠를 가져올 수 없습니다 : 보안 : 활성화 : False
다음으로, Config-Client, Config-Client1 및 Config-Server는 다음과 같이 Kafka 종속성을 소개해야합니다.
<pectionency> <groupid> org.springframework.cloud </groupid> <artifactid> Spring-Cloud-Starter-Bus-Kafka </artifactid> <3.3.2. Release </version> </dependency>
우리 프로젝트는 준비되어 있으므로 당분간 여기에 넣을 것입니다. 아래에 Kafka를 설치하고 다운로드합시다. 먼저 Kafka 공식 웹 사이트 kafka.apache.org/downloads로 이동하여 공식 웹 사이트의 권장 버전으로 이동합니다.
먼저, 다운로드 된 Kafka 디렉토리를 입력하고 Kafka_2.11-1.1.0/bin/wind
이 구성을 다음과 같이 찾으십시오.
코드를 다음과 같이 복사하십시오.
% classPath %에는 이중 인용문이 없음을 알 수 있습니다.
따라서 이중 인용구로 둘러싸고 그렇지 않으면 시작할 수 없습니다. JDK가 제대로 설치되지 않은 것으로보고됩니다. 수정 후 다음과 같습니다.
코드를 다음과 같이 복사하십시오.
그런 다음 구성 폴더에서 Server.Properties를 열고 다음과 같이 구성하십시오.
당신은 그것이 지역 동물원 키퍼와 연결되어 있음을 알 수 있습니다.
그런 다음 다음과 같이 먼저 Zookeeper를 시작한 다음 Kafka를 시작합니다.
위의 정보를 볼 때 Zookeeper의 스타트 업이 성공했음을 증명합니다. ,,,
다음으로 다음과 같이 다른 CMD로 Kafka를 시작하십시오.
이 정보를 보는 것은 Kafka가 성공적으로 시작되었음을 의미합니다.
자, 이전 프로젝트, 2 개의 등록 센터, 하나의 SpringCloud-Config-Server, 2 개의 SpringCloud-Config-Client 및 SpringCloud-Config-Client1을 시작하겠습니다.
SpringCloudbus가 0 샤드에 있음을 알 수 있습니다. 위의 정보가 두 config-clients에 모두 나타나면 시작이 성공했음을 증명합니다.
자, 이제 다음과 같이 구성 서버 측에 액세스 해 봅시다.
다음과 같이 두 명의 고객을 더 방문하십시오.
좋아요, 쇼가 시작되었습니다. 이제 우리는 Git 리포지토리로 이동하여 구성 센터 파일을 수정하고 다음과 같이 나이를 24로 변경합니다.
다음으로 새로 고침을 사용하여 구성 서버 구성을 새로 고치고 두 클라이언트에게 메모리의 구성 정보를 업데이트하도록 알립니다. Postman을 사용하여 LocalHost : 7000/Bus/Reshend를 보내십시오.
정보가 반환되지 않지만 걱정하지 않음을 알 수 있습니다. 이것은 모든 고객에게 메모리에서 정보를 업데이트 할 수있는 성공적인 알림입니다.
그런 다음 Config-Server와 두 명의 클라이언트를 다시 요청하여 페이지를 새로 고치고 결과는 다음과 같습니다.
두 클라이언트는 다음과 같습니다.
모든 클라이언트가 메모리에서 구성 정보를 자동으로 업데이트하는 것을 볼 수 있습니다.
지금까지 위의 부분은 구성 정보를 새로 고쳤습니다. 특정 서비스의 구성 정보를 새로 고치려면 괜찮습니다. 다음과 같이 새로 고침 범위를 지정할 수 있습니다.
새로 고침 범위를 지정합니다
위의 예에서는 서비스 인스턴스에서 스프링 클라우드 버스 /bus/refresh 인터페이스를 요청하여 버스의 다른 서비스 인스턴스를 트리거 /refresh . 그러나 일부 특별한 시나리오 (예 : Grayscale 릴리스)에서는 마이크로 서비스에서 특정 인스턴스의 구성을 새로 고치기를 희망합니다.
Spring Cloud Bus는 또한이 시나리오를 지원합니다. /bus/refresh 인터페이스는 또한 destination 매개 변수를 제공하여 새로 고칠 특정 응용 프로그램을 찾습니다. 예를 들어, /bus/refresh?destination=服务名字:9000 요청할 수 있습니다. 현재 버스의 각 응용 프로그램 인스턴스는 destination 속성의 값에 따라 자체 인스턴스 이름인지 여부를 결정합니다.
구성이 충족되면 구성이 새로 고침됩니다. 구성이 일치하지 않으면 메시지가 무시됩니다.
특정 인스턴스를 포지셔닝하는 것 외에도 destination 매개 변수를 사용하여 특정 서비스를 배치 할 수도 있습니다. 포지셔닝 서비스의 원칙은 Spring 's Pathmatecher customers 사용하여 구현됩니다 /bus/refresh?destination=customers:**
위는이 기사의 모든 내용입니다. 모든 사람의 학습에 도움이되기를 바랍니다. 모든 사람이 wulin.com을 더 지원하기를 바랍니다.