microconfig.io를 사용하여 마이크로서비스 구성을 쉽게 관리

마이크로서비스 개발 및 후속 운영의 주요 문제 중 하나는 해당 인스턴스의 유능하고 정확한 구성입니다. 제 생각에는 새로운 프레임워크가 이 작업에 도움이 될 수 있습니다. microconfig.io. 이를 통해 일부 일상적인 애플리케이션 구성 작업을 매우 우아하게 해결할 수 있습니다.

마이크로서비스가 많고 각 마이크로서비스가 자체 구성 파일/파일과 함께 제공되는 경우 그 중 하나에서 오류가 발생할 확률이 높으며 적절한 기술과 로깅 시스템 없이는 이를 포착하기가 매우 어려울 수 있습니다. 프레임워크가 자체적으로 설정하는 주요 작업은 중복된 인스턴스 구성 매개변수를 최소화하여 오류 추가 가능성을 줄이는 것입니다.

예를 살펴보겠습니다. 구성 파일이 있는 간단한 애플리케이션이 있다고 가정해 보겠습니다. 얌. 이는 모든 언어의 모든 마이크로서비스일 수 있습니다. 이 서비스에 프레임워크를 어떻게 적용할 수 있는지 살펴보겠습니다.

하지만 먼저 편의를 위해 microconfig.io 플러그인을 설치한 후 Idea IDE에서 빈 프로젝트를 생성해 보겠습니다.

플러그인 실행 구성을 설정했습니다. 위 스크린샷과 같이 기본 구성을 사용할 수 있습니다.

우리 서비스를 order라고 부르며, 새 프로젝트에서 비슷한 구조를 만들 것입니다.

서비스 이름이 있는 폴더에 구성 파일을 놓습니다. application.yaml. 모든 마이크로서비스는 일종의 환경에서 시작되므로 서비스 자체에 대한 구성을 만드는 것 외에도 환경 자체를 설명해야 합니다. 이를 위해 폴더를 만듭니다. 환경 작업 환경 이름으로 파일을 추가합니다. 따라서 프레임워크는 환경의 서비스에 대한 구성 파일을 생성합니다. DEV, 이 매개변수는 플러그인 설정에서 설정되기 때문입니다.

파일 구조 dev.yaml 그것은 아주 간단할 것이다:

mainorder:
    components:
         - order

프레임워크는 함께 그룹화된 구성으로 작동합니다. 서비스를 받으려면 그룹 이름을 선택하세요. 메인오더. 프레임워크는 환경 파일에서 이러한 각 애플리케이션 그룹을 찾아 해당 폴더에서 찾은 모든 애플리케이션에 대한 구성을 생성합니다.

서비스 설정 파일 자체에서 주문 지금은 하나의 매개변수만 지정하겠습니다.

spring.application.name: order

이제 플러그인을 실행해 보겠습니다. 그러면 속성에 지정된 경로에 따라 서비스에 필요한 구성이 생성됩니다.

하나는 수 지내다 플러그인을 설치하지 않고 간단히 프레임워크 배포판을 다운로드하고 명령줄에서 실행하면 됩니다.
이 솔루션은 빌드 서버에서 사용하기에 적합합니다.

프레임워크가 완벽하게 이해한다는 점은 주목할 가치가 있습니다. 재산 구문, 즉 함께 사용할 수 있는 일반 속성 파일입니다. 얌 구성.

다른 서비스를 추가해 보겠습니다. 지불 기존 것을 복잡하게 만듭니다.
В 주문:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

В 지불:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9998
spring.application.name: payments
db.url: 192.168.0.100

이러한 구성의 주요 문제점은 서비스 설정에 많은 양의 복사-붙여넣기가 존재한다는 것입니다. 프레임워크가 이를 제거하는 데 어떻게 도움이 되는지 살펴보겠습니다. 가장 분명한 것부터 시작하겠습니다 - 구성의 존재 유레카 각 마이크로서비스 설명에 설정 파일을 사용하여 새 디렉터리를 만들고 여기에 새 구성을 추가해 보겠습니다.

이제 각 프로젝트에 라인을 추가해 보겠습니다. #유레카 포함.

프레임워크는 자동으로 유레카 구성을 찾아서 서비스 구성 파일에 복사하지만, 환경 파일에 지정하지 않으므로 별도의 유레카 구성이 생성되지 않습니다. dev.yaml. 서비스 주문:

#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

가져오기 라인을 다음으로 변경하여 데이터베이스 설정을 별도의 구성으로 이동할 수도 있습니다. #include 유레카, 오라클.

구성 파일을 다시 생성할 때 프레임워크가 각 변경 사항을 추적하고 이를 기본 구성 파일 옆의 특수 파일에 배치한다는 점은 주목할 가치가 있습니다. 로그 항목은 다음과 같습니다. “Stored 1 속성이 다음으로 변경됩니다. 주문/diff-application.yaml" 이를 통해 대규모 구성 파일의 변경 사항을 신속하게 감지할 수 있습니다.

