마이크로서비스에서 카프카를 사용하는 방법

Unsplash 에 있는 Mathyas Kurmann의 사진

영형애플리케이션 워크플로가 가질 수 있는 가장 흥미롭고 도전적인 주제 중 하나는 메시지/이벤트 기반 디자인 입니다. 장기적으로 성공과 실패의 차이일 수도 있습니다.

제시된 모든 코드는 Github에서 사용할 수 있습니다. 기사 끝에 있는 " 유용한 리소스" 섹션을 통해 쉽게 액세스할 수 있습니다 .

# 색인

아키텍처 설명
카프카가 뭐야?
실제 예
결론
유용한 리소스

# 아키텍처 설명

Unsplash 의 Anders Jildén 의 사진

이미 알고 계시겠지만 서비스 커플링은 항상 피해야 하는 것입니다. 그렇지 않으면 적용된 변경 사항이 다른 서비스에 상당한 영향을 미칩니다.

타이트한 아키텍처의 문제를 해결하기 위해 우리는 두 가지 아키텍처에 의존하는 경향이 있습니다.

이벤트 중심 아키텍처(EDA)
메시지 기반 아키텍처(MDA)

이 패턴의 새로운 점은 무엇입니까? 상태의 변화를 나타내는 이벤트를 전달하기 위해 메시지를 사용하는 개념.

애플리케이션에 새로운 기능을 빠르게 추가하려면 서비스가 다른 서비스에서 내보내는 이벤트/메시지 스트림 수신을 시작하기만 하면 됩니다.

내가 항상 생각하는 가장 좋은 예는 메모리 캐시 업데이트입니다.

클라이언트 및 주소 서비스 를 생성했다고 상상해 보십시오 . 누군가 클라이언트를 요청할 때마다 주소 서비스에서 나머지 데이터를 가져와야 합니다. 불행히도, 이 서비스는 그러한 데이터를 가져오는 데 상당한 시간이 걸리고 데이터는 때때로 한 번만 업데이트되므로 어쨌든 캐시하기로 결정했습니다.

결합 아키텍처를 사용하면 주소가 업데이트될 때마다 캐시된 데이터를 취소해야 합니다. 따라서 모든 업데이트에서 주소 서비스는 캐시 해지를 위해 클라이언트 서비스에 연결해야 합니다. 새 서비스뿐만 아니라 주소 서비스 자체 도 업데이트해야 합니다 .

EDA/MDA 아키텍처를 사용 하면 변경 사항이 발생했음을 알리기 위해 주소 서비스 만 필요합니다 . 그러면 모든 이해 당사자가 메시지를 받고 캐시된 데이터를 취소합니다.

중요한 개념:

주제 —서비스가 메시지를 배치하거나 읽을 수 있는 메시지 버킷 .
소비자 — 특정 주제 를 듣고 있는 서비스입니다. 새 메시지가 도착할 때마다 버킷 에서 제거 하고 처리합니다.
Producer — 관심 있는 사람들이 그에 따라 행동할 수 있도록 주제 에 메시지를 추가합니다

장점:

느슨한 결합 — 두 서비스 모두 데이터 업데이트 문제와 관련하여 서로에 대해 알지 못합니다.
내구성 — 소비자 서비스가 중단된 경우에도 메시지가 배달되도록 보장합니다. 소비자가 다시 일어날 때마다 모든 메시지가 거기에 있을 것입니다.
확장성 — 메시지가 버킷에 저장되기 때문에 응답을 기다릴 필요가 없습니다. 우리는 모든 서비스 간에 비동기 통신을 만듭니다.
유연성 — 메시지 발신자는 누가 메시지를 사용할지 모릅니다. 더 적은 작업으로 새로운 소비자(새로운 기능)를 쉽게 추가할 수 있음을 의미합니다.

단점:

의미 체계 — 개발자는 엄격한 요구 사항인 메시지 흐름을 깊이 이해해야 합니다. 복잡한 대체 접근 방식이 발생할 수 있습니다.
메시지 가시성 — 문제가 발생할 때마다 디버그할 수 있도록 모든 메시지를 추적해야상관 ID가 옵션일 수 있습니다.

메시징은 복잡하지만 동시에 강력할 수 있습니다.

# 카프카가 뭐야?

카프카가 뭐야

Kafka는 LinkedIn에서 처음 개발하고 2011년에 오픈 소스로 제공한 오픈 소스 게시/구독 시스템입니다. 분산 이벤트 시스템이라고도 합니다.

메시지 는 보존 정책 으로 알려진 특정 기간 동안 디스크에 유지 됩니다.

Kafka의 주요 목표는 실시간 데이터 스트림을 처리하고 데이터 파이프라인을 구축하기 위한 안정적이고 높은 처리량 플랫폼을 제공하는 것입니다. 다음과 같은 현대적이고 확장 가능한 시스템을 만들 수 있습니다.

ETL (추출, 변환, 로드)
CDC (변경 데이터 캡처)
BDI (빅 데이터 수집)

