SpringCloud 의 동적 리 셋,재 시도,서비스 화 실현

만약 우리 의 설정 이 원 격 창고 에서 가 져 오 는 데 실패했다 면 어떻게 처리 해 야 합 니까?Spring Cloud Config 가 제시 한 동적 리 셋 재 시도 기능 을 사용 해 야 합 니 다.Spring Cloud Config 는 서비스 화 되 어 있 습 니 다.그렇다면 서비스 화 는 무엇 일 까?
서비스 화
저 희 는 앞의 설정 에서 Config Client 가 Config Server 에서 설정 데 이 터 를 가 져 와 야 할 때 Config Client 의 설정 파일 에 Config Server 주 소 를 직접 적 습 니 다.다음 구조 와 같 습 니 다.

이러한 표기 법 은 Config Client 와 Config Server 를 연결 하여 죽 인 것 과 같 습 니 다.앞으로 Config Server 의 주 소 는 바 꿀 수 없고 Config Server 도 끊 을 수 없습니다.그렇지 않 으 면 Config Client 는 정 보 를 얻 지 못 할 것 입 니 다.그리고 이런 방식 은 우리 마이크로 서비스의 전체적인 구 조 를 파괴 합 니 다.즉,서비스 간 에 서로 호출 되 고 상대방 의 정 보 를 얻 는 것 은 모두 서비스 등록 센터 에서 얻 는 것 입 니 다.그래서 우 리 는 이런 구 조 를 개조 하여 다음 과 같은 구조 로 개조 해 야 한다.

Config Server 가 시 작 될 때 서비스 등록 센터 인 Eureka 에 자신 을 등록 합 니 다.모든 Config Client 는 Eureka 에서 Config Server 의 정 보 를 얻 습 니 다.그러면 우 리 는 Config Server 와 Config Client 를 결합 시 키 는 데 성 공 했 습 니 다.Eureka 는 여기 서도 데이터 센터 의 역할 을 했 습 니 다.
그렇다면 서비스 화 방법 을 보 여 드 리 겠 습 니 다.전편 의 예 에 따라 개조 할 수 있 습 니 다.물론 프로젝트 를 하나 더 만들어 서 이 룰 수도 있 습 니 다.여 기 는 제 가 다시 만 들 기로 했 습 니 다.여러분 을 데 리 고 만 들 겠 습 니 다.
우선,우 리 는 여전히 클 라 우 드 Config-fwh 일반 maven 프로젝트 를 만 들 었 습 니 다.그리고 cloudConfig-fwh 에서 github 프로필 을 저장 하기 위해 일반적인 폴 더 configRepo 를 만 든 다음 에 각각 eureka,config 를 만 듭 니 다.server、config_client。
만 든 후 프로젝트 구 조 는 다음 과 같 습 니 다.

그리고 우 리 는 각각 configclient 와 configserver 는 eureka 인 스 턴 스 에 등록 합 니 다.

우 리 는 localhost:7000 을 방문 한 결과 이미 등록 되 어 있 는 것 을 발견 했다.
그러면 Config Client 설정 이 필요 합 니 다.boottstrap.yml 에서 설정 합 니 다.boottstrap.yml 우선 순 위 는 application.yml 보다 높 고 spring cloud config 우선 설정 은 여기에 두 겠 습 니 다.
boottstrap.yml 설정 은 다음 과 같 습 니 다.

spring:
 application:
  name: config-server
 #     
 # profiles:
 #  active: native
 cloud:
  config:
   profile: dev
   label: master
   discovery:
    service-id: config-server3
    enabled: true
server:
 port: 8002
eureka:
 client:
  service-url:
   defaultZone: http://localhost:7000/eureka/

여기에 추 가 된 두 개의 설정 을 말씀 드 리 겠 습 니 다.그 중에서 discovery.service-id 은 원래 의 cloud.config.uri 을 대체 하 였 습 니 다.
원래 uri 는 길 게 써 야 돼 요.그리고 ip 주소 포트 번호 가 바 뀌 었 다 면 Config Server 에 가서 수정 해 야 합 니 다.여 기 는 service-id 를 사용 하여 이 문 제 를 완벽 하 게 해결 하 였 습 니 다.service-id 를 통 해 eureka 센터 에 가서 Config Server 의 인 스 턴 스 를 찾 습 니 다.discovery.enabled=true 은 eureka 를 통 해 Config Server 를 가 져 오 는 것 입 니 다.
여기 작은 구덩이 가 있 으 니 주의 하 세 요.바로 이 spring.application.name 의 이름 은 github 창고 에 있 는 프로필 의 접두사 입 니 다.다음 그림 과 같 습 니 다.

