마이크로서비스 아키텍처 구축(전면 개정판)

653

16

장

진화하는 아키텍트

서비스별 뷰가 아니라 시스템 전체에 대한 뷰여야 한다.

10

장에서 논의했듯이 개별 마이크로

서비스의 상태를 아는 것은 유용하지만, 더 광범위한 문제를 진단하거나 더 큰 추세를 이해하

려고 할 때 특히 유용하다. 이를 최대한 쉽게 작업하려면, 모든 마이크로서비스가 상태 관련 메

트릭과 일반 모니터링 관련 메트릭을 동일한 방식으로 발송하는 것이 좋다.

각 마이크로서비스가 이 데이터를 중앙 위치로 푸시하는 푸시 메커니즘을 채택할 수도 있다.

어떤 방식을 선택하든 표준화된 방식을 유지하라. 상자 안의 기술을 불투명하게 만들고, 이를

지원하기 위해 모니터링 시스템을 변경할 필요가 없게 하라. 로깅

logging

도 같은 범주에 속하며,

한 곳에서 관리해야 한다.

16.12.216.12.2

인터페이스 인터페이스

소수의 정의된 인터페이스 기술을 선택하면 새로운 소비자를 통합하는 데 도움이 된다. 하나의

표준이 있으면 좋고

2

개도 나쁘지 않다. 하지만

20

개의 서로 다른 통합 스타일이 있다면 좋지

못하다. 이는 단순히 기술과 프로토콜을 선택하는 문제가 아니다. 예를 들어

HTTP

/

REST

를

선택한다면 동사

verb

를 사용할 것인가, 명사

noun

를 사용할 것인가? 자원의 페이지 매김

pagination

은

어떻게 처리할 것인가? 엔드포인트의 버전 관리는 어떻게 처리할 것인가?

16.12.316.12.3

아키텍처 안전 아키텍처 안전

오동작하는 마이크로서비스 하나 때문에 모두를 위한 ‘파티’를 망칠 수는 없다. 따라서 마이크

로서비스가 ...