2017-01-06 9 views
3

실제 세계의 기기를 Reliable Actors에 매핑하는 애플리케이션이 있습니다. Azure Fabric입니다. 장치에서 메시지를받을 때마다 이벤트 허브에 메시지를 보내려합니다.Azure Fabric 신뢰할 수있는 액터간에 EventHub 공유

현재 내가하고있는 일은 각 메시지에 대해 EventHubClient 객체를 생성/사용/종료하는 것입니다.

이것은 매우 비효율적이며 (약 1500ms 소요) 과거 EventHubClient를 메모리에 유지하고 있던 문제를 해결합니다. 많은 장치가 있으면 기본 가상 컴퓨터의 네트워크 연결이 빨리 끊어 질 수 있습니다.

EventHubClient를 유지함으로써 데이터를 EventHub으로 푸시하는 새 액터를 만드는 것에 대해 생각하고 있습니다. Reliable Actors의 기반 기반 동시성 모델 덕분에 좋은 생각이 아닌 것 같습니다. 데이터를 "동시에"푸시하는 10,000 개의 장치를 얻으면 각 액터가 메시지를 EventHub에 푸시하는 새 액터로 푸시하도록 차단합니다.

이 시나리오에서 권장되는 접근 방법은 무엇입니까? 감사합니다,

답변

4

한 가지 방법은 메시지를 EventHub에 푸시하는 책임이있는 상태 비 저장 서비스를 만드는 것입니다. 액터가 장치로부터 메시지를받을 때마다 (액터와 통신하는 방법은 무엇입니까?) 액터는 상태 비 저장 서비스를 호출합니다. 상태 비 저장 서비스는 차례대로 서비스 당 하나의 EventHubClient를 생성, 유지 및 처리합니다. 신뢰할 수있는 서비스는 신뢰할 수있는 액터처럼 수신 메시지를 처리 ​​할 때 동일한 '오버 헤드'를 발생시키지 않습니다. 응용 프로그램에서 메시지가 정확히 동일한 순서로 EventHub에 도달하는 것이 중요한 경우 Stateful Service 및 Reliable Queue를 사용하여이 작업을 수행해야합니다. () 반면에 액터가 수신 메시지를 처리 ​​할 때 동일한 순서로 처리 할 수 ​​있다는 보장이 없습니다.

다음과 같이 실험을 통해 솔루션을 미세 조정할 수 있습니다. instance count (https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-availability-services) 들어오는 메시지의 처리량을 처리 할 충분한 인스턴스가 있는지 확인하십시오.노드 당 노드 수와 코어 수에 따라 대략 몇 개의 인스턴스가 결정되지만 다른 요소도 영향을받을 수 있습니다.

Simplified architecture, Actors communicating with Services, Service with EventHub 장치 차례로 Actors이 (가) Service (당신이 메시지를 큐 아래를 참조 할 경우, 상태가없는 경우와 상태가 될 수있다), 각 서비스는 EventHub에 푸시 메시지를 수있는 EventHubClient 관리와 통신, 당신의 Actors와 통신합니다.

클러스터가이 서비스의 인스턴스 카운트를 충분히 지원하지 못하는 경우 (조금 단순화되면 더 많은 인스턴스 = 높은 처리량), 대신 상태 저장 서비스로 생성하고 서비스의 신뢰할 수있는 대기열에 넣고 서비스의 대기열을 순서대로 처리하려면 RunAsync이 있어야합니다. 이것은 성능 최고치의 압력을받을 수 있습니다.

Service Fabric Azure-Samples WordCount은 액터로부터의 메시지가 다른 인스턴스 (또는 실제 파티션)를 대상으로하기 위해 다른 파티션으로 작업하는 방법을 보여줍니다.

일반적인 팁은 모든 것을 위해 액터를 사용하지 않는 것입니다 (그러나 훌륭한 것들이 중요하고 복잡성을 크게 줄임) 신뢰할 수있는 서비스 모델은 더 많은 시나리오와 요구 사항을 지원하며 실제로 배우를 보완 할 수 있습니다 (액터가 실제로 설계되지 않은 것을하려고 시도하는 것보다).

+0

다이어그램과 모든 것에 대한 훌륭한 설명에 감사드립니다! – japf

4

pub/sub 패턴을 사용할 수 있습니다 (BrokerService 사용). 이벤트 처리에서 이벤트 게시를 분리함으로써 회전 기반 동시성 모델에 대해 걱정할 필요가 없습니다.

발행인 :

액터가 BrokerService 단순히 publishing 그들에 의해 메시지를 보냅니다.

가입자

는 그런 다음 이벤트의 가입자 하나 이상의 Stateless Services 또는 (다른) Actors를 사용합니다. 그들은 자신의 페이스대로 EventHub에 보낼 것입니다. 이 방법을 사용하여 이벤트 허브 클라이언트

당신은 EventHubClient 인스턴스 수와 수명을 완벽하게 제어 할 것입니다. 단순히 구독자를 추가하여 이벤트 처리 능력을 향상시킬 수 있습니다.

+0

펍/서브 라이브러리를 소개해 주셔서 감사합니다. – japf

0

제 의견으로는 내부 메모리 대기열이있는 백그라운드 스레드에서 이벤트 허브를 직접 호출해야합니다. 메시지를 집계하고 SendBatch를 사용하여 성능을 향상시켜야합니다.

이벤트 허브는 혼자서 부하를받을 수 있습니다.

+0

Actor의 서비스가 다운 된 경우 (어떤 이유로 든) Actor의 내부 메모리 대기열이 안정적이지 않습니다. 이 시나리오에서는 배치가 손실됩니다. 또는 액터의 지속 상태를 사용하여 이벤트를 저장하고 일괄 처리한다는 의미입니까? – yoape

+0

액터는 싱글 스레드이어야하며 백그라운드 스레드는 내 관점에서 이해가되지 않습니다. –