안녕 친구들! 이전 토론에서 우리는 Apache Camel과 Quarkus의 통합에 대해 자세히 알아보고 Apache Camel을 사용하여 실제 애플리케이션을 제작하는 방법을 시연했습니다. 시리즈를 계속하면서 Apache Camel의 중요한 구성 요소와 본질적인 세부 사항에 대해 자세히 알아보는 것을 목표로 합니다.
기본적으로 Apache Camel은 Gregor Hohpe와 Bobby Woolf가 쓴 Enterprise Integration Patterns(EIP) 책에 소개된 개념을 중심으로 구성되어 있습니다. 이 책에서는 엔터프라이즈 애플리케이션 전반에 걸쳐 강력한 통합 솔루션을 설계하고 문서화하기 위해 표준화된 다양한 패턴을 간략하게 설명합니다
또는 시스템. 다음은 Apache Camel에서 활용되는 몇 가지 핵심 패턴에 대한 개요입니다.
Aggregator 패턴(그림 1)은 관련 메시지를 응집력 있는 단일 메시지로 수집 및 통합하여 포괄적인 처리를 촉진하는 데 필수적입니다. 이는 전체 데이터 세트가 수신될 때까지 상관된 메시지를 축적하는 특수 필터 역할을 하며, 이 시점에서 집계된 출력을 게시합니다
추가 처리를 위해.
그림 1 – 집계 패턴(enterpriseintegrationpatterns.com)
이 패턴(그림 2)은 콘텐츠에 따라 메시지를 적절한 수신자에게 동적으로 라우팅합니다. 라우팅 결정은 필드 존재 여부 또는 특정 필드 값과 같은 다양한 메시지 속성에 따라 달라질 수 있습니다.
그림 2 – 콘텐츠 기반 라우터 패턴(enterpriseintegrationpatterns.com)
동적 라우터(그림 3)는 외부에서 정의된 규칙에 따라 또는 사용자 입력을 통해 동적으로 조정하고 현대적인 서비스 지향 아키텍처를 지원하여 런타임 시 라우팅 결정을 용이하게 합니다.
그림 3 – 동적 라우터 패턴(enterpriseintegrationpatterns.com)
메시지 필터(그림 4)는 메시지를 출력 채널로 보내거나 지정된 기준에 따라 메시지를 삭제하여 특정 조건을 충족하는 메시지만 추가로 처리되도록 합니다.
그림 4 – 메시지 필터 패턴(enterpriseintegrationpatterns.com)
이 패턴(그림 5)은 비즈니스 프로세스의 단계 순서를 조정하여 실행 순서와 발생하는 예외를 모두 처리합니다. 순차 처리 및 오류 관리가 중요한 복잡한 워크플로우를 뒷받침합니다.
그림 5 – 프로세스 관리자 패턴(enterpriseintegrationpatterns.com)
노멀라이저 패턴(그림 6)은 서로 다른 시스템 간의 메시지 형식 불일치 문제를 해결하는 Apache Camel의 중요한 도구입니다. 다양한 형식의 수신 메시지를 가져와 추가 처리 전에 표준화된 형식으로 변환하여 데이터 처리 파이프라인 전반에 걸쳐 일관성을 보장합니다. 이 패턴은 메시지가 다양한 형식의 다양한 소스에서 발생하는 환경에서 특히 유용합니다.
그림 6 – 노멀라이저 패턴(enterpriseintegrationpatterns.com)
여러 데이터 항목으로 구성된 복잡한 메시지 처리는 Splitter 패턴을 통해 간소화됩니다(그림 7). 이 패턴은 복합 메시지를 구성 요소로 효율적으로 나누어 각 요소를 독립적으로 처리할 수 있도록 합니다. 이는 메시지의 여러 부분을 개별 특성에 따라 다르게 라우팅하거나 처리해야 하는 시나리오에서 매우 유용합니다.
그림 7 – 분할 패턴(enterpriseintegrationpatterns.com)
이것들은 Apache Camel에서 사용되는 패턴 중 일부에 불과하다는 점을 언급해야 합니다. Apache Camel에는 더 많은 패턴이 사용됩니다. 하지만 저는 이 패턴이 가장 중요하다고 생각합니다.
기본적으로 Apache Camel 프레임워크는 강력한 라우팅 엔진, 더 정확하게는 라우팅 엔진 빌더를 중심으로 구성됩니다. 이 엔진을 사용하면 개발자는 맞춤형 라우팅 규칙을 고안하고, 메시지를 수락할 소스를 결정하고, 해당 메시지를 처리하고 다양한 대상으로 디스패치하는 방법을 정의할 수 있습니다. Apache Camel은 복잡한 비즈니스 프로세스에서 발견되는 것과 유사한 통합 언어를 통해 복잡한 라우팅 규칙의 정의를 지원합니다.
Camel의 주요 원칙 중 하나는 데이터에 구애받지 않는 특성입니다. 이러한 유연성은 개발자가 데이터를 미리 정의된 표준 형식으로 변환해야 하는 엄격한 요구 사항 없이 모든 유형의 시스템과 상호 작용할 수 있도록 하기 때문에 매우 중요합니다. 다양한 데이터 양식을 원활하게 처리할 수 있는 능력 덕분에 Camel은 모든 시스템 통합업체의 툴킷에 포함된 다용도 도구가 되었습니다.
Apache Camel 영역에서 메시지는 메시징 채널을 통해 시스템 간 통신을 촉진하는 기본 엔터티입니다. 이러한 구성 요소는 (그림 8)에 나와 있습니다. 경로 실행 과정에서 메시지는 변경, 복제,
등 다양한 변형을 겪을 수 있습니다.
또는 프로세스의 특정 요구 사항에 따라 완전히 교체됩니다. 메시지는 본질적으로 발신자에서 수신자로 단방향으로 흐르며 여러 구성 요소로 구성됩니다.
본문(페이로드): 메시지의 주요 내용입니다.
헤더: 키와 해당 값을 포함할 수 있는 메시지와 관련된 메타데이터입니다.
첨부파일: 메시지와 함께 보낼 수 있는 선택적 파일
그림 8 – Apache Camel 메시지 구조
Apache Camel의 메시지는 java.lang.String 유형의 식별자로 고유하게 식별됩니다. 이 식별자의 고유성은 메시지 작성자에 의해 적용되며 사용된 프로토콜에 따라 달라집니다. 하지만 형식 자체는 표준화되지 않았습니다. 고유한 메시지 식별 체계가 없는 프로토콜의 경우 Camel은 자체 ID 생성기를 사용합니다.
Camel 메시지의 헤더는 보낸 사람 식별자, 콘텐츠 인코딩에 대한 힌트, 인증 데이터 등과 같은 메타데이터가 포함된 키-값 쌍 역할을 합니다. 각 헤더 이름은 고유하고 대소문자를 구분하지 않는 문자열이며, 값은 Camel의 유연한 헤더 유형 처리를 반영하는 임의의 객체(java.lang.Object)일 수 있습니다. 모든 헤더는 메시지 내에 맵으로 저장됩니다.
또한 메시지에는 웹 서비스 및 이메일 거래와 관련된 맥락에서 일반적으로 사용되는 선택적 첨부 파일이 포함될 수 있습니다. 역시 java.lang.Object 유형의 메시지 본문은 모든 형태의 콘텐츠를 수용할 수 있는 다목적입니다. 이러한 유연성으로 인해 애플리케이션 디자이너는 다양한 시스템에서 콘텐츠를 이해할 수 있어야 합니다. 이를 지원하기 위해 Camel은 필요한 경우 자동 유형 변환을 포함한 다양한 메커니즘을 제공하여 데이터를 발신자와 수신자 모두가 호환 가능한 형식으로 변환함으로써 다양한 환경에서 원활한 데이터 통합을 촉진합니다.
Apache Camel에서 Exchange는 Camel 경로를 통해 데이터를 탐색하는 중추적인 메시지 컨테이너입니다. (그림 9)에 설명된 대로 메시지를 캡슐화하여 Camel 경로 내에서 사전 정의된 일련의 단계를 통해 메시지 변환 및 처리를 지원합니다. Exchange는 다음과 같은 org.apache.camel.Exchange 인터페이스를 구현합니다.
그림 9 – Apache Camel 교환
Exchange는 특히 요청-응답 패턴을 강조하면서 다양한 스타일의 메시징을 수용하도록 설계되었습니다. 메시지 처리 중에 예외가 발생할 경우 결함이나 오류에 대한 정보를 전달할 만큼 강력합니다.
거래소 ID: 거래의 고유 식별자로 추적성을 보장하기 위해 Camel에서 자동으로 생성합니다.
메시지 교환 패턴 MEP: InOnly 또는 InOut 중 메시징 스타일을 지정합니다. InOnly의 경우 트랜잭션에는 들어오는 메시지만 포함됩니다. InOut의 경우 응답을 개시자에게 다시 전달하기 위해 추가로 나가는 메시지(Out Message)가 존재합니다.
예외 - Exchange는 라우팅 중에 발생하는 예외를 캡처하여 오류 관리를 중앙 집중화하여 쉽게 처리하고 완화할 수 있습니다.
본문: 각 메시지(In 및 Out)에는 다양한 콘텐츠 유형을 허용하는 java.lang.Object 유형의 페이로드가 포함되어 있습니다.
헤더: 맵으로 저장되는 헤더에는 메시지와 관련된 키-값 쌍이 포함되어 라우팅 신호, 인증 키, 기타 상황별 정보와 같은 메타데이터를 전달합니다.
속성: 헤더와 유사하지만 교환 전체에 지속되는 속성은 메시지 처리 수명 주기 전반에 걸쳐 관련된 전역 수준 데이터를 보유합니다.
메시지 내용: 기본 구성 요소인 이 필수 요소는 인바운드 채널에서 들어오는 요청 데이터를 캡슐화합니다.
아웃 메시지: InOut 교환에 존재하는 선택적 구성 요소로 응답 데이터를 아웃바운드 채널로 전달합니다.
Apache Camel에서 Exchange는 Camel 경로를 통해 데이터를 전달하는 메시지 컨테이너입니다. 이는 메시지를 캡슐화하고 Camel 경로에 정의된 일련의 처리 단계에 걸쳐 메시지를 변환하고 처리할 수 있도록 합니다. 또한 Exchange는 요청-응답 메시징 패턴을 용이하게 하며 메시지 처리 중에 예외가 발생할 경우 오류 또는 오류 정보를 전달할 수 있습니다.
Apache Camel 컨텍스트는 Apache Camel의 필수 요소로, 통합 프레임워크의 기능을 조정하는 핵심 프레임워크 역할을 합니다. 라우팅 규칙, 구성, 구성 요소 및 추가 통합 요소가 수렴되는 곳입니다. Camel 컨텍스트(그림 10)는 포함된 모든 구성 요소와 경로의 수명 주기를 초기화, 구성 및 감독합니다.
그림 10 – Apache Camel 컨텍스트
Camel 컨텍스트 내에서는 다음과 같은 중요한 작업이 촉진됩니다.
구성 요소 및 데이터 형식 로드: 여기에는 다양한 경로에서 사용되는 구성 요소 및 데이터 형식의 초기화 및 가용성 관리가 포함됩니다.
경로 구성: 다양한 엔드포인트에서 메시지가 처리되고 조정되는 방식에 대한 규칙을 포함하여 메시지가 따르는 경로를 정의하는 메커니즘을 제공합니다.
경로 시작 및 중지: Camel 컨텍스트는 경로의 활성화 및 비활성화를 관리하여 이러한 작업이 스레드로부터 안전한 방식으로 수행되도록 합니다.
오류 처리: 컨텍스트 내의 모든 경로에서 활용할 수 있는 중앙 집중식 오류 처리 메커니즘을 구현합니다.
리소스 관리: 스레드 풀이나 연결과 같은 리소스를 효율적으로 관리하고 더 이상 필요하지 않을 때 적절하게 해제합니다.
Camel 컨텍스트는 프로그래밍 방식으로 또는 선언적으로 구성할 수 있습니다. 예를 들어 Java 기반 설정에서는 다음과 같습니다.
import org.apache.camel.CamelContext;
import org.apache.camel.impl.DefaultCamelContext;
public class MainApp {
public static void main(String[] args) {
CamelContext camelContext = new DefaultCamelContext();
try {
// Add routes, components, etc.
camelContext.start();
Thread.sleep(10000);
} catch (Exception e) {
e.printStackTrace();
} finally {
try {
camelContext.stop();
} catch (Exception e) {
// Handle exception
}
}
}
}
Quarkus와 같은 환경의 경우 Camel Context는 일반적으로 다음과 같이 검색 및 관리됩니다.
@Inject CamelContext context;
if (context.isStarted()) {
context.getRouteController().startRoute("start_route");
}
Quarkus를 활용하면 Camel Context가 자동으로 프로비저닝되고 관리됩니다.
@ApplicationScoped
public class DemoRoute extends RouteBuilder {
@Override
public void configure() throws Exception {
from("direct:start_route")
.log("Starting route: ${routeId}, headers: ${headers}")
.setHeader("header_abc", constant("header_value"))
.to("direct:route_1")
.to("direct:route_3");
}
}
Apache Camel에서 엔드포인트는 Camel 애플리케이션을 외부 시스템 또는 서비스와 연결하기 위한 인터페이스를 나타냅니다. 경로가 시작(소비)되거나 끝나는(생산) 지점입니다.
몇 가지 일반적인 엔드포인트 유형은 다음과 같습니다.
// Route to read files from the directory "input" and move
processed files to "output"
from("file:input?move=processed")
.to("file:output");
// Route to consume data from an HTTP service
from("timer:foo?period=60000")
.to("http://example.com/api/data")
.to("log:result");
// Using direct for synchronous call
from("direct:start")
.to("log:info");
Camel의 경로는 일련의 프로세서 또는 변환을 통합하여 엔드포인트 간의 메시지 흐름을 정의합니다. 이는 Camel 애플리케이션 내에서 처리 논리를 구성하는 데 중요합니다.
다음은 일련의 상호 연결된 경로를 보여주는 예입니다.
@ApplicationScoped
public class DemoRoute extends RouteBuilder {
@Override
public void configure() throws Exception {
from("direct:start_route")
.log("Starting route: ${routeId}, headers: ${headers}")
.setHeader("header_abc", constant("header_value"))
.to("direct:route_1")
.to("direct:route_3");
from("direct:route_1")
.log("Starting route_1: ${routeId}, headers: ${headers}, thread: ${threadName}")
.process(
exchange -> {
exchange.getIn().setHeader("header_abc", "UPDATED_HEADER_VALUE");
})
.to("direct:route_2");
from("direct:route_2")
.log("Starting route_2: ${routeId}, headers: ${headers}, thread: ${threadName}");
}
}
여기서 첫 번째 경로는 direct:start_route 엔드포인트에서 시작하고, RouteId와 헤더를 기록하고, header_abc 키로 새 헤더를 설정한 후 메시지를 다음 경로 direct:route_1로 전달합니다. 두 번째 경로는 RouteId, 헤더 및 스레드 이름을 기록한 후 메시지를 다음 경로 direct:route_2로 전달합니다. 세 번째 경로는 RouteId, 헤더 및 스레드 이름을 기록합니다.
Apache Camel에 대한 자세한 탐색에서 우리는 Apache Camel을 기업 통합 영역에서 필수적인 도구로 만드는 핵심 개념과 필수 구성 요소를 살펴보았습니다. EIP(엔터프라이즈 통합 패턴)에 대한 철저한 조사를 시작으로 Camel이 Aggregator, Splitter 및 Normalizer와 같은 패턴을 활용하여 일반적인 통합 문제를 효과적으로 해결하는 방법을 이해했습니다.
또한 Camel의 아키텍처 기본 사항을 자세히 조사하여 Camel의 다양한 라우팅 기능, 유연한 메시지 모델, 이러한 요소를 관리하고 조정하는 데 있어서 Camel Context의 중추적인 역할을 강조했습니다. 또한 외부 시스템과의 통신을 용이하게 하는 다양한 엔드포인트 유형을 살펴보는 것과 함께 경로가 정의되고 관리되는 방법을 시연하는 등 실용적인 측면도 다루었습니다.
위 내용은 Apache Camel의 핵심 기능 및 구성 요소 탐색의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