구조적으로는 클러스터라고 하는 크기가 조정된 구성 요소가 있습니다. 클러스터 내부에는 브로커라고도 하는 여러 서버가 있습니다. 우리는 일반적으로 충분한 중복성을 제공하기 위해 최소 3명의 브로커를 보유합니다.

각 브로커는 생산자로부터 메시지를 수신하고 해당 메시지를 디스크에 커밋할 책임이 있습니다. 브로커는 또한 소비자의 가져오기 요청에 응답하고 서비스를 제공할 책임이 있습니다.

Kafka에서는 메시지가 브로커에게 전송될 때 특정 주제로 전송됩니다. 위 섹션에서 언급한 주제를 통해 데이터를 분류할 수 있습니다. 데이터는 결국 여러 파티션으로 분할될 수 있습니다.

주제를 여러 파티션으로 분할하여 각 파티션을 별도의 소비자가 읽을 수 있으므로 확장성을 촉진합니다.

Kafka는 시스템의 모든 이벤트에 대한 중앙 허브입니다.

# 실제 예

kafka를 사용한 스프링 부트

이 실제 예제에서는 아키텍처 섹션에서 사용된 메모리 캐시 예제를 선택했습니다.

소비자와 생산자라는 두 가지 서비스가 있습니다.

생산자는 HTTP 요청을 수신할 책임이 있습니다. 각 요청에서 여러 데이터 업데이트를 생성합니다. 이러한 데이터 업데이트는 해당 데이터를 캐시하는 서비스를 통해 전파되어야 합니다. 메시지 시스템을 통해 모든 이해 당사자는 주제 메시지를 통해 알림을 받습니다.

소비자는 주제를 듣고 새 메시지를 받을 때마다 그에 따라 데이터를 취소합니다.

요구 사항:

스프링 부트 → 작동하고 구성 가능한 예제를 쉽게 가질 수 있습니다.
Docker → 모든 환경에서 모든 것을 실행할 수 있습니다.
Apache Kafka → 메시지 기반 서버.

다음 링크 를 사용하여 docker-compose를 설치합니다 .

2. Spring Initializer 에 접속 하여 다음 속성으로 Spring 프로젝트를 생성한 후 ' 생성'을 클릭합니다.

프로듀서 프로젝트 이니셜라이저

3. 소비자를 위해 1단계를 반복합니다.

소비자 프로젝트 이니셜라이저

4. 다운로드한 두 개의 압축을 푼 폴더를 만듭니다.

5. docker-compose.yml 이라는 파일 을 만들고 아래 내용을 추가합니다. 이를 통해 애플리케이션에 연결할 Kafka 클러스터를 정의합니다.

버전 → 도커 버전.
서비스 → 동일한 docker-compose 내의 모든 서비스는 서로 볼 수 있습니다. docker가 해당 위치를 확인하므로 통신 목적으로 서비스 이름을 사용할 수 있습니다.

참고: 자동 생성 주제를 비활성화하면 주제를 직접 생성하도록 지정합니다.

6. 두 서비스를 모두 시작하려면 아래 docker 명령만 실행하면 됩니다.

다음 컨테이너를 사용할 수 있어야 합니다.

명령: docker ps

7. 비즈니스 로직을 코딩할 시간입니다. 각 마이크로 서비스에 대해 "2개의 패키지" 구조가 있습니다.

구성 → 생산자/소비자 구성.
컨트롤러 → REST 또는 메시지 컨트롤러.

8. 먼저 생산자를 구성합니다. 종속성 파일에 아래 구성을 삽입합니다.

참고: Lombok은 생성자, 설정자 및 게터에 의해 생성된 일부 상용구를 제거할 수 있는 종속성입니다.

9. 응용 프로그램 구성 파일 내에서 아래 속성을 추가해 보겠습니다.

10. 생산자 구성을 완료하는 데 두 단계 더 가까워졌습니다. 속성 판독기 클래스를 만듭니다.

참고: Lombok @Data 주석은 빌드 시 해당 생성자, getter 및 setter를 생성합니다.

11. 마지막으로 생산자 구성 구성 요소를 소개합니다.

지도를 통해 생산자 구성을 주입하는 것으로 시작합니다. 이 예에서는 기본 항목을 추가합니다. 키에는 Kafka의 문자열 직렬 변환기를 사용하고 값에는 JSON 직렬 변환기를 사용합니다.
생산자 공장을 정의합니다. 주로 생산자 구성을 사용자 지정하고 있기 때문입니다.
Kafka 템플릿을 사용하여 Kafka 서버에 메시지를 보냅니다. 우리는 결국 여러 유형의 객체를 지원하기를 원하므로 객체 값이 있습니다.
새로운 주제를 주입함으로써 우리는 Kafka에게 그것을 생성하도록 지시합니다.

12. 구성 세트를 사용하여 메시지와 해당 컨트롤러를 통해 이동할 개체만 정의하면 됩니다.

HTTP 생성 엔드포인트가 호출 될 때마다 x 메시지가 생성되어 캐시에서 제거하려는 엔티티와 함께 Kafka 서버로 전송됩니다.

http://localhost:8002/produce 를 호출할 때마다 다음과 같은 결과를 볼 수 있어야 합니다 .