비동기 메시징(특히 게시/구독 스타일 메시징)이 도메인 서비스 아키텍처로 실행 가능합니까, 아니면 SOA 중심 환경에서만 실행 가능합니까?

Question

저는 비동기 메시징을 연구해 왔으며 특정 도메인 내의 일부 문제를 우아하게 처리하는 방식과 도메인 개념을 보다 명확하게 만드는 방식을 좋아합니다.그러나 이것이 일반적인 도메인 중심 개발(적어도 서비스/애플리케이션/컨트롤러 계층에서)에 실행 가능한 패턴입니까, 아니면 원격 서비스 및 분산 처리와 같은 SOA 기반 시나리오로 제한되어야 하는 설계 오버헤드입니까?

Answer 1

좋은 질문입니다 :).비동기 메시징의 주요 문제점은 사람들이 절차적 또는 객체 지향 언어를 사용할 때 비동기식 또는 이벤트 기반 방식으로 작업하는 것이 종종 매우 까다롭고 복잡하며 프로그래머가 읽고 이해하기 어렵다는 것입니다.비즈니스 로직은 메소드를 호출하고 즉시 결과를 얻는 등 동기식으로 구축되면 훨씬 더 간단해지는 경우가 많습니다. :)

내 경험 법칙은 일반적으로 비즈니스 로직을 위해 미시적 수준에서 더 간단한 동기 프로그래밍 모델을 사용해 보는 것입니다.그런 다음 매크로 수준에서 비동기 및 SEDA를 사용하십시오.

예를 들어 구매 주문을 제출하면 메시지 대기열에 메시지를 쓸 수도 있습니다.그러나 구매 주문을 처리하려면 개별 단계를 병렬로 처리하는 많은 동시 프로세스 및 스레드가 있는 고성능 분산 시스템에서 모두 비동기식 및 병렬인 10개의 서로 다른 단계가 필요할 수 있습니다.따라서 매크로 레벨 배선은 SEDA 종류의 접근 방식을 기반으로 하지만 마이크로 레벨에서는 개별 10단계에 대한 코드가 대부분 동기식 프로그래밍 스타일로 작성될 수 있습니다.

Answer 2

많은 아키텍처 및 디자인 질문과 마찬가지로 대답은 "상황에 따라 다릅니다"입니다.

내 경험에 따르면 비동기 메시징의 강점은 디자인에 느슨한 결합을 가져온다는 것입니다.커플 링은 다음과 같습니다.

• 시간 - 요청을 비동기식으로 처리할 수 있어 전반적인 확장성에 도움이 됩니다.
• 공간 - 지적했듯이 많은 동기식 설계보다 더 강력한 방식으로 분산 처리가 가능합니다.
• 기술 - 메시지와 대기열은 기술 차이를 연결하는 한 가지 방법입니다.

메시지와 대기열은 다양한 구현이 가능한 추상화라는 점을 기억하세요.JMS 호환, 트랜잭션, 고성능 메시징 프레임워크를 반드시 사용할 필요는 없습니다.올바르게 구현되면 관계형 데이터베이스의 테이블은 행이 메시지인 대기열 역할을 할 수 있습니다.나는 두 가지 접근 방식이 모두 큰 효과를 거두는 것을 보았습니다.

Answer 3

나도 @BradS에 동의한다.

지금 비즈니스 로직에서 미들웨어를 숨기는 방법은 다음과 같습니다. 여전히 느슨한 결합 및 SEDA의 이점을 누리면서 - 메모리 SEDA에서 JMS, AMQP, JavaSpaces, 데이터베이스, 파일 또는 FTP 등 다양한 미들웨어 기술 사이를 쉽게 전환할 수 있습니다.