# 마이크로 서비스 설계 원칙

1. 비즈니스 도메인을 중심으로 모델링

도메인 기반 설계를 통해 더욱 안정된 서비스를 구축하고 다양한 사용자 인터페이스에 대해 보다 쉽게 각 서비스들을 재결합 할 수 있다.

2. 자동화 문화

많은 수의 마이크로서비스의 복잡성을 관리하려면 자동화가 필수적이다.

• CI/CD
• 빌드 파이프라인 단계에서의 SIT(System Integration Testing) & UAT(User Acceptance Testing) 테스트
• 프로비저닝, OS 구성, 서비스 이미지 생성 등

3. 구현 세부 정보 숨기기

서비스가 독립적으로 변경되고 진화할 수 있도록 각 서비스의 구현 세부 정보를 숨겨야 한다. 필요한 정보는 DB에 직접 접근하는 것이 아닌 각 서비스 API를 통해서 얻어야 한다.

4. 모든 것을 분권화하기

각 서비스는 자체 결정을 내릴 수 있어야 하며 그 안에서 완전한 자율성을 가질 수 있어야 한다.

• Service Ochestration
  : 중앙 집중식 접근 방식
  
  
• Service Choreography
  : 느슨하게 결합된 접근 방식
  
  

5. 독립적으로 배포

서비스 구성 요소를 변경하는 경우 다른 구성 요소를 변경하지 않고 프로덕션으로 릴리스할 수 있어야 한다.

6. 소비자 우선

당신의 서비스가 호출되기 위해 존재한다는 생각을 가지고 있어야 한다. 따라서 소비자 관점에서 디자인을 하고 API Docs 도구를 사용하여 API를 문서화하는 것은 필수적이다.

7. 오류 격리

기본적으로 마이크로서비스는 신뢰할 수 없다는 것을 전제로 설계해야 한다. 계단식 오류를 방지하기 위해 각 오류를 격리함으로써 시스템 복원력을 높이는 것이 중요하다.

• Timeout
  : 모든 프로세스간 호출에 대한 시간 제한과 기본 초과 시간을 설정한다.
• Bulkhead
  : 원격 호출을 서로 격리하고 원격 서비스 호출을 자체 스레드 풀로 분리한다.
• Circuit breaker
  : 느리게 실행되고 성능이 저하된 시스템 호출을 종료해 자원 고갈을 방지한다.

일부 서비스 호출의 실패가 전체 서비스 자원을 고갈시켜서는 안된다.
✅ Hystrix: 대표적인 오류 격리 서비스

1. 지정한 오류율을 초과한 경우 발생
2. 회로의 상태를 CLOSE -> OPEN 변경
3. 회로가 열린 상태에서 모든 요청에 대해 fallback method(대체함수) 실행
4. 지정 시간이 지난 후 HALF OPEN(하나의 요청만 원래 method로 실행) 수행
5. HALP OPEN이 성공하면 회로 상태 CLOSE, 실패하면 다시 OPEN

8. 높은 수준의 모니터링

시스템에서 무슨일이 일어나고 있는지 알기 위해서 충분한 입력과 로그가 생성되어야 한다. 또한 보다 높은 수준의 모니터링을 위해서 상태 체크, 중앙 집중식 로그 및 통계 집계, 상관 관계 ID를 사용한 분산 추적 등이 가능해야 한다.

 

 

[참고사이트](https://learncsdesign.medium.com/microservices-design-principles-b62499b583bc)