AMQP와 같은 메시지 지향 미들웨어는 어떤 도메인에서 유용합니까?

AMQP와 같은 메시지 지향 미들웨어는 어떤 도메인에서 유용합니까?

---

MOM (Message Oriented Middleware)은 어떤 문제를 해결합니까? 확장 성? 완성?

일반적으로 사용되는 도메인과 일반적으로 사용 되지 않는 도메인은 무엇입니까?

예를 들어 Google이 기본 검색 엔진이나 GMail을 위해 이러한 솔루션을 사용하고 있습니까?

Walmart, eBay, FedEx (대부분의 Java 상점) 및 buy.com (대부분의 MS 상점)과 같은 대형 웹 사이트는 어떻습니까? MOM이 필요를 해결합니까?

서버 측을 제어하고 동종 환경 (예 : Linux + Java JVM을 모두 실행하는 수십 개의 Amazon EC2 인스턴스)이 있고 클라이언트가 웹 브라우저 인 웹앱을 작성할 때 의미가 있습니까?

서버와 통신해야하는 데스크톱 앱에 적합합니까?

아니면 일반적으로 어떤 방식 으로든 통신해야하는 수많은 서로 다른 시스템이 행복하게 혼합되어있는 대기업에만 해당합니까?

나는 그들이 무엇에 유용하는지에 대해 약간 혼란스럽고 그들이 어디에 적합하고 적합하지 않은지에 대한 예를 들어 사용하면 더 잘 이해할 수 있다고 생각합니다.

---

이것은 좋은 질문입니다.

메시징의 주요 용도는 확장, 오프 로딩 작업, 통합, 모니터링, 이벤트 처리, 라우팅, 네트워킹, 푸시, 이동성, 버퍼링, 대기열, 작업 공유, 경고, 관리, 로깅, 배치, 데이터 전달, pubsub, 멀티 캐스트, 감사입니다. , 일정, ... 등. 기본적으로 : 데이터가 필요하지만 데이터베이스 요청을 원하지 않는 모든 것. (캐싱은 또 다른 긴 이야기입니다).

이를 보는 또 다른 방법은 사용자 (사람)가 데이터베이스에서 트랜잭션을 실행하여 수행 할 작업 (읽기, 쓰기 포함)을 수행 할 것이라고 가정하여 구축 된 많은 응용 프로그램을 확인하는 것입니다. 그러나 오늘날 많은 작업은 사용자가 시작하지 않습니다. 대신 응용 프로그램에서 시작됩니다. 예 : "내가 사고 싶은 책의 재고가 있으면 알려주세요." 이러한 종류의 문제를 해결하는 가장 좋은 방법은 일종의 메시징입니다. 미들웨어, 웹 푸시 또는 실시간 샐러드 드레싱이라고 ​​부르든 상관 없습니다. 모든 메시지입니다.

애플리케이션이 이벤트를 시작하거나 반응하도록 설정하면 아키텍처가 느슨하게 결합 된 구성 요소를 기반으로 할 수 있으므로 확장하기가 훨씬 쉽습니다. 메시징이 안정적이고 확장 가능하며 서비스 가능한 도구를 기반으로하고, 가급적이면 개방형 표준 API 및 프로토콜을 사용하는 경우 이러한 구성 요소를 통합하는 것이 훨씬 쉽습니다.

이게 도움이 되길 바란다. 여기 에 메시징에 대한 유용한 링크 목록을 유지하려고합니다.

이것에 대한 질문과 의견으로 연락하십시오. 우리는 찾기가 쉽습니다.

---

구체적인 질문을 해결하려면 :

일반적으로 사용되는 도메인과 일반적으로 사용되지 않는 도메인은 무엇입니까?

데이터베이스와 마찬가지로 메시징 시스템은 모든 곳에서 자랍니다.

예를 들어 Google이 기본 검색 엔진이나 GMail을 위해 이러한 솔루션을 사용하고 있습니까?

Google은 자체 개발 한 기술을 많이 사용하지만 많은 오픈 소스 기여와 알려진 사용 사례를 보면 메시징이 일부 주요 서비스의 중심 (또는 그 중심에 있어야 함)이 있음을 시사합니다.

Walmart, eBay, FedEx (대부분의 Java 상점) 및 buy.com (대부분의 MS 상점)과 같은 대형 웹 사이트는 어떻습니까? MOM이 필요를 해결합니까?

매우 그렇다.

