서비스 지향 아키텍처 - 전송 계층 (http 대 메시징)

Question

SOA (Service Oriented Architecture)를 사용하여 아키텍처를 분할하고 새로운 구성 요소를 추가하는 방법을 살펴 보았습니다. 우리가 REST HTTP 인터페이스를 사용하여 제 3 자에 의해 사용될 많은 외부 API가있을 것입니다. 그러나 모든 구성 요소가 우리의 통제하에 있으며 내부적으로 사용하는 것이 가장 좋을지 궁금합니다. 동일한 네트워크, 잠재적으로 다른 기술 (주로 .net 및 레일상의 루비).

HTTP (REST, SOAP 등) 대신 메시징 시스템 (redis, rabbitmq, EMS, 내가 들어 본 적이없는 다른 주목할만한 예외)을 사용하면 성능/기능면에서 큰 이득을 얻을 수 있습니까?

저는이 주제에 대한 좋은 정보를 찾기 위해 애를 썼습니다. (아마도 알 수 있듯이) 나는이 측면 영역에 새로운 것이므로 어떤 조언이나 좋은 자료라도 감사 할 것입니다!

Thnaks

Answer 1

@ Hill Hartung이 언급 한 것 외에도 시스템으로 무엇을 할 것인가에 달려 있다고합니다. 서버/서비스가 거의없고 완전히 독립적인 경향이있는 대부분 클라이언트 - 서버 유형의 응용 프로그램을 사용하는 경우 HTTP를 통한 REST를 통해 서비스 계약을 구현하는 것이 더 쉬울 것입니다.

반면에 전체 시스템이 양방향 통신을 수행 중이거나 많은 프로세스 간 호출이있는 경우 (특히 시스템의 모든 참가자가 클라이언트와 서버 모두에있을 경우) 어떤 점), 메시지가 가장 좋은 방법입니다. 메시징 옵션 중에서 AMQP/RabbitMQ는 가장 기능이 풍부하고 사용하기 쉽다는 것을 알게되었습니다. 코드 작성을위한 진정한 비동기 플랫폼을 제공합니다.

메시징 사용의 주요 이점은 각 유형의 메시지에 대한 대기열을 가질 수 있다는 점입니다. 따라서 시스템이 확장되고 변경 될 때 대기열/메시지는 동일하지만 처리 할 서비스가 변경 될 수 있습니다. 레이어 분리를 촉진합니다.

마지막으로 이것은 메시징의 적절한 사용은 작고 독립적 인 코드를 촉진한다고 생각합니다. 이들은 더 테스트 가능하고 유지 보수가 용이하며 일반적으로 엔터프라이즈 아키텍처를 단순화합니다. HTTP 엔드 포인트에서 너무 많은 서비스를 처리하려고 시도하면 (1 년 또는 2 년 동안) 결국 (1) 길을 추적 할 엔드 포인트가 너무 많아 지거나 (2) 스파게티 코드의 유지가 불가능한 엉망으로 끝나게됩니다 .

우리 회사는 메시지 기반 프레임 워크를 사용하기 시작했습니다. RabbitMQ 서버는 가장 신뢰할 수있는 구성 요소였습니다. 메시징 또는 SOA에 대해 더 이상의 질문이 있으면 언제든지 물어보십시오.

Answer 2

메시징을 사용하면 좀 더 느슨하게 결합 된 아키텍처를 제공하는 경향이있다. 개별 인프라가 전체 인프라를 파괴하지 않고 실패 할 수 있기 때문에 잠재적으로 더욱 강력해질 수 있습니다.

단점은 복잡성, 패러다임이 비동기 모델로 이동하며 성능이 향상 될 수 있다는 것입니다 (특히 어디에서나 메시지를 지속하는 경우 특히 그렇습니다).

또한 메시징 시스템이 특히 강력해야합니다. 로직의 한 측면은 모든것에 영향을 미치지 않고 중단되고 다시 시작될 수 있지만 핵심 메시지 기반을 잃어 버리면 모든 논리가 다운되어 메시징이 백업 될 것입니다.

다행히도 메시지 버스는 사람이 손대지 않고 만지면 오랜 시간 동안 실행될 수 있습니다. 이는 시스템의 오류 및 불안정성의 가장 큰 원인입니다.