여기 config-server 를 가 져 오 면 됩 니 다.
설정 이 완료 되면 http://localhost:8002/love 방문 결 과 는 다음 과 같 습 니 다.

이렇게 해서 접근 이 성공 했다 는 것 은 우리 의 설정 에 문제 가 없다 는 것 을 설명 한다.다음은 동적 리 셋 을 말씀 드 리 겠 습 니 다.
동적 새로 고침
다음은 설정 파일 의 동적 새로 고침 문 제 를 살 펴 보 겠 습 니 다.Git 창고 에서 설정 파일 이 바 뀌 면 Config Server 의 요청 주 소 를 새로 고치 면 데이터 도 달라 집 니 다.즉,Config Server 는 설정 파일 의 변 화 를 신속하게 감지 할 수 있 지만 이러한 감 지 는 Config Client 에 전달 되 지 않 습 니 다.즉,Config Client 는 설정 파일 의 변 화 를 제때에 감지 할 수 없습니다.기본 적 인 상황 에서 Config Client 가 다시 시작 해 야 최신 설정 파일 데 이 터 를 불 러 올 수 있 습 니 다.Config Client 도 설정 데 이 터 를 동적 으로 새로 고 칠 수 있 습 니까?
Config Client 에 다음 의존 도 를 추가 하면 동적 으로 설정 을 새로 고 칠 수 있 습 니 다.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

추가 완료 후 refresh 인터페이스 노출 이 필요 합 니 다.G 버 전의 Cloud 를 제외 하고 수 동 으로 refresh 인 터 페 이 스 를 노출 해 야 합 니 다.다른 버 전의 Cloud 는 아래 설정 을 설정 하지 않 아 도 수 동 으로 노출 됩 니 다.

management:
 endpoints:
  web:
   exposure:
    include: 'refresh'

이 설정 이 완료 되면 HelloController 에 대한 설명 @RefreshScope 을 추가 합 니 다.refresh 인 터 페 이 스 를 호출 할 때 동적 새로 고침:

@RefreshScope
@RestController
public class HelloController {
  @Value("${love}")
  String love;

  @GetMapping("/love")
  public String name() {
    return love;
  }
}

설정 이 완료 되면 Config Client 프로젝트 를 다시 시작 합 니 다.그리고 아이디어 의 콘 솔 /actuator/refresh 인터페이스 가 노출 되 었 습 니 다.

이 인 터 페 이 스 는 설정 파일 을 동적 으로 새로 고 치 는 데 사 용 됩 니 다.
물론 이 동적 리 셋 인 터 페 이 스 를 설정 하 였 습 니 다.우 리 는 반드시 방문 하여 테스트 해 야 합 니 다.인터페이스 가 정상 입 니까?
저 희 는 http://localhost:8002/actuator/refresh 을 방문 하여 post 를 사용 하여 방문 을 요청 합 니 다.다음 그림 처럼 인터페이스 가 정상 적 이라는 것 을 설명 합 니 다.

그러나 세심 한 사람 은 Config Client 를 다시 시작 하지 않 은 상태 에서 도 동적 리 셋 설정 을 실현 할 수 있 는 문 제 를 발견 할 수 있 습 니 다.그러나 모든 마이크로 서 비 스 는 /actuator/refresh 인터페이스 요청 을 하나씩 보 내야 합 니 다.귀 찮 습 니 다.그렇다면 어떤 간편 한 방법 이 있 습 니까?있 을 거 야.내 가 소개 할 게.
요청 실패 재 시도
부탁 이 실패 하면 다시 해 봐 야 지,실패 할 리 가 없 으 니 계속 실패 하 게 해 줘.이 건 안 될 거 야.세심 한 친구 가 제 이전의 글 을 보 았 다 면 저 는 어떻게 실패 하고 다시 시도 하 는 지 에 대해 말 했 습 니 다.예 를 들 어 네트워크 의 변동,네트워크 의 질 이 매우 나 쁜 상황 에서 서비스 호출 의 실 패 를 초래 할 수 있 습 니 다.그러면 우 리 는 요청 에 실패 하고 다시 시도 해 야 한다.
실 패 를 실현 하려 면 다시 시도 하 는 것 도 매우 간단 하 다.전에 내 글 을 본 친구 들 은 여기에 두 가지 의존 이 필요 하 다 는 것 을 알 고 있 을 것 이다.

