MSA 설계시 참고 사항.

1. 서비스 경계 설정

  • 각 서비스의 크기는 DDD에서, 도메인 모델을 설정 한뒤에 나오는 경계지어진 컨텍스트 당 한 서비스가 이상적임.
  • 다른곳에 의존이 없는 지율적인 기능에 대해서는 단독 서비스로 뺄 수도 있다.
  • SRP 를 적용하여 구분 지을 수 있다.
  • 서비스 하나를 하나의 제품으로 생각 할 수 있을 정도가 좋다.

2. 오케스트레이션

  • 아마존이나 도커, 쿠버네티스를 사용함이 일반적일 수 있다.
  • 기본적으로 어떤걸 사용하든 서비스 오케스트레이션, 수평확장을 위해 각각의 서비스가 각각의 영구 상태 값등 을 갖고있으면 안된다..
  • 기본적인 데이터 스토어관련 서비스들의 분리,,, (RDBMS, ElasticSearch, Hadoop, MongoDB등등..))

3. 룰엔진 에 대해?

  • 룰이 단순하고 하나의 서비스 내부에서만 사용된다면 비즈니스 룰 코딩이 낫다.
  • 룰이 복잡하다면 룰엔진을 사용하되 하나의 서비스에 내장된 룰 엔진 사용이 좋다.
  • 여러가지 룰 이 외부 요건에 의해 작성되고, 변경 될 수 있따면 외부 룰 저장소를 사용하는 방식도 고려해봐야한다.

4. 각각의 서비스 인스턴스의 물리적인 위치.

  • 이건 최대한 자유롭게 짜야한다. 하나의 물리서버에 여러 서비스가 같이 있을 수도 있고, 하나의 서비스가 오케스트레이션으로 수평 확장 할 수도 있다.
  • ElasticSearch Node와 클러스터링 구조 개념 참조.

5. 데이터 스토어에 대한 공유

  • 2번에서 오케스트레이션에서도 나온지만 데이터 스토어가 공유 되는 자원 인지에 대한 여부는 기본적으로 msa자체 에서도 이는 중요한 이슈임.
  • 공유 되지 않는 방식으로 짜는게 제일 베스트( 완벽한 분리.. )
  • 그게 안된다면 저장소 인터페이스 서비스를 따로 둬서 간접적으로 비즈니스로직도 분리 되도록 처리 하는게 좋음.

6. 트랜젝션 경계 설정

  • MSA를 너무 잘게 쪼게서 트랜젝션이 여러 서비스에 걸쳐 나타나면 FailOver, Managing 등등에서 관리포인트들이 많이생김!!!
    • Ti 이슈… ㅠㅜ
  • 최종적 일관성
    • 중간에서 일관성이 깨질 수도 있지만 궁극적으로 맞추는 방식으로 설계 되어야 함.
  • ex) 특정 서비스 요청 시 트랜젝션으로 다 묶어서 결과를 알려주는 방식이 아닌, 과정을 보여주고 결과는 따로 호출 하게 비동기로 바꾸는 식으로 트랜젝션 분리.
    • NoSQL에서의 데이터 입력 방식은 각각의 테이블로 각자 insert하는것이 아닌 전체 DB를 한꺼번에 Insert한다. (결과는 select로 확인해야함.)
  • 트랜젝션 과정에서 외부의 다른 서비스와의 통신이 연계가 된다면 그건 제일 뒤로 미루는게 안전.

7. 종단점 설계 (api, 등등) 고려사항

  • KISS (Keep it simple stupid) 최대한 서비스 사용 방식은 단순하게!!
  • YAGNI 괜히 미리 필요없는 기능 만들지 않기!
  • 진화적 설계 (단순히 작업해놓고 리팩토링하면서 추가개발)
  • CDC 소비자 주도 계약
    • 종단점 설계 먼저 해두고 그에 맞춰 개발, BDD할 때에도 그런걸로 하면서 개발!
  • 프로토콜은 요즘 거의 JSON
  • MessageQueue 고려
  • API 문서화!
    • Swagger
    • RAML
    • ApiDoc
    • Api블루프린트?

8. 서비스 프론트단 설계

  • HATEOAS 고려!
  • API Gateway를 이용하여 웹페이지가 여러 서비스를 조합해야 하는 걸 줄이도록 할 수도 있음
  • 각 서비스당 네트워크 고려하려면 Gateway를 각각 할 수도 있음!

9. 공유 라이브러리에 관하여

  • 음.. nexus 잘 이용하고,,, 라이브러리로 쓰는게 어떰?
  • Utils같은거 공유라이브러리로 잘…

10. 버저닝 고려

  • 메이저.마이너.패치
  • 메이저가 api변겅건
  • 마이너는 하위호환정도
  • 패치는 api변경 없는 버그픽스

11. 크로스 오리진

  • 스프링에서 쉽게 지원해줌
  • 서로다른 도메인간에서의 처리?
  • 프론트에서 서비스하는게 아닌 내부 처리로직중에서 사용

12. 공유데이터!!

  • 5번내용
  • 아무리 MSA를 잘 해도 공유 데이터는 필수 불가결함
    • 앞단에서 applayer에서의 join, 조합방식
    • 공유데이터 복제 방식 (클러스터링 이슈)
    • 사전 배치 처리 방식
    • 각각의 서비스에서 캐싱 하는 방식(동기화 이슈)