다른 마이크로서비스를 배포하지 않고, 마이크로서비스를 배포,출시할 수 있음
이를 위해
- 마이크로서비스 간 결합도를 낮춰야함
- 즉 서비스간에 명시적, 잘 정의되고, 안정된 명세/계약(api) 필요
예를들어 A서비스가 B서비스와 동기통신을 하는경우
A서비스는 B서비스가 동작중이지 않으면 동작할 수 없다.
이런 강결합을 해소하고자 동기통신을 메세징 서비스를 활용한 비동기로 처리
2. 비즈니스 도메인을 중심으로 모델링
도메인 기준으로 서비스 경계를 정의
-> ex) 재고관리를 담당하는 서버는 재고관리만 / 결제는 결제를 모두 구현
- 즉. 한 마이크로서비스가 기능에 필요한 전체를 구현
- 새 기능 출시가 쉬워짐
- 다른 방식으로 마이크로 서비스를 재조합하기 쉬워짐
3. 데이터베이스/ 데이터를 공유하지 말아라
마이크로서비스는 db/데이터를 공유하면 안된다
다른 마이크로서비스가 갖고있는 데이터에 접근하기 위해선 api를 통해서 접근
- 직접 접근을 하지 마라
- 이는 곧 결합도의 증가
- 왜냐? a,b 서비스가 디비를 공유하면 a가 잘못건드려서 b도 디비 접근이 안될 수 있다
- 즉 강하게 결합되어버린다.
4. 마이크로서비스의 크기는 내 머리가 이해할 수 있는정도
얼마나 많은 마이크로서비스를 다룰 수 있냐?
- 마이크로서비스의 증가 -> 복잡도 증가 -> 새 기술 습득 필요
서비스간 경계 정의
- 복잡하게 얽힌다면 이해를 위한 비용이 증가
5. 유연함
마이크로서비스가 필요한가?
굳이 엄청 큰 규모 혹은 너무 작은 단위로 나눌필요가 있는가?
마이크로서비스는 옵션으로 알맞게 상황에 맞게 판단하여 이를 활용해라
점진적으로 마이크로서비스로 넘어가는게 좋은 방법일 수 있다.
6. 아키텍처와 조직을 맞춰라
아키텍처는 조직 구조를 닮는다.
조직 간 이관이나 사일로를 줄여야함
여러 직능을 한 조직에 모아 줄인다.
프론트팀,백엔드팀,db팀 -> 고객팀,구매팀
결국 비즈니스 도메인 -> 시스템 아키텍처를 주도
e커머스 -> (고객/주문/배송 .. )
1. 독립적 배포
2. 비즈니스 도메인을 중심으로 모델링
3. 데이터베이스/ 데이터를 공유하지 말아라
4. 마이크로서비스의 크기는 내 머리가 이해할 수 있는정도
5. 유연함
6. 아키텍처와 조직을 맞춰라