Spring Cloud Config를 동적으로 조작하는 방법은 크게 3가지로 나뉜다.
장점 : 구조가 단순해서 서버 관리가 쉽다.
단점 : 변경한 서비스의 인스턴스가 100개라 가정했을때 refresh 요청 보내야할게 100개다ㅎㅎ;
장점 : 인스턴스 별로 refresh를 MQ가 대신 날려주는 셈이다. 개꿀
단점 : config 서버 하나때문에 MQ를 두는 것은 잘 생각해봐야한다. 이미 MQ가 도입된 상황이면 진짜 개꿀이지만 그렇지 않은 경우라면 MQ서버도 관리해야 할 대상에 들어간다.
장점 : 자기스스로 업데이트 해서 속성이 변경되더라도 내가 안알려줘도 됨
단점 : 자꾸 서버에 물어봐야해서 리소스 낭비가 있음. 또, 잘 설정된 라이브러리를 헤집어서 설정해 줘야함..
-> 첫번째 처럼 하기에는 너무 번거롭고 두번째 처럼 하기에는 서버 관리 비용이 들어 세번째로 정하였다.
리소스 낭비되는 부분은 Scheduling 시간을 널널하게 두면 되기 때문에 큰 비용이라 생각하지 않았고,설정이 굳이 실시간으로 이뤄져야 하는 이유를 찾지 못해서 세번째로 정하였다.
코드는 아래 주소에 잘 나와있어서 거의 비슷하게 했다.ㅋㅋㅋ
https://jaehun2841.github.io/2022/03/10/2022-03-11-spring-cloud-config-polling/
잘 설정된 라이브러리를 헤집는건 문제가 되지 않는다. 혼자 서비스를 개발하고 올린다면..
그러나!!! 개발해야할 서비스가 늘어나다 보면 각 서비스 별로 그 코드를 구현해 놓아야한다는 점이다. 그래서 생각했다. 이거 라이브러리로 만들면 한곳에서 관리하고 업데이트 할 수 있잖아!....
나는 예전부터 나도 라이브러리 만들 수 있겠지 하는 조그마난 꿈도 있었기에 도전했다.
라이브러리를 만드는 과정은
https://www.youtube.com/watch?v=tr5_OWgXDiw&list=LL&index=1&t=680s
이 동영상 토씨하나 안틀리고 따라하면 금방 만들 수 있더라...