4. 통합

마이크로 서비스의 통합은 어떻게 말하면 느슨한 결합의 분리를 의미한다. 하나의 마이크로 서비스가 다른 마이크로 서비스와 통신하는 방법

에 대한 여러가지 방법에 대해서 공부하려 한다.

 

- 공유 데이터베이스 

 

가장 단순하지만 마이크로 서비스 아키텍쳐가 추구하는 방법이 아니다. 강한 응집력과 느슨한 결합력을 잃게 되는 것만으로 피해야하는 통합
(통신) 방법이다.

 

- 오케스트레이션과 코레오그래피

 

오케스트레이션 방식은 지휘자처럼 프로세스를 안내하고, 구동하는 하나의 Master에 의존한다. 반면 코레오 그래피 방식은 발레 무용수들이 자신의 역할을 알고 주변의 다른 무용수에 반응하는 것처럼 시스템 각 부분에 작업 내용을 알리고 세부 사항을 수행하게 한다.

 중앙 관리 권한에 많은 권한이 있는 것 오케스트레이션 방식에 대비해서 이벤트를 발산하고, 그것을 체크하여 수행하는 방식인 코레오 그래피 방식은 느슨한 결합을 이끌어낸다. (이때 일이 제대로 수행되는지 모니터하고 추적하기 위한 추가 작업이 필요하다.)

 

- 원격 프로시저 호출 (Repote Procedure Call) RPC

 

 마이크로 서비스의 경우 다양한 언어와 프레임워크로 개발 될 수 있기 때문에, 프로토콜을 맞춰서 통신해야 하는 비용이 발생한다. 이럴 때 RPC를 이용하여 언어에 구애받지 않고, 원격에 있는 프로시저를 호출하여 비즈니스 로직에 집중할 수 있게 된다.

 

- REST 

 

 클라이언트가 요청/응답 통신을 사용하는 경우 요청을 서비스에 보낸 다음, 서비스가 요청을 처리하고 다시 응답을 보낸다. 요청/응답 통신은 특히 클라이언트 앱에서 실시간 UI(라이브 사용자 인터페이스)에 대한 데이터를 쿼리하는 데 적합.

 

-  버전관리의 가장 좋은 방법은 애초에 결함을 만들어내지 않는 것 

 

 관심 없는 데이터의 변경들을 무시할 수 있도록 독자를 구현하는 것 (관대한 독자 패턴)

 '전송할 때는 보수적으로, 받아들일 때는 자유롭게' (포스텔 법치)

 

 버전관리시의 하위 호환성이 깨지는 경우와 아닌 경우를 알 수 없을까? -> 유의적 버전 관리 (Major.Minor.Patch) 

 

 

전체적으로 여러가지 통신 방법들이 있고, 이것들로 각 마이크로 서비스를 어떻게 통합할 것이고, 문제를 해결할 것인지에 대한 고민들이 있는 부분인 것 같다. 책의 내용을 요약하는 것보다 내 것으로 만들어서 그에 대한 생각을 정리하고 싶었지만 굉장히 많은 내용을 다루고 있어 그런 부분이 어려웠고 각 기술들에 대해서 깊게 공부하는 시간을 가져야겠다는 생각을 하게 했다.  (gRPC, 메시지 큐 등에 대한 정리도 추가로 할 시간을 만들어보아야 겠다. )

 

 

이는 마이크로서비스 아키텍처 구축을 공부하면서 생각을 정리한 것입니다.. 관련된 내용에 대해서 더 알고 싶은 경우에는 해당 책을 보는 것을 권유합니다.

마이크로서비스 아키텍처 구축