엄청난 양의 데이터를 별도의 테이블과 데이터베이스에 유지하기 위해 책임이 다른 여러 콘솔 응용 프로그램을 작성했습니다. 예를 들어, 한 응용 프로그램은 데이터베이스를 시드 할 수 있으며, 다음 응용 프로그램은 새 데이터를 처리하고 마지막 필터는 오래된 데이터와 새 데이터를 처리 할 수 있습니다. 기타서비스 패브릭 흐름 패턴
지금 서비스는 순차적으로 (손으로) 실행됩니다. 이러한 응용 프로그램의 결과에 따라 이전 응용 프로그램을 실행해야 할 수 있습니다.
이 프로세스 흐름을 자동화하려면 서비스가 서로 통신 할 수 있음을 알면서 서비스 패브릭을 사용할 생각입니다.
하나의 서비스에서 입력/출력을 제어하고 올바른 서비스로 보내는 '기본'서비스가있는 패턴이 있습니까? 아니면 서비스 패브릭의 사용에 대해 지나치게 생각하고 있습니까?
저는 서비스 패브릭이 매우 다양한 요구 사항을 해결할 수있는 매우 유연하고 강력한 시스템이라고 말하고 싶습니다. 원하는 아키텍처를 확실히 구축 할 수 있어야합니다.
흐름을 만들고 제어하려면 SF 액터 사용을 고려할 수 있습니다. 파이프 라인이나 일종의 체인을 만들면 각 액터가 작업을 완료하는 방법, 다음 액터가 성공을 위해 호출하는 것, 무언가가 실패 할 경우 불평 할 사람을 알 수 있습니다. 액터가 장시간 집중적 인 I/O 작업을하는 것을 피하기 위해 미리 알림을 활용할 수 있습니다. 예를 들어, 새로운 입력 부분이 도착하면, 콘솔 어플리케이션 로직이 구현 된 다른 SF 서비스 (실제 작업자)를 호출하여 작업을 시작하고, 작업 ID 또는 배우의 상태에있는 다른 속성을 저장하여 '작업자'를 식별하고, 진행중인 작업의 상태를 확인하도록 미리 알림을 설정하십시오. SF는 서비스가 서로 통신 할 수있는 다양한 방법을 제공하므로 배우와 근로자 간의 상호 작용을 눈 깜짝 할 사이에 설정할 수 있습니다.
당신의 콘솔 어플리케이션이 엄청난 논리적 인 로직을 가지고 있고 십자군 운동의 시작 부분에 코드를 옮기고 싶지 않은 경우 SF의 GuestExecutables와 함께 플레이 할 수도 있습니다.
처음 생각과 일부 매우 일반적인 디자인 일뿐입니다. 내 요점은, SF는 여러 가지 다양한 경우를 다루기위한 다양하고 훌륭한 옵션 때문에 서비스를하는 데있어 매우 좋은 선택입니다.
P.
체크 아웃 Service Fabric Reliable Services Pipeline design을 확인하십시오. 이 토론은 비슷한 주제와 관련이 있으며 사용자가 쉽게 찾을 수있는 세부 정보를 밝힙니다.
[API 게이트웨이] (http://microservices.io/patterns/apigateway.html)에 대해 이야기하고 있습니까? – Marusyk