<dependency>
  <groupId>org.springframework.retry</groupId>
  <artifactId>spring-retry</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

이 의존 도 를 추가 하면 Config Client 의 boottstrap.yml 에 다음 설정 을 추가 해 야 합 니 다.

fail-fast: true

이 설정 은 실패 하고 빠 른 응답 을 하 는 것 을 의미 합 니 다.기본 적 인 상황 에서 Config Client 가 Config Server 를 방문 하 는 데 실 패 했 을 때 이 아니 라 Config Server 이 될 때 까지 기 다 려 야 이 됩 니 다.쉽게 말 하면 우리 가 이전에 love 변 수 를 가지 고 있 지 않 았 습 니까?만약 이 love 변수 가 존재 하지 않 고,우리 Config Client 가 또 호출 되 어 사용 된다 면,오 류 를 보고 하고 이상 을 던 질 것 입 니 다.따라서 Config Client 가 Config Server 에 접근 하 는 데 실 패 했 을 때 빠 른 응답 을 켜 야 합 니 다.여 기 는 실패 하고 다시 시도 할 수도 있 고 사용자 정의 이상 정 보 를 던 질 수도 있 습 니 다.
이 설정 을 추가 한 후 실행 효 과 를 보 여주 기 위해 서 는 조금 만 더 수정 하 겠 습 니 다.현재 Config Server 는 보안 인증 이 있 기 때문에 Config Client 는 사용자 이름 비밀번호 가 있어 야 Config Server 에 접근 할 수 있 습 니 다.Config Client 에서 Config Server 에 접근 한 사용자 이름 비밀 번 호 를 잠시 설명 합 니 다.즉,다음 두 줄 입 니 다.

#spring:
# cloud:
#  config:
#   username: jishu
#   password: 123456

이 곳 의 username 과 password 는 Config Server 에 설 정 된 Security 의 계 정 암호 정보 입 니 다.설명 을 다 한 후 Config Client 프로젝트 를 다시 시작 합 니 다.실패 한 재 시도 효 과 를 살 펴 보 겠 습 니 다.

이 를 통 해 알 수 있 듯 이 모두 6 번 의 요청 을 보 냈 습 니 다.첫 번 째 실패 후에 도 5 번 을 다시 시 도 했 습 니 다.이것 이 기본 적 인 요청 정책 입 니 다.요청 정책 을 설정 할 수 있 습 니 다.

spring:
 cloud:
  config:
   retry:
    initial-interval: 1000
    multiplier: 1.1
    max-interval: 2000

이 네 가지 설정 은 다음 과 같다.

max-attemps 는 최대 요청 횟수 를 표시 합 니 다.기본 값 은 6 입 니 다.바로 위 그림 에서 보 셨 던 상황

입 니 다.

initial-interval 은 재 시도 요청 의 초기 시간 간격

을 표시 합 니 다.

multiplier 는 시간의 간격 곱 수 를 나타 낸다.네트워크 디 더 링 은 일반적으로 규칙 적 이기 때문에 재 시도 요청 시 연속 적 인 충돌 을 방지 하기 위해 우 리 는 시간 간격 곱 수 를 필요 로 한다.여기 서 나 는 간격 곱 수 를 1.2 로 설정 했다.첫 번 째 재 시도 간격 은 1s 이 고 두 번 째 간격 은 1.2 초 임 을 나타 낸다.■세 번 째 간격 1.44 초...

max-interval 은 재 시도 의 최대 간격 을 표시 합 니 다.

요청 재 시도 체 제 를 열 면 약 한 네트워크 환경 에서 도 서비스의 가용성 을 효과적으로 보장 할 수 있 습 니 다.
총결산
본 고 는 분포 식 설정 센터 Spring Cloud Config 에서 흔히 볼 수 있 는 세 가지 문제,서비스 화,데이터 동적 새로 고침 설정 및 재 시도 요청 실 패 를 소개 합 니 다.서비스 화 는 Config Server 와 Config Client 간 의 결합 도 를 낮 추어 우리 의 프로젝트 구 조 를 더욱 규범화 시 켰 다.동적 새로 고침 은 Config Client 를 다시 시작 하지 않 은 상태 에서 설정 데 이 터 를 새로 고 칠 수 있 습 니 다.마지막 으로 재 시도 요청 은 약 한 네트워크 환경 에서 서비스의 가용성 을 확보 했다.실제 생산 프로젝트 에서 이 세 가 지 는 기본적으로 모두 필수 적 인 것 이 므 로 모두 진지 하 게 파악 해 야 한다.
항목 주소
github
이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.