예제 사용 사례는 웹 페이지 요청을 확장하는 것입니다. 사용자가 웹 요청을하면 웹 서버는이를 백그라운드 처리를 위해 큐에 넣습니다. 이는 요청이 처리되는 동안 웹 서버가 계속 작동 할 수 있음을 의미합니다. 또한 웹 서버가 요청 처리 방법을 알 필요가 없으므로 주요 부분이 '분리'되기 때문에 시스템 유지 관리, 업그레이드 및 롤백이 훨씬 간단 해집니다.

어쨌든, 웹 요청은 백엔드 서비스 또는 아마도 '책 제목 조회', '장바구니 그리기', '광고 가져 오기', '사용자 계정 확인'과 같은 많은 서비스에 의해 처리됩니다. 마지막으로 모두 결과는 웹 서버에 의해 수집 및 사용자 응답을 위해 준비된 다른 대기열에 저장됩니다. 일반적으로 시스템은 약 100ms의 시간 제한을 포함하므로 지연된 요청은 모두 버려집니다. 사용자는 시간 간격에서 처리 된 모든 것을 볼 수 있습니다. 이것이 일부 대형 전자 상거래 사이트에 단계적으로로드되는 것처럼 보이는 페이지가있는 이유 중 하나입니다.

더 많은 사용 사례가 있습니다 ...

서버 측을 제어하고 동종 환경 (예 : Linux + Java JVM을 모두 실행하는 수십 개의 Amazon EC2 인스턴스)이 있고 클라이언트가 웹 브라우저 인 웹앱을 작성할 때 의미가 있습니까?

명확히. 알 수 없거나 제한되지 않은 사용자 수, 서버 측 인스턴스 및 애플리케이션 대기 시간이있는 경우 비 차단 RPC를위한 확장 가능한 기판이라 할지라도 메시징을 사용하는 것이 좋습니다.

서버와 통신해야하는 데스크톱 앱에 적합합니까?

많은 경우에. 매우 일반적인 경우 중 하나는 서버가 이벤트를 데스크톱 앱에 푸시하는 경우입니다 (예 : 게임 이벤트, 트윗, 금융의 가격 피드, 시스템 알림 등) ....

아니면 일반적으로 어떤 방식 으로든 통신해야하는 수많은 서로 다른 시스템이 행복하게 혼합되어있는 대기업에만 해당합니까?

이러한 '레거시 통합'사례뿐만 아니라 중요합니다. RabbitMQ에서 순수한 규모 또는 메시지 양 측면에서 가장 큰 고객은 클라우드 공급자와 대규모 웹 애플리케이션 공급자입니다.

---

저는 이전 경험에서 한 가지 대답 만 답할 것입니다. 여기에서 대기업에서 사용하는 미들웨어 를 살펴 보겠습니다. 미들웨어에는 하나의 목적이 있습니다. 연결이 끊긴 시스템 (이종 언어로 작성된)을 서로 붙여서 서로 상호 작용하고 비즈니스 프로세스를 능률화 할 수 있습니다.-Entera는 제가 경험 한 것처럼 C로 작성된 프로세스를 사용하여 유닉스 박스가 작성된 프런트 엔드를 통해 메인 프레임 시스템 (DB2, COBOL)과 상호 작용하는 중간 계층을 생성합니다. PowerBuilder에서 (저는 회사 이름을 지정하지 않습니다!).

