서비스 패브릭 서비스는 완전히 단일 스레드입니까?

Question

나는 서비스 패브릭에 대해 손을 잡으려고 노력 중이고 조금 어려움을 겪고 있습니다. 몇 가지 질문 :

• 은 모두 단일 서비스 스레드 서비스 인스턴스입니까? Task.Delay 메서드를 사용하여 상태가없는 웹 API를 만든 다음 문자열을 반환했습니다. 이 서비스에 대한 두 개의 요청이 동시에 처리되지 않고 순차적으로 처리되었습니다. 그렇다면 동시 처리 요청 수는 애플리케이션 매니페스트의 서비스 인스턴스 개수에 따라 결정됩니다. 편집 OWIN Wep Api의 설정과 관련이 있습니다. 세션별로 차단할 수 있습니까? 나는 기본적으로 세션이 없다고 가정 했는가?

• 나는 서비스 패브릭에서 수행해야하는 (오랜 시간이 걸릴 수 있음) 장기 실행 작업을 가지고 있습니다. 이 서비스 패브릭에 사용할 수있는 권장 패턴이 있습니까? 현재 이러한 작업은 webjob을 트리거하는 저장 대기열을 사용하여 처리됩니다. 신뢰할 수있는 대기열과 RunAsync 루프가있는 것일까 요?

Answer 1

첫 번째 사항은 고객 문제입니다. Chrome은 내 요청을 공개하지 않았으므로 1 차 요청이 응답을받을 때까지 2 차 요청을 지연 시켰습니다. 요청의 매개 변수를 변경하면 동시에 제공 될 수 있습니다.

Answer 2

첫 번째 부분을 처리 한 것 같아서 두 번째 부분에 대해 언급 할 것입니다. "장기 실행 작업".

서비스 패브릭이 등장하기 훨씬 전에 장시간 실행되는 작업/워크 플로를 처리 할 수 ​​있습니다. 이러한 이유로 우리는 소프트웨어 전문가들이 수십 년 동안 사용해 온 디자인 패턴을 살펴봄으로써 거인의 어깨를 쌓을 수 있습니다. 예를 들어, 유명하고 포괄적 인 Process Manager입니다. 이 패턴이 때때로 과잉이라고주의하십시오. 귀하의 경우라면 Gregor Hohpe의 Enterprise Integration Patterns 서적에서 나머지 패턴을 확인하십시오.

신뢰할 수있는 컬렉션의 사용은 선택한 디자인 패턴을 지원하는 데이터 구조를 선택할 때 구현 세부 사항입니다. 정말 당신의 장기 실행 작업의 성격에 따라 달라집니다 -

나는 그 두 번째 점에 관해서

Answer 3

도움이되기를 바랍니다.

장기 실행 작업은 로컬 OS/VM 수준 리소스에 의존하고 결국 결과 (A)로 돌아가는 격리 된 스레드에서 실행되는 작업 종류입니까? 또는 단계를 거치며 일련의 지속 된 상태 변경 (B)을 통해 결과의 모델을 구축하는 일종의 장기 실행 태스크입니까?

Service Fabric에 대해 잘 알고 있지만 장시간 실행되는 작업 부하 (A)를 실행하기 위해 실제로 설계된 것은 아니지만 수평 확장 성과 가용성이 뛰어난 시스템을 작성하는 데 더 적합합니다.

서비스 패브릭 사용에 절대적으로 관심이 있다면 (예 : 귀하의 작업 부하가 A보다 B와 비슷한 경향이있는 경우) 클러스터를 통해 병렬로 처리 할 수있는 장기 실행 작업을 분해 할 수있는 방법을 분명히 찾을 수 있습니다 . 하지만 Azure Batch와 같이이를 위해 설계된 기술이 더 적절할 것입니다.

p.s.RunAsync 메서드에 장기 실행 프로세스를 배치하려는 경우 작업 부하를 디자인하여 클러스터의 다른 노드에서 다시 시작할 수있는 방법으로 상태를 유지해야합니다.

상태 저장 서비스의 경우 기본 복제본에만 상태에 대한 쓰기 권한이 있으므로 일반적으로 서비스가 실제로 작업을 수행 할 때입니다. Stateful 서비스의 RunAsync 메서드는 상태 저장 서비스 복제본이 기본 일 때만 실행됩니다. 기본 복제본의 역할이 주에서 벗어나 변경되면 RunAsync 메서드는 이므로 취소 및 종료 이벤트와 마찬가지로 이 취소됩니다.

P.s.s 장기 실행 작업은 확장 가능 시스템 작성을 시도 할 때의 악마입니다. 시도하고 지금 태클하고 가능한 경우 미래의 고통을 저장하십시오.