강의 08: 샘플 애플리케이션을 마이크로서비스로 나누는 방법
Lesson 07에서 Domain-Driven Design의 기본 개념을 소개한 후, 본 강의에서는 Domain-Driven Design과 관련된 아이디어를 마이크로서비스 분야에서 적용하는 방법을 소개한다.
마이크로서비스 부문
마이크로서비스 아키텍처 애플리케이션의 설계 및 구현에서 가장 중요한 작업을 찾으려면 비마이크로서비스의 구분 이어야 합니다 . 마이크로 서비스 아키텍처의 핵심은 여러 협력 마이크로 서비스로 구성된 분산 시스템입니다.마이크로 서비스 분할이 완료된 후에야 각 마이크로 서비스의 책임을 명확히하고 마이크로 서비스 간의 상호 작용 모드를 결정한 다음 진행하는 API 설계의 API 설계 각 마이크로 서비스는 각 마이크로 서비스의 최종 구현, 테스트 및 배포입니다.
위의 프로세스에서 볼 수 있듯이 마이크로서비스 부서는 애플리케이션 설계 및 구현의 전체 체인에서 첫 번째 링크입니다. 체인의 각 링크의 변경 사항은 후속 링크에 영향을 미치며 마이크로 서비스 부문의 첫 번째 링크로서 변경 사항이 있으면 모든 후속 링크에 영향을 미칩니다. 마지막으로 원하는 것은 마이크로서비스를 구현하는 동안 일부 기능을 다른 마이크로서비스로 마이그레이션해야 한다는 사실을 깨닫는 것입니다. 이 경우 관련 마이크로 서비스의 API 및 구현을 모두 수정해야 합니다.
물론 실제 개발에서 마이크로서비스의 분할 변경을 완전히 회피하는 것은 비현실적이다. 마이크로서비스 분할 단계에서 분석에 충분한 에너지를 쏟는다면 얻을 수 있는 이점은 절대적으로 큽니다.
마이크로서비스 및 제한된 컨텍스트
07교시에서는 Domain-Driven Design에서 Defined Context 개념을 소개했는데, Domain-Driven Design 개념을 마이크로서비스 아키텍처에 적용하면 마이크로서비스와 정의된 컨텍스트가 일대일로 대응할 수 있다. . 각각의 경계가 있는 컨텍스트는 마이크로서비스에 직접 해당하며 컨텍스트 매핑 패턴을 사용하여 마이크로서비스 간의 상호 작용 방식을 정의합니다.
이와 같이 마이크로서비스의 분할 문제는 Domain-Driven Design에서 정의한 컨텍스트 분할의 문제로 전환된다. Domain Driven Design에 대해 이미 확실하게 이해하고 있다면 이점이 있고, 그렇지 않은 경우 Lesson 07의 내용을 통해 빠르게 시작할 수 있습니다.
구체적인 설명을 위해 이 칼럼의 샘플 애플리케이션을 예로 들어 보겠습니다.
샘플 애플리케이션의 마이크로서비스 파티셔닝
06과에서는 샘플 애플리케이션의 사용자 시나리오를 소개합니다. 이러한 시나리오를 기반으로 애플리케이션의 도메인을 결정할 수 있습니다. 실제 애플리케이션 개발에는 보통 도메인 전문가와 비즈니스 담당자가 참여해야 하며, 비즈니스 담당자와의 커뮤니케이션을 통해 도메인에 대한 보다 명확한 이해를 할 수 있습니다. 예제 애플리케이션은 애플리케이션 도메인이 비교적 생활에 가깝기 때문에 관련 소개를 단순화하기 위해 도메인 분석을 직접 수행합니다. 그러나 이는 개발자가 수행한 도메인 분석이 반드시 실제 비즈니스 프로세스를 반영하지 않는다는 단점이 있습니다. 그러나 샘플 애플리케이션의 경우 이 정도면 충분합니다.
도메인 중심 설계는 도메인을 핵심으로 삼고 도메인은 문제 공간 과 솔루션 공간 으로 나뉩니다 .
문제 공간은 비즈니스 수준에서 생각하는 데 도움이 되며 핵심 도메인과 필요에 따라 다른 하위 도메인을 포함하는 핵심 도메인이 의존하는 도메인의 일부입니다. 핵심 도메인은 우리가 개발할 소프트웨어 시스템의 핵심이기 때문에 처음부터 새로 만들어야 합니다. 다른 하위 도메인이 이미 존재하거나 처음부터 새로 만들어야 할 수도 있습니다. 문제 공간의 핵심 문제는 하위 필드를 식별하고 분할하는 방법입니다.
그런 다음 솔루션 공간은 하나 이상의 제한된 컨텍스트와 컨텍스트 내의 모델로 구성됩니다. 이상적으로는 정의된 컨텍스트와 하위 도메인 간에 일대일 대응이 있습니다. 이러한 방식으로 비즈니스 수준에서 분할을 시작한 다음 구현 수준에서 동일한 분할 방법을 채택하여 문제 공간과 솔루션 공간의 완벽한 통합을 실현할 수 있습니다. 실제로는 정의된 컨텍스트와 하위 필드 간에 일대일 대응이 있을 가능성이 없습니다. 소프트웨어 시스템을 구현할 때 일반적으로 기존 레거시 시스템 및 외부 시스템과 통합해야 하며 이러한 시스템에는 자체적으로 정의된 컨텍스트가 있습니다. 실제로는 여러 개의 제한된 컨텍스트가 동일한 하위 필드에 속하거나 하나의 제한된 컨텍스트가 여러 하위 필드에 해당하는 것이 더 현실적입니다.
Domain-Driven Design의 아이디어는 도메인에서 시작하여 먼저 하위 도메인을 나눈 다음 하위 도메인에서 정의된 컨텍스트와 컨텍스트의 모델을 추상화하는 것입니다.정의된 각 컨텍스트는 마이크로 서비스에 해당합니다.
핵심 분야
핵심 도메인은 소프트웨어 시스템의 가치가 존재하는 곳이며, 디자인의 출발점이기도 합니다. 소프트웨어 시스템을 시작하기 전에 소프트웨어 시스템의 핵심 가치를 명확하게 이해해야 합니다.그렇지 않다면 먼저 소프트웨어 시스템의 판매 포인트를 고려해야 합니다.소프트웨어 시스템마다 핵심 영역이 다릅니다. 택시 호출 애플리케이션으로서 그 핵심 영역은 승객을 빠르고 편안하고 안전하게 이동시키는 방법이며, 이는 Didi Taxi 및 Uber와 같은 택시 호출 애플리케이션의 핵심 영역이기도 합니다. 예를 들어 행복한 여행 애플리케이션의 경우 이러한 핵심 영역이 너무 커서 행복한 여행 애플리케이션은 핵심 영역을 단순화하고 승객이 빠르게 여행할 수 있는 방법에만 집중합니다.
핵심 도메인에 적절한 이름을 지정해야 합니다. 차를 불러야 하는 승객과 여행 서비스를 제공하는 기사를 어떻게 빠르게 매칭하느냐가 행복한 여행의 핵심 영역이다. 사용자가 여정을 생성하면 시스템은 이를 이용 가능한 운전자에게 배포하고, 운전자가 여정을 수신하면 시스템은 여정을 배포할 운전자를 선택합니다. 핵심 영역은 여정 발송에 중점을 두므로 이름은 여정 배포 입니다 .
현장의 개념
그런 다음 도메인의 개념을 열거합니다. 떠오르는 관련 개념을 하나씩 화이트보드에 나열하는 브레인스토밍 과정입니다. 여정에서 출발하여 승객과 운전자의 개념을 도출할 수 있습니다.여객은 여정의 개시자이고 운전자는 여정의 완성자입니다.각 여정에는 시작 지점과 종료 지점이 있으며 해당 개념은 주소. 운전자는 개인 차량을 사용하여 여행을 완료하므로 차량은 또 다른 개념입니다.
우리는 개념을 기반으로 다른 하위 분야를 찾고 여행의 개념은 핵심 분야에 속합니다. 운전자와 승객은 다양한 독립된 하위 도메인에 속해 별도로 관리되어야 하므로 승객 관리 와 운전자 관리 라는 두 개의 하위 도메인이 생깁니다 . 주소의 개념은 주소 관리 의 하위 필드 에 속 하고 차량의 개념은 운전자 관리의 하위 필드에 속합니다.
하위 도메인을 도메인의 개념으로 나눈 후 다음 단계는 도메인의 작업에서 새 하위 도메인을 계속 검색하는 것입니다. 사용자 시나리오에서 여정을 확인해야 한다고 언급되며 이 작업에는 해당 하위 필드 여정 확인이 있습니다 . 여행이 완료된 후 승객은 결제를 해야 하며 이 작업에는 해당 하위 필드 결제 관리가 있습니다 .
다음 그림은 샘플 애플리케이션의 하위 영역을 보여줍니다.
제한된 컨텍스트
핵심 도메인과 기타 하위 도메인을 식별한 후 다음 단계는 문제 공간에서 솔루션 공간으로 이동하는 것입니다. 먼저 하위 도메인을 구분 컨텍스트에 매핑하고 구분 컨텍스트는 하위 도메인과 동일한 이름을 가진 다음 구분 컨텍스트를 모델링하고 모델링의 주요 작업은 관련 개념을 구체화하는 것입니다.
여정 배포
일정 디스패치 모델에서 중요한 엔터티는 일정이 상주하는 집계의 루트이기도 한 일정입니다. 여행에는 값 개체 주소로 표현되는 시작 및 종료 위치가 있습니다. 여정은 승객에 의해 시작되므로 여정 엔터티에는 승객에 대한 참조가 있어야 합니다 시스템이 여정을 수락할 드라이버를 선택하면 여정 엔터티에는 드라이버에 대한 참조가 있습니다. 전체 수명 주기 동안 여행은 다른 상태에 있을 수 있으며 여행의 상태를 설명하는 속성 및 해당 열거 유형이 있습니다.
아래 그림은 모델의 엔터티 및 값 개체를 보여줍니다.
승객 관리
Passenger Management 모델에서 중요한 엔터티는 Passenger이며 이는 Passenger가 상주하는 Aggregate의 루트이기도 합니다. 승객 엔터티의 속성에는 이름, 이메일 주소, 연락처 번호 등이 포함됩니다. 승객 엔터티에는 연결된 저장된 주소 목록이 있으며 주소는 엔터티입니다.
아래 그림은 모델의 엔터티를 보여줍니다.
드라이버 관리
드라이버 관리 모델에서 중요한 엔터티는 드라이버이며 드라이버가 상주하는 집계의 루트이기도 합니다. 운전자 엔터티의 속성에는 이름, 이메일 주소, 연락처 등이 포함됩니다. 집계에는 운전자 엔터티 외에 차량 엔터티도 포함됩니다. 차량 엔터티의 속성에는 제조업체, 모델, 제조 날짜 및 라이센스가 포함됩니다. 번호판.
아래 그림은 모델의 엔터티를 보여줍니다.
주소 관리
주소 관리 모델에서 중요한 엔터티는 주소이며 성, 지방자치단체 및 자치구에서 마을 및 거리에 이르는 계층적입니다. 계층적 주소 외에도 또 다른 중요한 정보, 즉 경도와 위도를 포함한 지리적 위치 좌표가 있습니다.
여정 확인
여정 확인 모델에는 특정 엔터티가 포함되지 않지만 여정을 확인하는 서비스 및 관련 알고리즘 구현이 포함됩니다.
결제 관리
지불 관리 모델에서 중요한 엔터티는 여정 참조 및 지불 상태와 같은 정보가 포함된 지불 기록입니다.
제한된 컨텍스트 간의 상호 작용
정의된 컨텍스트의 모델에서 여정 디스패치 모델의 여정 엔터티는 승객 관리 모델의 집합 "승객"의 루트 엔터티와 드라이버 관리 모델의 집합 "드라이버"의 루트 엔터티를 참조해야 합니다. . Lesson 07에서 외부 객체는 Aggregate의 루트 엔터티만 참조할 수 있으며 참조할 때 엔터티 자체가 아니라 Aggregate의 루트 엔터티 식별자를 참조해야 한다고 언급했습니다. Passenger 엔터티와 Driver 엔터티의 식별자는 모두 문자열 유형이므로 Trip 엔터티에는 각각 Passenger 엔터티와 Driver 엔터티를 참조하는 String 유형의 두 속성이 포함됩니다.
동일한 개념이 다른 구분된 컨텍스트의 모델에 나타날 때 매핑이 필요하며 매핑을 위해 Lesson 07에서 언급한 컨텍스트 매핑 모드를 사용할 수 있습니다.
주소 관리 및 여정 디스패치 컨텍스트 모두에서 주소라는 개념이 있습니다. 주소 관리의 주소 엔터티는 다단계 주소 선택 및 주소 쿼리를 실현하기 위한 다양한 수준의 지명을 포함하는 복잡한 구조입니다. 일정 발송의 맥락에서 주소는 단순히 전체 이름과 지리적 위치 좌표로 구성됩니다. 두 컨텍스트 사이를 매핑하기 위해 모델 변환을 위해 출장 파견 컨텍스트에 부식 방지 레이어를 추가할 수 있습니다.
기존 모놀리식 애플리케이션의 마이그레이션
이 컬럼의 샘플 애플리케이션은 처음부터 새로 만든 애플리케이션이므로 마이크로서비스를 구분할 때 참고할 기존 구현이 없습니다. 기존의 모놀리식 애플리케이션을 마이크로서비스 아키텍처로 마이그레이션할 때 마이크로서비스의 구분이 더 추적 가능할 것입니다. 그들의 책임에 따라 그들을 나누는 것이 좋습니다. 이렇게 분할된 마이크로서비스가 실제 운영 상황에 더 가깝습니다.
ThoughtWorks의 Sam Newman은 저서 "Building Microservices"에서 SnapCI 제품의 마이크로서비스 부문 경험을 공유했습니다. 오픈 소스 프로젝트 GoCD의 관련 경험으로 인해 SnapCI 팀은 SnapCI의 마이크로서비스를 신속하게 분할했습니다. 그러나 GoCD와 SnapCI의 사용자 시나리오에는 약간의 차이가 있습니다.시간이 지난 후 SnapCI 팀은 현재 마이크로 서비스 부서가 많은 문제를 가져왔다는 것을 발견했습니다.그들은 종종 여러 마이크로 서비스에 걸쳐 약간의 변경을 해야 하므로 높은 오버헤드가 발생합니다. . .
SnapCI 팀이 한 일은 이러한 마이크로서비스를 다시 단일 모놀리식으로 병합하여 시스템이 실제로 어떻게 실행되고 있는지 이해할 수 있는 시간을 더 많이 주는 것이었습니다. 1년 후 SnapCI 팀은 이 모놀리식 시스템을 마이크로서비스로 재분할했고, 이 분할 이후 마이크로서비스의 경계는 더욱 안정되었습니다. SnapCI의 이 예는 마이크로서비스를 분할할 때 도메인 지식이 중요하다는 것을 보여줍니다.
요약하다
마이크로서비스 파티셔닝은 마이크로서비스 아키텍처의 애플리케이션 개발에서 매우 중요합니다. Domain-Driven Design의 아이디어를 적용하여 마이크로 서비스의 구분을 Domain-Driven Design의 하위 도메인 구분으로 변환한 다음 정의된 컨텍스트를 통해 도메인의 개념을 모델링합니다. 정의된 컨텍스트 간의 매핑 패턴을 통해 모델 변환을 수행할 수 있습니다.
강의 09: 신속한 배포 개발 환경 및 프레임워크
이 수업은 "신속 배포 개발 환경 및 프레임워크"에 관련된 내용을 소개합니다.
이전 수업시간에는 클라우드 네이티브 마이크로서비스 아키텍처와 관련된 배경지식을 소개하였고, 다음 수업시간에는 실제 마이크로서비스 개발에 들어가게 됩니다. 이 수업은 마이크로서비스 개발과 관련된 첫 번째 수업으로, 로컬 개발 환경을 준비하는 방법에 초점을 맞추고 샘플 애플리케이션에서 사용되는 프레임워크, 타사 라이브러리 및 도구를 소개합니다.
개발에 필요한
개발 전제 조건은 개발 환경에 필요한 것을 말합니다.
자바
샘플 애플리케이션의 마이크로서비스는 Java 8을 기반으로 개발되었습니다. Java 14가 출시되었지만 샘플 애플리케이션은 이전 Java 8 버전이 여전히 널리 사용되고 있고 Java 8 이후에 추가된 새로운 기능이 샘플 애플리케이션에 유용하지 않기 때문에 여전히 이전 Java 8 버전을 사용합니다. JDK 8이 설치되지 않은 경우 AdoptOpenJDK 웹 사이트로 이동하여 OpenJDK 8 설치 프로그램을 다운로드하는 것이 좋습니다 . MacOS 및 Linux에서는 SDKMAN!을 사용하여 JDK 8을 설치하고 다양한 버전의 JDK를 관리할 수 있습니다.
다음은 java -version의 출력입니다.
openjdk 버전 "1.8.0_242" OpenJDK 런타임 환경(AdoptOpenJDK)(빌드 1.8.0_242-b08) OpenJDK 64비트 서버 VM(AdoptOpenJDK)(빌드 25.242-b08, 혼합 모드)
메이븐
샘플 애플리케이션에서 사용하는 빌드 도구는 Apache Maven이며, Maven 3.6을 수동으로 설치하거나 IDE에 내장된 Maven을 사용하여 프로젝트를 빌드할 수 있습니다. HomeBrew 는 MacOS 및 Linux에 권장되며 Chocolatey는 Windows에 권장됩니다 .
통합 개발 환경
좋은 IDE는 개발자 생산성을 크게 향상시킬 수 있습니다. IDE의 경우 IntelliJ IDEA와 Eclipse의 두 가지 선택이 있으며 IDE 선택의 경우 둘 사이에 큰 차이가 없으며 IntelliJ IDEA Community Edition 2020을 사용합니다.
도커
로컬 개발 환경은 Docker를 사용하여 데이터베이스 및 메시지 미들웨어를 포함하여 애플리케이션에 필요한 지원 서비스를 실행해야 합니다. Docker를 통해 다양한 소프트웨어 서비스의 설치 문제가 해결되어 개발 환경 구성이 매우 간단해집니다. 반면 애플리케이션의 프로덕션 및 실행 환경은 Kubernetes이며 컨테이너화를 사용하여 배포되어 개발 환경과 프로덕션 환경 간의 일관성을 보장합니다. 로컬 개발 프로세스를 단순화하기 위해 Docker Compose는 컨테이너 오케스트레이션을 위한 로컬 환경에서 사용됩니다.
개발 환경의 운영체제에 따라 Docker를 설치하는 방법이 다릅니다. Docker를 설치하는 데 사용할 수 있는 3가지 Docker 제품, 즉 Docker Desktop, Docker Toolbox 및 Docker Engine이 있으며 다음 표는 이러한 3가지 제품의 해당 플랫폼을 보여줍니다. MacOS 및 Windows의 경우 버전에서 지원하는 경우 Docker Desktop을 먼저 설치한 다음 Docker Toolbox를 고려해야 합니다.
Docker Desktop 제품은 Docker Engine, Docker Command Line Client, Docker Compose, Notary, Kubernetes 및 Credential Helper를 비롯한 많은 구성 요소로 구성됩니다. Docker Desktop의 장점은 더 나은 통합을 제공할 수 있는 운영 체제에서 제공하는 가상화 지원을 직접 사용할 수 있다는 것입니다.또한 Docker Desktop은 그래픽 관리 인터페이스도 제공합니다. 대부분의 경우 docker 명령줄을 통해 Docker를 작동합니다. docker -v 명령이 올바른 버전 정보를 표시할 수 있으면 Docker Desktop이 성공적으로 설치된 것입니다.
아래 그림은 Docker Desktop의 버전 정보를 보여줍니다.
Docker Toolbox는 Docker Desktop의 전신입니다. Docker Toolbox는 가상화를 위해 시스템 요구 사항이 낮은 VirtualBox를 사용합니다. Docker Toolbox는 Docker Machine, Docker Command Line Client, Docker Compose, Kitematic 및 Docker Quickstart Terminal로 구성됩니다. 설치가 완료되면 Docker Quickstart를 통해 터미널을 실행하여 docker 명령을 실행합니다.
아래 그림은 Docker Quickstart 터미널의 실행 효과입니다.
Linux에서는 Docker 엔진만 직접 설치할 수 있으며 Docker Compose도 수동으로 설치해야 합니다.
Docker Desktop과 Docker Toolbox 사용에는 상당한 차이가 있습니다. Docker Desktop에서 실행되는 컨테이너는 현재 개발 환경 호스트에서 네트워크를 사용할 수 있으며, 컨테이너가 노출하는 포트는 localhost를 사용하여 액세스할 수 있습니다. 가상 머신 IP 주소를 통해 액세스합니다. 192.168.99.100과 같이 Docker Quickstart로 시작한 터미널에서 docker-machine ip 명령을 통해 IP 주소를 얻을 수 있습니다. 컨테이너에 의해 노출된 포트는 고정되지 않은 이 IP 주소를 사용하여 액세스해야 합니다. 권장 방법은 호스트 파일에 dockervm이라는 호스트 이름을 추가하고 이 IP 주소를 가리키는 것입니다. 컨테이너의 서비스에 액세스할 때는 항상 dockervm 호스트 이름을 사용하십시오. 가상 머신의 IP 주소가 변경되면 호스트 파일만 업데이트하면 됩니다.
쿠버네티스
애플리케이션을 배포할 때 사용 가능한 Kubernetes 클러스터가 필요하며 일반적으로 Kubernetes 클러스터를 만드는 방법에는 세 가지가 있습니다.
첫 번째 방법은 클라우드 플랫폼을 사용하여 . 많은 클라우드 플랫폼이 Kubernetes를 지원합니다. 클라우드 플랫폼은 Kubernetes 클러스터의 생성 및 관리를 담당합니다. 웹 인터페이스 또는 명령줄 도구만 사용하면 Kubernetes 클러스터를 빠르게 생성할 수 있습니다. 클라우드 플랫폼을 사용하면 시간과 노력을 절약할 수 있다는 장점이 있지만 비용이 많이 듭니다.
두 번째 방법은 가상 머신 또는 물리적 베어메탈에 Kubernetes 클러스터를 설치하는 것 입니다 . 가상 머신은 클라우드 플랫폼에서 제공하거나 자체적으로 생성 및 관리할 수 있으며 자체적으로 유지 관리하는 물리적인 베어메탈 클러스터를 사용하는 것도 가능합니다. RKE , Kubespray , Kubicorn 등과 같은 많은 오픈 소스 Kubernetes 설치 도구가 있습니다. 이 방식의 장점은 상대적으로 오버헤드가 적다는 점이지만, 사전 설치 및 사후 유지보수가 필요하다는 단점이 있습니다.
세 번째 방법은 로컬 개발 환경에 Kubernetes를 설치하는 것 입니다 . Docker Desktop은 이미 Kubernetes와 함께 제공되므로 활성화하기만 하면 되고 Minikube 도 설치할 수 있습니다 . 이 방식의 장점은 오버헤드가 가장 적고 제어가 용이하다는 점이며, 단점은 로컬 개발 환경에서 많은 리소스를 차지한다는 것입니다.
위의 세 가지 방법 중 클라우드 플랫폼 방식이 프로덕션 환경의 배포에 적합합니다. 테스팅 및 딜리버리 준비(스테이징) 환경은 클라우드 플랫폼을 선택하거나 비용 측면에서 직접 환경을 구축하도록 선택할 수 있습니다. 로컬 개발 환경의 Kubernetes도 많은 경우에 필요합니다.
로컬 개발 환경에서 Docker Desktop용 Kubernetes를 수동으로 활성화해야 합니다. Minikube의 경우 공식 문서를 참조하여 설치할 수 있습니다. 이 둘의 차이점은 Docker Desktop과 함께 제공되는 Kubernetes 버전이 일반적으로 몇 가지 부 버전 뒤에 있다는 것입니다. 아래 그림과 같이 "Kubernetes 활성화" 옵션을 선택하여 Kubernetes 클러스터를 시작합니다. Docker Desktop과 함께 제공되는 Kubernetes 버전은 1.15.5이고 최신 Kubernetes 버전은 1.18입니다.
프레임워크 및 타사 라이브러리
샘플 애플리케이션은 아래에 간략하게 소개된 몇 가지 프레임워크와 타사 라이브러리를 사용합니다.
스프링 프레임워크와 스프링 부트
Spring 프레임워크 없이 Java 애플리케이션을 개발하는 것은 어렵습니다. Spring Boot는 또한 현재 Java로 마이크로서비스를 개발하는 데 널리 사용되는 선택 중 하나입니다.Spring 및 Spring Boot의 소개는 이 칼럼의 범위를 벗어납니다. 샘플 애플리케이션의 마이크로서비스는 Spring Data JPA, Spring Data Redis 및 Spring Security를 포함하여 Spring 프레임워크의 일부 하위 프로젝트를 사용합니다.
결국 트램
Eventuate Tram은 샘플 애플리케이션에서 사용하는 트랜잭션 메시지 프레임워크로, 트랜잭션 메시지 모드는 데이터 일관성을 유지하는 데 중요한 역할을 합니다. Eventuate Tram은 트랜잭션 메시징 패턴에 대한 지원을 제공하며 비동기 메시징에 대한 지원도 포함합니다. Eventuate Tram은 PostgreSQL 및 Kafka와 통합됩니다.
Axon 서버 및 프레임워크
샘플 애플리케이션도 이벤트 소싱 및 CQRS 기술을 사용하고 이벤트 소싱 구현은 Axon 서버 및 Axon 프레임워크를 사용합니다. Axon 서버는 이벤트 스토리지를 제공하고 Axon 프레임워크는 Axon 서버에 연결하여 CQRS 지원을 제공합니다.
지원 서비스 및 도구
샘플 애플리케이션의 지원 서비스는 런타임에 필요하며 관련 도구는 개발에 사용될 수 있습니다.
아파치 카프카와 주키퍼
샘플 애플리케이션은 서로 다른 마이크로서비스 간에 비동기 메시지를 사용하여 데이터의 최종 일관성을 보장하므로 메시지 미들웨어가 필요합니다. Apache Kafka는 샘플 애플리케이션에서 사용되는 메시지 미들웨어이며 Kafka를 실행하려면 ZooKeeper가 필요합니다.
PostgreSQL
샘플 애플리케이션의 일부 마이크로서비스는 관계형 데이터베이스를 사용하여 데이터를 저장합니다. 많은 관계형 데이터베이스 중에서 PostgreSQL이 예제 애플리케이션의 일부 마이크로 서비스에 대한 데이터베이스로 선택되었습니다.
데이터베이스 관리 도구
개발 과정에서 관계형 데이터베이스의 데이터를 확인해야 할 수도 있습니다. DBeaver , pgAdmin 4 , OmniDB 등 많은 PostgreSQL 클라이언트를 사용할 수 있습니다. IntelliJ IDEA의 Database Navigator 플러그인 과 같은 IDE 플러그인을 사용할 수도 있습니다 .
우편 집배원
개발 및 테스트에서 REST 서비스를 테스트하기 위해 HTTP 요청을 보내는 경우가 종종 있습니다 .Postman , Insomnia 및 Advanced REST Client 와 같은 REST 서비스 테스트와 관련된 많은 도구가 있습니다 . OpenAPI 사양 파일을 직접 가져오고 해당 REST 요청 템플릿을 생성할 수 있으므로 Postman을 사용하는 것이 좋습니다. 마이크로서비스는 API 우선 설계 접근 방식을 채택하므로 각 마이크로서비스 API에는 해당 OpenAPI 사양 파일이 있습니다. 개발 중에 OpenAPI 파일을 Postman으로 가져오기만 하면 테스트를 시작할 수 있으므로 수동으로 요청을 생성하는 작업을 줄일 수 있습니다.
요약하다
실제 전투를 설명하기 전에 먼저 로컬 개발 환경을 준비해야 합니다. 이 수업은 먼저 Java, Maven, 통합 개발 환경, Docker 및 Kubernetes를 설치하고 구성하는 방법을 소개한 다음 샘플 애플리케이션에서 사용되는 프레임워크 및 타사 라이브러리를 간략하게 소개하고 마지막으로 샘플 애플리케이션에서 사용하는 지원 서비스 및 개발에 필요한 도구.
강의 10: OpenAPI 및 Swagger를 사용한 API 우선 설계
이 수업을 시작으로 클라우드 네이티브 마이크로서비스 아키텍처 애플리케이션의 실제 개발에 들어가게 되며 마이크로서비스의 구체적인 구현을 소개하기 전에 먼저 각 마이크로서비스의 개방형 API를 설계하고 결정 합니다 . Open API는 최근 몇 년 동안 널리 보급되어 많은 온라인 서비스와 정부 기관에서 Open API를 제공하여 온라인 서비스의 표준 기능이 되었습니다. 개발자는 개방형 API를 사용하여 다양한 애플리케이션을 개발할 수 있습니다.
마이크로 서비스 애플리케이션의 개방형 API와 온라인 서비스의 개방형 API는 일정한 관계가 있지만 기능은 다릅니다. 마이크로 서비스 아키텍처의 애플리케이션에서 마이크로 서비스는 일반적으로 REST 또는 gRPC를 사용하는 프로세스 간 통신을 통해서만 상호 작용할 수 있습니다. 이러한 상호작용 방식은 정형화되어 개방형 API를 형성해야 하며, 마이크로서비스의 개방형 API는 서비스의 내부 구현 세부 사항을 외부 사용자로부터 보호하고 외부 사용자가 상호 작용할 수 있는 유일한 방법입니다. 물론 여기서는 API를 통해서만 마이크로 서비스 간의 통합을 의미하며, 비동기 이벤트가 통합에 사용되는 경우 이러한 이벤트도 대화식입니다. 이를 통해 마이크로서비스 API의 중요성을 알 수 있습니다. 청중의 관점에서 볼 때 마이크로 서비스 API의 사용자는 주로 다른 마이크로 서비스, 즉 주로 외부 사용자를 지향하는 온라인 서비스의 API와 다른 애플리케이션의 내부 사용자입니다. 다른 마이크로서비스 외에도 애플리케이션의 웹 인터페이스와 모바일 클라이언트도 마이크로서비스의 API를 사용해야 하지만 일반적으로 API 게이트웨이를 통해 마이크로서비스의 API를 사용합니다.
마이크로서비스 API의 중요성으로 인해 API를 매우 초기에 설계해야 합니다. 즉, API 우선 전략입니다.
API 우선 전략
온라인 서비스 API 개발 경험이 있으신 분들은 구현이 먼저 나오고 공개 API가 뒤따르는 경우가 많은데 이는 공개 API가 설계 이전에 고려되지 않고 나중에 추가되었기 때문입니다. 이 접근 방식의 결과 개방형 API는 API가 아닌 현재 실제 구현만 반영합니다. API 퍼스트(API First)의 설계 방식은 구체적인 구현보다 API의 설계를 우선시하는 것으로, API First는 API 사용자의 입장에서 API의 설계를 더 많이 고려해야 함을 강조한다.
구현 코드의 첫 줄을 작성하기 전에 API 제공자와 사용자는 API에 대해 충분히 논의하고 양측의 의견을 결합하여 최종적으로 API의 모든 세부 사항을 결정하고 정식 형식으로 수정하여 API 사양. 그런 다음 API 제공자는 실제 구현이 API 사양의 요구 사항을 충족하는지 확인하고 사용자는 API 사양에 따라 클라이언트 구현을 작성합니다. API 사양은 공급자와 사용자 간의 계약이며 많은 온라인 서비스 개발에 API 우선 전략이 적용되었습니다. API가 설계 및 구현된 후 온라인 서비스 자체의 웹 인터페이스 및 모바일 애플리케이션은 다른 타사 애플리케이션과 마찬가지로 동일한 API를 사용하여 구현됩니다.
API 우선 전략은 마이크로서비스 아키텍처의 애플리케이션 구현에서 더 중요한 역할을 합니다. 여기에서 두 가지 유형의 API를 구분할 필요가 있습니다. 하나는 다른 마이크로 서비스에 제공되는 API이고 다른 하나는 웹 인터페이스 및 모바일 클라이언트에 제공되는 API입니다. 07학번에서 Domain-Driven Design을 소개할 때 Bounded Context의 Mapping Mode에서 Open Host Service와 Public Language를 언급했는데 마이크로서비스는 Bounded Context에 일대일로 대응된다. 개방형 호스트 서비스와 공통 언어를 결합하면 마이크로 서비스의 API가 되고 공통 언어는 API의 사양입니다.
여기에서 우리는 첫 번째 유형의 마이크로 서비스 API의 목적이 컨텍스트 매핑이라는 것을 알 수 있으며 이는 두 번째 유형의 API 역할과 크게 다릅니다. 예를 들어 승객 관리 마이크로 서비스는 승객 등록, 정보 업데이트 및 쿼리를 포함하여 승객 관리를 위한 기능을 제공합니다. 승객 앱의 경우 이러한 기능은 API 지원이 필요하며, 다른 마이크로 서비스에서 승객 정보를 가져와야 하는 경우 승객 관리 마이크로 서비스의 API도 호출해야 합니다. 이는 서로 다른 마이크로 서비스 간에 승객의 개념을 매핑하기 위한 것입니다.
API 구현
API 구현에서 첫 번째 문제 중 하나는 API의 구현 방법을 선택하는 것입니다. 이론적으로 마이크로서비스의 내부 API는 상호 운용성에 대한 요구 사항이 높지 않으며 개인 형식을 사용할 수 있습니다. 단, 서비스 그리드를 사용하기 위해서는 공통 표준 포맷을 사용하는 것을 권장하며, 공통 API 포맷은 다음 표와 같다. SOAP를 적게 사용하는 경우를 제외하고는 일반적으로 REST와 gRPC 중에서 선택합니다. 이 둘의 차이점은 REST는 텍스트 형식을 사용하고 gRPC는 바이너리 형식을 사용한다는 것입니다. 요컨대 REST는 상대적으로 대중적이고 구현하기 어렵지만 성능은 gRPC만큼 좋지 않습니다.
이 칼럼의 샘플 애플리케이션용 API는 REST를 사용하여 구현되지만 gRPC 전용 클래스가 있습니다. 다음은 REST API와 관련된 OpenAPI 규격에 대한 설명입니다.
OpenAPI 사양
API 제공자와 사용자 간의 원활한 의사소통을 위해서는 API를 설명하는 표준 형식이 필요합니다. REST API의 경우 이 표준 형식은 OpenAPI 사양에 의해 정의됩니다.
OAS(OpenAPI 사양)는 Linux Foundation의 OAI(OpenAPI Initiative)에서 관리하는 개방형 API 사양입니다. OAI의 목표는 공급업체 중립적인 API 설명 형식을 생성, 발전 및 홍보하는 것입니다. OpenAPI 사양은 SmartBear Corporation에서 기증한 Swagger 사양을 기반으로 합니다.
OpenAPI 문서는 API를 설명하거나 정의하며 OpenAPI 문서는 OpenAPI 사양을 충족해야 합니다. OpenAPI 사양은 OpenAPI 문서의 콘텐츠 형식, 즉 포함할 수 있는 개체 및 속성을 정의합니다. OpenAPI 문서는 JSON 또는 YAML 파일 형식으로 표현할 수 있는 JSON 개체입니다. 다음은 OpenAPI 문서의 형식에 대한 소개이며, 이 강의의 코드 예제는 모두 YAML 형식을 사용합니다.
OpenAPI 사양에는 정수, 숫자, 문자열 및 부울과 같은 몇 가지 기본 유형이 정의되어 있습니다. 각 기본 유형에 대해 형식 필드를 통해 데이터 유형의 특정 형식을 지정할 수 있습니다. 예를 들어 문자열 유형의 형식은 날짜, 날짜-시간 또는 비밀번호일 수 있습니다.
OpenAPI 문서의 루트 개체에 나타날 수 있는 필드 및 해당 설명은 아래 표에 나와 있습니다.OpenAPI 사양의 최신 버전은 3.0.3입니다.
정보 개체
Info 개체에는 사용자가 API의 관련 정보를 더 잘 이해하는 데 도움이 되는 API의 메타데이터가 포함되어 있습니다. 다음 표에는 Info 개체에 포함될 수 있는 필드와 해당 설명이 나와 있습니다.
다음 코드는 Info 객체를 사용한 예제입니다.
제목: 테스트 서비스 설명: 이 서비스는 간단한 테스트에 사용됩니다. termOfService: http://myapp.com/terms/ 연락처: 이름: 관리자 url: http://www.myapp.com/support 이메일: support@myapp .com 라이선스: 이름: Apache 2.0 URL: https://www.apache.org/licenses/LICENSE-2.0.html 버전: 2.1.0
서버 개체
Server 객체는 API의 서버를 나타내며 다음 표는 Server 객체에 포함될 수 있는 필드와 설명을 보여줍니다.
다음 코드는 서버 객체를 사용하는 예로서, 서버의 URL은 port와 basePath라는 두 개의 매개변수를 포함하고, port는 열거형이며, 선택적 값은 80과 8080입니다.
URL: http://test.myapp.com:{port}/{basePath}
설명: 테스트 서버
변수:
포트:
열거형:
- '80'
- '8080'
기본값: '80'
basePath:
기본값: v2
경로 개체
Paths 개체의 필드는 동적입니다. 각 필드는 "/"로 시작하는 경로를 나타내며 경로는 변수를 포함하는 문자열 템플릿일 수 있습니다. 필드 값은 요약, 설명, 서버 및 매개 변수와 같은 일반 필드와 가져오기, 넣기, 게시, 삭제, 옵션, 헤드, 패치 및 추적을 포함하는 HTTP 메서드 이름을 사용할 수 있는 PathItem 개체입니다. , 메서드 이름 필드는 해당 경로에서 지원하는 HTTP 메서드를 정의합니다.
작업 개체
Paths 개체에서 HTTP 메서드에 해당하는 필드의 값 유형은 HTTP 작업을 나타내는 Operation 개체입니다. 다음 표는 Operation 객체에 포함될 수 있는 필드와 그에 대한 설명을 나타낸 것으로, 그 중 파라미터, requestBody, Response가 많이 사용됩니다.
매개변수 객체
Parameter 개체는 작업의 매개 변수를 나타냅니다. 다음 표에는 Parameter 개체에 포함될 수 있는 필드와 해당 설명이 나와 있습니다.
다음 코드는 Parameter 객체를 사용한 예제로, 경로에 파라미터 id가 나타나며 타입은 string입니다.
이름: id in: 경로 설명: 乘客ID 필수: true 스키마: 유형: 문자열
RequestBody 개체
RequestBody 객체는 HTTP 요청의 내용을 나타내며, 다음 표는 RequestBody 객체에 포함될 수 있는 필드와 설명을 보여줍니다.
응답 개체
Responses 개체는 HTTP 요청에 대한 응답을 나타내며 이 개체의 필드는 동적입니다. 필드의 이름은 HTTP 응답의 상태 코드이며 해당 값의 유형은 Response 또는 Reference 개체입니다. 다음 표는 응답 개체에 포함될 수 있는 필드와 해당 설명을 보여줍니다.
참조 객체
다른 유형의 개체에 대한 설명에서 필드 유형은 참조를 선언하는 $ref 필드만 포함하는 다른 구성 요소에 대한 참조를 나타내는 참조 개체일 수 있습니다. 참조는 동일한 문서 내의 구성 요소나 외부 파일에서 참조할 수 있습니다. 문서 내에서 다른 유형의 재사용 가능한 구성 요소는 Components 객체에서 정의되고 Reference 객체에서 참조할 수 있습니다. 문서 내 참조는 #/components/schemas/CreateTripRequest와 같이 #으로 시작하는 객체 경로입니다.
스키마 객체
Schema 객체는 데이터 타입의 정의를 기술하기 위해 사용되며, 데이터 타입은 단순 타입, 배열 또는 객체 타입이 될 수 있다. . 배열 유형인 경우, 즉 유형의 값이 배열인 경우 필드 항목을 사용하여 배열의 요소 유형을 나타내야 합니다. 객체 유형인 경우 즉 유형의 값이 객체입니다. , 필드 속성을 사용하여 개체의 속성 유형을 나타내야 합니다.
전체 문서 예제
다음은 전체 OpenAPI 문서의 예입니다. paths 객체에는 세 가지 작업이 정의되어 있으며 작업 요청 내용 및 응답 형식의 유형 정의는 Components 객체의 schemas 필드에 정의되어 있습니다. 작업의 requestBody 및 응답 필드는 모두 참조 개체를 사용하여 참조됩니다.
openapi: '3.0.3'
정보:
제목: 여행 서비스
버전: '1.0'
서버:
- url: http://localhost:8501/api/v1
태그:
- 이름: 여행
설명: 여행 관련
경로:
/:
게시물:
tags:
- 여행
요약: 여행 만들기
operationId: createTrip
requestBody:
내용:
애플리케이션/json:
스키마:
$ref: "#/components/schemas/CreateTripRequest"
required: 참
응답:
'201':
설명: 성공적으로 생성됨
/{tripId} :
얻다:
태그:
- 여행
요약: 여행 가져오기
operationId: getTrip
매개변수:
- 이름: tripId
입력: 경로
설명: 여행 ID
필수: 참
스키마:
유형: 문자열
응답:
'200':
설명: 성공
콘텐츠 가져오기:
애플리케이션/json:
스키마:
$ref: "#/components/schemas/TripVO"
'404':
설명: 여행을 찾을 수 없음
/{tripId}/accept:
게시:
태그:
- 여행
요약: 여행 수락
operationId: acceptTrip
매개변수:
- 이름: tripId
위치: 경로
설명: 行程ID
필수: 참
스키마:
유형: 문자열
requestBody:
내용:
애플리케이션/json:
스키마:
$ref: "#/components/schemas/AcceptTripRequest"
필수: 참
응답:
'200 ':
설명: 接受成功
components:
스키마:
CreateTripRequest:
유형: 개체
속성:
passengerId:
유형: 문자열
startPos:
$ref: "#/components/schemas/PositionVO"
endPos:
$ref: "#/components/schemas/PositionVO"
required:
- passengerId
- startPos
- endPos
AcceptTripRequest:
유형: 개체
속성:
driverId:
유형: 문자열
posLng:
유형: 숫자
형식: 이중
posLat:
유형: 숫자
형식: 이중
필수:
- driverId
- posLng
- posLat
TripVO:
유형: 객체
속성:
id:
유형: 문자열
passengerId:
유형: 문자열
driverId:
유형: 문자열
startPos:
$ref: "#/components/schemas/PositionVO"
endPos:
$ref: "#/components/schemas/PositionVO"
상태:
유형: 문자열
PositionVO:
유형: 개체
속성:
lng:
유형: 숫자
형식: double
lat:
유형: 숫자
형식: double
필수:
addressId:
유형: 문자열
-lng
-위도
OpenAPI 도구
일부 도구를 사용하여 OpenAPI 사양과 관련된 개발을 지원할 수 있습니다. OpenAPI 사양의 전신인 Swagger는 OpenAPI와 관련된 많은 도구를 제공합니다.
Swagger 편집기
Swagger 편집기는 Swagger 및 OpenAPI 문서 편집기의 웹 버전입니다. 편집기의 왼쪽에는 편집기가 있고 오른쪽에는 API 문서의 미리보기가 있습니다. Swagger 편집기는 구문 강조, 다양한 유형의 개체를 빠르게 추가, 서버 코드 생성 및 클라이언트 코드 생성 등 많은 유용한 기능을 제공합니다.
Swagger 편집기를 사용할 때 온라인 버전을 직접 사용 하거나 로컬에서 실행할 수 있으며 로컬에서 실행하는 가장 쉬운 방법은 Docker 이미지 swaggerapi/swagger-editor를 사용하는 것입니다.
다음 코드는 Swagger 편집기의 Docker 컨테이너를 시작합니다. 컨테이너가 시작된 후 localhost:8000을 통해 액세스할 수 있습니다.
docker run -d -p 8000:8080 swaggerapi/swagger-editor
아래 그림은 Swagger 편집기의 인터페이스입니다.
Swagger 인터페이스
Swagger 인터페이스는 API 문서를 보고 상호 작용할 수 있는 직관적인 방법을 제공합니다. 이 인터페이스를 통해 HTTP 요청을 API 서버에 직접 보내고 응답 결과를 볼 수 있습니다.
마찬가지로 Docker를 사용하여 아래 명령과 같이 Swagger 인터페이스를 시작할 수 있습니다. 컨테이너가 시작된 후 localhost:8010을 통해 액세스할 수 있습니다.
docker run -d -p 8010:8080 swaggerapi/swagger-ui
로컬 OpenAPI 문서의 경우 해당 문서를 사용하도록 Docker 이미지를 구성할 수 있습니다. 현재 디렉터리에 OpenAPI 문서 openapi.yml이 있다고 가정하면 다음 명령을 사용하여 Docker 이미지를 시작하여 문서를 표시할 수 있습니다.
도커 실행 -p 8010:8080 -e SWAGGER_JSON=/api/openapi.yml -v $PWD:/api swaggerapi/swagger-ui
아래 그림은 Swagger 인터페이스의 스크린샷입니다.
코드 생성
OpenAPI 문서를 통해 Swagger에서 제공하는 코드 생성 도구를 사용하여 서버 스텁 코드와 클라이언트를 자동으로 생성할 수 있습니다. 코드 생성을 위해 다양한 프로그래밍 언어와 프레임워크를 사용할 수 있습니다.
코드 생성 도구에서 지원하는 프로그래밍 언어 및 프레임워크는 다음과 같습니다.
aspnetcore, csharp, csharp-dotnet2, go-server, dynamic-html, html, html2, java, jaxrs-cxf-client, jaxrs- cxf, inflector, jaxrs-cxf-cdi, jaxrs-spec, jaxrs-jersey, jaxrs- di, jaxrs-resteasy-eap, jaxrs-resteasy, micronaut, spring, nodejs-server, openapi, openapi-yaml, kotlin-client, kotlin-server, php, python, python-flask, r, scala, scal a- akka -http-서버, swift3, swift4, swift5, typescript-angular, javascript
코드 생성 도구는 다운로드 후 바로 실행할 수 있는 자바 프로그램입니다. JAR 파일 swagger-codegen-cli-3.0.19.jar 를 다운로드한 후 다음 명령을 사용하여 Java 클라이언트 코드를 생성할 수 있습니다. 여기서 -i 매개변수는 입력 OpenAPI 문서를 지정하고 -l은 생성된 언어를 지정하며 - o 출력 목차를 지정합니다.
java -jar swagger-codegen-cli-3.0.19.jar 생성 -i openapi.yml -l java -o /tmp
클라이언트 코드 생성 외에도 서버 스텁 코드도 생성할 수 있습니다. 다음 코드는 NodeJS 서버 스텁 코드를 생성하는 것입니다.
java -jar swagger-codegen-cli-3.0.19.jar 생성 -i openapi.yml -l nodejs-server -o /tmp
요약하다
API 우선 전략은 마이크로서비스 API가 API 사용자의 요구 사항을 충분히 고려하여 설계되어 API가 공급자와 사용자 간의 좋은 계약이 되도록 합니다. 이 수업은 먼저 API의 설계 전략을 소개하고 API의 다양한 구현 방법을 소개한 다음 REST API의 OpenAPI 사양을 소개하고 마지막으로 OpenAPI의 관련 도구를 소개합니다.