[마이크로서비스의 원칙]
1. 비즈니스 개념에 따른 모델
인터페이스 안정성 : 비즈니스 경계로 나눔 > 기술적 개념에 맞춤
시스템이 동작하는 도메인을 모델링 -> 더 안정적인 인터페이스 형성
비즈니스 프로세스의 변경을 더 쉽게 반영 가능
2. 자동화 문화의 적용
다루어야 하는 변경되는 부분의 수만으로도 복잡성이 증가
자동화 테스팅이 매우 중요
일관된 명령 호출 = 어디에서나 같은 방식으로 배포 + 지속적 배포
환경 정의, 커스텀 이미지, 불변 서버 등을 사용
3. 내부 세부 구현의 은폐
경계가 있는 콘텍스트로 모델링 -> 공유되고 은폐되어야 하는 모델에 집중하게 도움
DB통합과 같은 결합 문제에 빠지지 않도록 데이터페이스도 감추어야 함
데이터 펌프 or 이벤트 데이터 펌프 -> 리포팅 목적으로 여러 서비스로부터 데이터를 통합
기술 중립적 API (REST)
4. 모든 것을 분권화
셀프 서비스 : 요구할 때 언제든 배포, 개발과 테스팅을 가능한 쉽게, 별도의 팀이 이러한 활동을 수행할 필요가 없게
팀이 변경 및 변경 릴리즈 시점까지도 스스로 결정하게 하여 팀이 그들의 서비스를 소유하도록 보장
내부 오픈 소스를 이용하면 다른 팀이 소유한 서비스를 변경할 수 있지만 구현이라는 부가적인 일이 생긴다는 점을 기억
콘웨이의 법칙이 효과가 있도록 팀을 조정
공유 거버넌스 모델 : 각 팀의 사람들이 시스템의 기술 비전을 진화시킬 책임을 집단으로 공유
코레오그래피 아키텍처 : 서비스 경계 내에서 로직과 데이터 연관성을 보장하는 영리한 엔드포인트로 응집력을 유지 (오케스트레이션과 멍청한 미들웨어는 사용하지 않음)
오케스트레이션(orchestration)
- 오케스트라 지휘자처럼 프로세스를 아내하고 구동하는 하나의 중앙 두뇌에 의존
- 고객 서비스에 지나치게 많은 중앙 관리 권한이 부여되는 단점
- 매우 취약하고 높은 변경 비용 수반
코레오그래피(choreography)
- 발레 무용수들이 자신의 역할을 알고 주변의 다른 무용수에 반응하는 것처럼 시스템 각 부분에 작업 내용을 알리고 세부 사항을 수행
- 비동기 방식으로 이벤트 발산을 통해 느슨한 결합을 이끔
5. 독립적인 배포
클라이언트 호환성을 깨는 변경이 필요할 때 시간을 두고 변경할 수 있도록 여러 버전의 엔드 포인트가 공존되도록 해야 함
RPC 기반의 통합을 한다면 Java RMI와 같은 강력히 결합된 클라이언트/서버 스텁의 생성은 피해야 함
호스트당 단일 서비스 모델 적용
청색/녹색 or 카나리아 릴리스 기법 : 잘못된 릴리스의 위험을 줄이며 릴리스와 배포를 분리
소비자 주도 계약 : 호환성을 깨뜨리는 변경을 미리 발견
6. 장애 격리
원격 호출을 지역 호출처럼 처리하면 안됨 - 지나치게 추상화한 클라이언트 라이브러리 사용 X
네트워크 파티션이 함축하는 것과 주어진 상황에서 가용성과 일관성 중 어느 것을 희생하는 것이 옳은 판단인지 알아야 함
7. 매우 식별 가능한
합성(가상) 트랜잭션을 주입함으로써 실사용자의 행위를 모의하는 유의적 모니터링을 사용
로그와 통계를 수집
시스템 간 모든 호출을 추적할 수 있도록 상관관계 ID 사용
[언제 마이크로서비스를 사용하지 않아야 하는가?]
1. 해당 분야를 제대로 이해하지 못할 때 : 경계가 있는 콘텍스트를 찾기 힘듦
2. 미개발 분야의 개발 : 모놀리식으로 시작하고 안정화되면 분해!
ref) 마이크로서비스 아키텍처 구축