MSA(3) - 스프링 부트로 마이크로서비스 구축하기

마이크로서비스 프로젝트 아키텍쳐는 세 가지 핵심 업무에 집중한다.

1. 비즈니스 문제 분해
2. 서비스 세분화 확정
3. 서비스 인터페이스 정의

 

비즈니스 문제 분해

• 명사에 주목
• 동사에 주목
• 데이터 응집성을 찾기

 

서비스 세분화 확정

• 광범위하게 시작하여 더 작은 서비스로 리팩토링
• 서비스간 교류하는 방식에 중점
• 도메인에 이해가 깊어지면서 서비스 책임도 계속 변한다.

 

여기서 나쁜 서비스의 징후들은 ?

• 책임이 너무 많은 서비스
• 다수 테이블에 걸쳐 데이터를 관리하는 서비스
• 테스트가 너무 많은 서비스

 

그렇다면 너무 작은 서비스는?

• 마이크로서비스가 토끼처럼 번식한다
• 지나치게 상호 의존적이다
• 서비스들이 단순 CRUD서비스 집합이 된다

 

서비스 인터페이스 설계

• REST 철학을 수용해라
• URI를 사용하여 의도를 전달해라
• 요청과 응답에 JSON을 사용해라
• HTTP 상태 코드로 결과를 전달해라

 

 

절대 사양해야할 금기사항

• 분산 시스템 구축의 복잡성 : 자동화와 운영작업(모니터링, 확장)에 투자하지 않는 한 사용을 고려하지 않는 편이 좋다
• 가상 서버나 컨테이너 스프롤 : 어지간한 서비스에서는 서버를 관리하고 모니터링하는 운영 작업이 오히려 더 복잡할 수 있다.
• 애플리케이션 타입 : 규모가 작은 애플리케이션은 오히려 비효율적이다
• 데이터 트랜잭션과 일관성 : 

 

엔드포인트 이름은 ?

• 리소스에 명확한 URL 이름 사용
• 리소스 간 관계 설정
• URL 버전 체계를 일찍 세워라

 

 

---

• 마이크로서비스는 일체형이어야 한다 : 여러 인스턴스를 독립적으로 배포할 수 있어야 한다.
• 마이크로서비스는 구성 가능해야 한다 : 구성 정보를 한곳에서 읽어 오거나 환경 변수로 전달받아야 한다
• 인스턴스는 클라이언트에 투명해야 한다 : 서비스 디스커버리 에이전트와 통신해야 한다
• 자기 상태를 전달해야 한다 : 디스커버리 에이전트는 고장난 인스턴스를 우회해서 라우팅해야 한다. 스프링 부트 액추에이터를 사용해서 상태를 표시한다

 

아래의 4가지 수칙을 마이크로서비스를 빌드하고 환경에 배포할 때마다 발생하는 표준 수명 주기 이벤트로 변환해야 한다.

1. 서비스 조립 : 반복성과 일관성을 보장하면서 서비스를 패키징하고 배포하는 방법
2. 서비스 부트스트래핑 : 런타임 코드에서 애플리케이션 코드와 환경별 구성 코드를 분리하는 방법
3. 서비스 등록 및 디스커버리 : 새 마이크로서비스가 배포될 때 애플리케이션 클라이언트가 새 서비스 인스턴스를 발견할 수 있는 방법
4. 서비스 모니터링 : 인스턴스를 모니터링해야 하며 장애가 발생한 서비스 인스턴스를 우회해서 라우팅하고 종료되는지 확인해야 한다

 

 

 

서비스 디스커버리 에이전트는 등록된 각 서비스 인스턴스 상태를 모니터링하고 라우팅 테이블에서 실패한 서비스 인스턴스를 제거하여 클라이언트가 실패한 서비스 인스턴스와 통신하지 않도록 한다.

 

정리하자면

• 아키텍트, 개발자, 데브옵스 팀의 관점을 통합해야 한다.
• 아키텍트 관점에서는 마이크로서비스가 작고 독립적이며 분산되어 있다. 그 경계가 좁고 소규모 데이터를 관리해야 한다.
• 개발자 관점에서는 REST 스타일 디자인을 사용하여 구축하고 데이터를 주고받을 수 있는 페이로드로 JSON을 사용한다.
• 국제화의 주요 목표는 다양한 형식과 언어로 콘텐츠를 제공하는 애플리케이션을 개발하는 것이다.
• 데브옵스 관점에서 마이크로서비스를 패키징, 배포, 모니터링하는 방법은 매우 중요하다. JAR파일로 제공할 수 있고 톰캣 서버가 서비스를 호스팅한다.
• 스프링 액추에이터는 서비스의 런타임 정보와 함께 서비스의 운영 상태 정보도 제공한다.