msa를 호출 할 때 msi서버끼리 p2p를 처리하려면 eureka 서버나 ribbon 사용
spring cloud feign 을 처리
eureka나 ribbon은 그냥 url만 지우면 된다더라...
eureka가 내부적인 동작 원리가 가장 복잡함
총 4단계로 돌아가기에 다양한 레이어에 캐시가 되어 있기에 대략 60초에서 90초까지 걸림
eureka에서 명령을 하는 방법으로 처리
서버 인스턴스가 1개 문제가 있다면 같은 부분이 있다면 전체에서 일부분 이기에 분명히 circuit breaker 가 기본 세팅 50퍼보다 작기에 생각보다 거의 작동하지 않음 이때 fallback, timeout은 해주긴 함
config server는 모든 서비스에 다 설치해뒀음 config client에서 알아서 가져와서 정말 간단해짐
config cluent의 우선순위를 정말 설정을 잘 해야 함. system, config, application 순이나 그런 방식으로 처리
git 기반으로 config 관리시에 pr로 돌아가는 장점 역시 있음
기존 모니터링에 추가 해야 되는 것은 twitter가 개발한 집킨 같은 거로 uuid를 헤더에 박아버림. 그래서 그거를 계속 따라가야 됨. 어플리케이션 안에도 다 박야 됨. spring cloud 에 slemuth라는 프로젝트 컴포넌트 끼리 전달 뿐만 아니라 다른 서비스까지 다 되어 있음
서버와 서버와 서버가 계속 거치면서 파라미터가 무한히 필요해지고 그런 부분이 그냥 타임 아웃을 일으킬 수도 있음. 커뮤니케이션 과정을 통해서 캐싱같은 부분을 도입하는 것이 훨씬 좋음
zipkin extension에서 모든 url에 대해서 다 볼 수 있음
완성도 높은 코드라는거는 참 문법이 깔끔한가? 명칭이 깔끔한가? 대신 기능을 완벽하게 작동한다고 확신할 수 있는가?
우리가 고민해야 할 부분은 config가 어떻게 라이브하게 바뀔 수 있는가
https://velog.io/@kimsehwan96/S3-CORS-%ED%97%A4%EB%8D%94-%EA%B4%80%EB%A0%A8-%EC%9D%B4%EC%8A%88-%ED%95%B4%EA%B2%B0%EB%B0%A9%EB%B2%95-html2canvas-lottie
이렇게 s3에서 다운로드를 가능하도록 처리할 수도 있었다... 정말 이게 맞나? 싶긴 해도 되긴 했다
const downloadImage = (imageUrl: string) => {
fetch(imageUrl, {
method: "GET",
headers: {},
}).then((res) => {
res.arrayBuffer().then((buffer) => {
const url = window.URL.createObjectURL(new Blob([buffer]));
const link = document.createElement("a");
link.href = url;
link.innerHTML = "hello";
link.setAttribute("download", "image.png");
document.body.appendChild(link);
link.click();
});
});
};이거는 진짜 천재가 아닐까? 미쳤다
