많은 서버가있는 시스템을 상상해보십시오. 각각에는 여러 가지 설정이 있습니다.
- 서버에 특정한 것
- 지역에 따라 일부
- 그들 모두에게 공통적 인 것
- 이 서버 그룹은 읽기 전용이므로 일부 사용자 지정 그룹을 가질 수 있습니다.
- 기타
내가 생각하는 현재 관행은 재정의 능력을 가진 간단한 속성 구조입니다.
예제 목적으로 Google 서버를 사용할 수 있습니다. 각각에는로드 할 설정 목록이 있습니다.
예를 들어 런던 서버에는 다음이있을 수 있습니다.
rootsettings.properties
, europesettings.properties
, londonsettings.properties
, searchengine.properties
, 등
각 파일에 일련의 속성이 포함되어 있고 로딩 순서를 통해 속성을 재정의 할 수있는 경우 더 멀리 갈 수 있습니다.
예를 들어 rootsettings.properties
있을 수 있습니다 accessible=false
기본으로하지만,에 오버라이드 searchengine.properties
와accessible=true
내가이 구조로 가지고있는 문제는 통제하기가 매우 쉽다는 것입니다. 전혀 구조화되지 않았으므로 어떤 수준에서든 속성을 정의 할 수 있으며 많은 항목이 더 이상 사용되지 않을 수 있습니다.
또한 이제는 많은 서버에 영향을 미치므로 네트워크가 성장함에 따라 중간 레벨을 변경할 수 없습니다.
마지막으로, 각 개별 인스턴스에는 1 개의 특수 속성이 필요할 수 있습니다. 즉, 트리는 각 서버에 대한 구성으로 끝나므로 최적의 솔루션이 아닙니다.
더 나은 구성 관리 아키텍처의 제안 / 아이디어가 있다면 대단히 감사하겠습니다.