내가 제공 한 설명에서 Entera는 엔디안 형식에 관계없이 데이터 흐름의 원활한 통합, 다양한 언어가 미들웨어 브로커와 통신 할 수있는 기능 (브로커는 CORBA 또는 DCE 유사 프로세스, 특정 포트에서 수신하는 'The Open Group)을 준수하고 IDL에 의해 지정됨이는 프로세스가 로컬 인 것처럼 보이게합니다. Microsoft의 .NET Framework에서 Remoting에 사용되는 용어를 이해한다면 멀지 않은 것입니다! 미들웨어는 컴파일 타임에 링크 된 스텁을 생성하고 프로세스 생성을 관리하고, 포트에서 호스팅하고, 런타임에 멀티 스레딩하며, 최신 프런트 엔드 (예 : .NET, Java , PowerBuilder는 말을 할 수없는 VB6 ... ok ... VB.NET조차도 특정 IP 주소에서 지정된 포트에 대한 연결을 열어 상호 작용할 수 있으며 생성 된 스텁을 사용하여 직접 상호 작용할 수 있습니다.

분명히 설명 된 내용을 통해 레거시 시스템이 새로운 생명을 불어 넣어 프로세스의 확장 성을 확보 할 수있는 방법을 알 수 있습니다. 이것의 주요 단점은 수천 달러에 달할 수있는 비용 요소입니다. 메인 프레임을 청구 / 청구를위한 백엔드 처리 시스템으로 사용하는 대기업, 막대한 수익을 창출하는 대기업은 분명히 그러한 값 비싼 제품을 감당할 수 있습니다-그들에게는 사용 때문에 물 한 웅덩이에 동전을 던지는 것처럼 보일 것입니다. 비즈니스 프로세스를 연장하고 새로운 생명을 불어 넣는 미들웨어는 '레거시'태그가 부착 된 것에 대해 걱정하지 않고 미래로 사업을 확장 할 수 있습니다.

덧붙여서 저는이 작업을 제 BSc 논문의 일부로 수행했습니다. 이 상업적 프런트 엔드를 다루는 정보 시스템에서. Sourceforge에서 FreeDCE 라는 미들웨어의 오픈 소스 버전이 있었지만 개발 노력은 거부되거나 중단되었습니다.

편집 : @cocotwo : 미들웨어가 배관 도구라고 말했듯이 정확히 수행하는 작업입니다 ... 메시지 지향 미들웨어는 AFAIK에 대해 실제로 들어 있지 않습니다. 왜냐하면 제가 상상하기 때문에 프로세스 (기능)를 호출해야하기 때문입니다. 마치 프런트 엔드의 응용 프로그램 도메인 내에서 로컬로 표시되어 쉽게 상호 작용할 수 있습니다.

메시지를 사용하는 것은 네트워크 연결이 끊어지는 경우 메시지가 안전한 보관 영역에 대기한다는 점에서 RPC 호출에 비해 이점이있을 수 있습니다. 해당 측면에서 일부 데이터 캐싱이 진행되어 프런트 엔드가 계속 진행될 수 있습니다. ... 미들웨어를 통해 백엔드에 대한 단방향 쓰기 데이터 인 '특정 청구 / 인보이스 번호의 상태 업데이트'의 경우에 유용합니다.

좋습니다. 대기업은 기술자가 데이터 흐름의 원활한 전달을 보장하기 위해 24 시간 상주하는 고급 시스템 인프라를 보유하고있을 것입니다. 제가 함께 일했던 회사는 IBM 글로벌 지원 계약을 통해 주문을 이행했습니다. 핫 스왑 / 균형 클러스터 / 미러링 시스템을 제자리에두고 소수점 이하 6 개의 9로 최대 가동 시간 99 %를 보장합니다.

Whereas with RPC, if the disconnection occurs, the front-end would have to be restarted or would have to handle the disconnection event. It really depends if the message-queueing middle-ware handles each message in real-time and pass back results to the front-end immediately...

This is where each (Message-queueing and RPC related middle-ware) have their strengths and weaknesses...and also the cost mitigation factor such as support, maximum up-time, development efforts and training - that's a biggie here as middle-ware are really proprietary (despite following the 'The Open Group' layout/standards) and complex to setup and to glue the whole thing together via scripts.

---

Good answers and discussion here. Our consulting team has two preferred "messaging" solutions: RabittMQ and NXTera a high speed RPC middleware, the contemporary version of Entera mentioned above. My partners and I have developed several solutions using RabittMQ, it is the best tool available in that space right now. Additionally, I happen to work for the company that makes NXTera/Entera.

From experience I can clearly say that both of these products meet the need for reliability and low maintenance as discussed above. There are situations where a messaging service, like RabittMQ, is the right choice -- where Publish and subscribe, certified delivery, Queuing or store-and-forward are required.

In other cases, RPC's (remote procedure calls) are the best and fastest solutions for transactional and distributed processing for enterprise or cloud-based applications. When it is right to use an RPC, but SOAP/.NET (yes these are RPC implementations) are too slow, expensive or complex, a lightwieght high speed RPC middleware like NXTera/Entera is the right choice for us.

There is some use case overlap between RPC middleware and message oriented middleware, and where there are you can use either successfully. But both are strong and dependable choices.

The large companies I work with use both RPC and MoM side-by-side. As far as Internet companies, Google (Protocol Buffers) and Facebook (Thrift) show that RPC's have a roll to play in modern web and cloud-based development.

ReferenceURL : https://stackoverflow.com/questions/2388539/in-which-domains-are-message-oriented-middleware-like-amqp-useful