마이크로 서비스를 구축하는데 있어 저자의 지침을 소개하는 책

• 분해 기술의 종류

  • 마이크로 서비스
    • 서비스를 세분화
  • 공유 라이브러리
    • 코드베이스를 여러 라이브러리로 분해하는 방식
    • 단점
      • 이기종성을 얻을 수 없다
      • 동적 라이브러리가 아니고서는 배포, 확장이 어렵다
      • 경계가 불명확하다
  • 모듈
    • OSGI, JPMS 처럼 수명 주기 관리가 가능한 분해 기술
    • 복잡하고 비용이 너무 크다

• 아키텍트의 역활

  • 도시 설계자처럼 도시를 구역화하는 일을 담당
  • 구역 내의 업무보다는 구역의 경계에서 벌어지는 일을 더 걱정해야 한다
  • 원칙의 수는 적을 수록 좋다
  • 모니터링, 인터페이스의 종류, 안정성에 유의 해야 한다

• 마이크로 서비스

  • SOA에 대한 특정한 구현 방식
  • 2주 안에 재 작성 될 수 있는 작고 탄력적인 서비스
  • 장점
    • 기술 이 기종성: 서비스에 가장 유용한 기술을 자유롭게 도입할 수 있다
    • 회복성: 격벽(bulkhead)을 이용한 장애의 비 전파성
    • 확장성, 배포 용이성
  • 단점
    • 개발자의 작업 방식에 많은 제약을 가하는 조직이 있다면 운영하기 힘들다
    • 복잡도가 높다

• 서비스의 경계

  • 경계를 확정 짓는 중요한 요소는 느슨한 결합과 강한 응집력이다
  • 서비스의 경계가 도메인 컨텍스트와 정렬되고( 1: 1 대응 ), 서비스가 이 경계를 잘 표현한다면 매우 좋다
  • 너무 작게 분해하지 마라 → 큰 경계에서 작게 분해하는 것이 더 쉽다
  • 조직 구조에 따라 경계를 분할해라 → 서비스가 각기 다른 팀에 의해 관리된다면 최상위 마이크로 서비스 일 가능성이 높다

• 서비스 통합

  • 서비스를 어떻게 협업하고 구성할 것인가? 에 대한 고민
  • 원격 인터페이스와 지역 인터페이스에 대한 API 디자인은 별개로 생각해야 한다
  • 서비스가 전략적 자산이면 직접 개발, 그 외에는 솔루션을 구매해도 된다
  • Client와 협업 방법
    • 공유 데이터베이스
      • 외부에서 내부의 구현 상세를 조회하고 결합하는 것을 허용
      • 소비자에게 특정 기술을 선택하는 범위를 제한함
      • 응집력이 매우 떨어짐
    • 동기 전송 방식 ( ex: Rest )
      • 요청/응답 스타일인 동기식
      • 가장 보편적인 방법
      • 더럽게 느리고 비싸다 → RPC나 이벤트 방식에 비해
    • 원격 프로시져 호출(RPC)
      • 매우 쉬운 사용성 → 사용성이 좋으나 베이스 작업이 힘들 수 있음
      • 기술 결합이 강하게 일어남 → 서버의 변경은 클라이언트도 변경해야 한다
      • 원격 호출의 복잡성은 은폐한다 → 장점이자 단점
      • 네트워크가 은폐 될 정도로 너무 추상화하지 말아라
    • 이벤트 기반의 각자 업무를 처리하는 비동기식
      • 미들웨어를 멍청하게, 엔드 포인트를 지능적으로 만들어야 한다 → 안 그러면 결국 ESB 꼴 난다
      • 구현 방식
        • 오케스트레이션: 특정 서비스가 중앙 두뇌처럼 프로세스를 구동한다
        • 코레오그래피: 각 시스템에 작업 내용을 알리고 세부 사항을 각자 수행하게 한다
          • 프로세스를 모니터링하고 추적하는 부가 작업 필요
      • 복잡도가 매우 높아진다
  • 상태 기계로서의 서비스는 매우 중요한 개념이다!!!! → 핵심 도메인의 생명 주기 및 상태 변경은 서비스가 스스로 해야 한다
  • 코드의 재 사용성과 DRY (don’t repeat yourself )
    • 행동 양식(behavior) 와 지식( knowledge)의 중복을 회피하려는 시도
    • 저자는 개별 서비스의 DRY 위반은 주의해야 하지만 전체 서비스는 너무 걱정하지 말라고 한다
    • 클라이언트 라이브러리를 제공하는 것은 오히려 늘어난 결합 비용을 초래하며 업데이트 시점을 클라이언트가 핸들링 할 수 없게 한다
  • 참조에 의한 접근
    • 메일 등을 통해 도메인의 정보를 전달 할 때 직접 내용이 아닌 URL에 대한 참조를 제공하는 방식
    • 이벤트가 발생 할 때와 현재 상태를 비교 할 수 있고 생명 주기를 컨트롤 가능하다
  • 버전 관리
    • API 버전의 변경은 가능하면 지양하라
    • 전송할 때(request)는 보수적으로, 받아 들일 때(response)는 자유롭게 하라
    • semantic versionning: X.Y.Z 방식의 버전 방식으로 X는 Major ( 하위 호환성이 깨진 변경). Y는 Minor( 기능 추가 ). Z 는 Patch ( Bug fix ) 방식이다
  • API 생명 주기 관리
    • 확장/수축 패턴을 이용하자
      • 과거/최신 버전의 API가 공존하도록 시스템을 운영한다
      • V1의 요청을 V2로 , V2의 요청을 V3로 보내도록 유도한다
      • V1을 삭제하고 남은 코드를 제거한다
      • V2를 제거하고 남은 코드를 제거한다
  • API 구성
    • 모바일, 웹이 너무 많은 API를 호출하는 방식은 좋지 않다
    • API Gateway
      • Gateway 를 이용하여 다수의 하부 호출을 모아 한번에 전송한다
    • UI 부분 구성 ( ex: Server Driven UI )
      • 서비스가 UI를 제공하고, 웹페이지를 이를 레이아웃에 맞게 조정하는 방식
      • UI 간 교차 상호 작용이 많을 때는 사용하지 말아야 한다
    • BFF(Backend for frondend)
  • 교살자(Strangler) Pattern

• 서비스 분해

• 서비스 배포

• 서비스 테스트

• 모니터링