구성의 공통 부분을 제거하면 불필요한 복사-붙여넣기를 많이 제거할 수 있지만 다양한 환경에 대한 구성을 유연하게 생성할 수는 없습니다. 서비스의 끝점은 고유하고 하드 코딩되어 있으므로 이는 좋지 않습니다. 이것을 제거해 보도록 하겠습니다.

좋은 해결책은 모든 엔드포인트를 다른 사람이 참조할 수 있는 하나의 구성으로 유지하는 것입니다. 이를 위해 자리 표시자에 대한 지원이 프레임워크에 도입되었습니다. 구성 파일이 다음과 같이 변경됩니다. 유레카:

 client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/

이제 이 자리 표시자가 어떻게 작동하는지 살펴보겠습니다. 시스템은 다음과 같은 구성 요소를 찾습니다. 엔드 포인트 그리고 그 속에서 의미를 찾는다 유레카입, 그런 다음 이를 구성으로 대체합니다. 하지만 환경이 다르면 어떨까요? 이렇게 하려면 다음 위치에 설정 파일을 만듭니다. 엔드 포인트 다음 유형 application.dev.yaml. 프레임워크는 파일 확장자에 따라 독립적으로 이 구성이 속하는 환경을 결정하고 로드합니다.

개발 파일 내용:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

서비스 포트에 대해 동일한 구성을 만들 수 있습니다.

server.port: ${ports@order}.

모든 중요한 설정이 한 곳에 있으므로 구성 파일에 분산된 매개변수로 인한 오류 가능성이 줄어듭니다.

프레임워크는 미리 만들어진 많은 자리 표시자를 제공합니다. 예를 들어 구성 파일이 있는 디렉터리의 이름을 가져와 할당할 수 있습니다.

#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}

덕분에 구성에서 애플리케이션 이름을 추가로 지정할 필요가 없으며 동일한 유레카와 같은 공통 모듈에 배치할 수도 있습니다.

client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/
 spring.application.name: ${this@name}

구성 파일 주문 한 줄로 줄어듭니다.

#include eureka, oracle
server.port: ${ports@order}

상위 구성의 설정이 필요하지 않은 경우 구성에서 이를 지정할 수 있으며 생성 중에 적용됩니다. 즉, 어떤 이유로든 주문 서비스에 대한 고유한 이름이 필요한 경우 매개변수만 그대로 두겠습니다. spring.application.name.

별도의 파일에 저장되는 사용자 정의 로깅 설정을 서비스에 추가해야 한다고 가정해 보겠습니다. 예를 들면 다음과 같습니다. logback.xml. 이에 대한 별도의 설정 그룹을 만들어 보겠습니다.

기본 구성에서는 자리 표시자를 사용하여 필요한 로깅 설정 파일을 배치할 위치를 프레임워크에 알려줍니다. @ConfigDir:

microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml

파일에서 logback.xml 표준 어펜더를 구성합니다. 여기에는 구성 생성 중에 프레임워크가 변경하는 자리 표시자가 포함될 수도 있습니다. 예를 들면 다음과 같습니다.

<file>logs/${this@name}.log</file>

서비스 구성에 가져오기를 추가하여 로그백, 각 서비스에 대해 구성된 로깅을 자동으로 가져옵니다.

#include eureka, oracle, logback
server.port: ${ports@order}

이제 프레임워크의 사용 가능한 모든 자리 표시자에 대해 더 자세히 알아볼 시간입니다.

${this@env} - 현재 환경의 이름을 반환합니다.
${…@name} — 구성 요소의 이름을 반환합니다.
${…@configDir} — 구성 요소의 구성 디렉터리에 대한 전체 경로를 반환합니다.
${...@resultDir} — 구성 요소의 대상 디렉터리에 대한 전체 경로를 반환합니다(결과 파일은 이 디렉터리에 배치됩니다).
${this@configRoot} — 구성 저장소의 루트 디렉터리에 대한 전체 경로를 반환합니다.

또한 시스템을 사용하면 Java 경로와 같은 환경 변수를 얻을 수 있습니다.
${env@JAVA_HOME}
어느 쪽이든 프레임워크가 다음 언어로 작성되었기 때문에 JAVA, 호출과 유사한 시스템 변수를 얻을 수 있습니다 시스템::getProperty 다음과 같은 구조를 사용합니다.
${[이메일 보호]}
확장 언어에 대한 지원을 언급할 가치가 있습니다. 스프링EL. 구성에는 다음 표현식을 적용할 수 있습니다.

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} 

표현식을 사용하여 구성 파일에서 로컬 변수를 사용할 수 있습니다 #var:

#var feedRoot: ${[email protected]}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

따라서 프레임워크는 마이크로서비스를 미세 조정하고 유연하게 구성하기 위한 상당히 강력한 도구입니다. 프레임워크는 설정에서 복사-붙여넣기를 제거하고 설정을 통합하여 결과적으로 가능한 오류를 최소화하는 동시에 구성을 쉽게 결합하고 다양한 환경에 맞게 변경할 수 있도록 하는 주요 작업을 완벽하게 수행합니다.

이 프레임워크에 관심이 있다면 공식 페이지를 방문하여 전체 내용을 알아보는 것이 좋습니다. 선적 서류 비치, 또는 소스를 자세히 살펴보세요. 여기에.

출처 : habr.com