새 프로젝트를 시작하면서 백엔드에서 서비스를 연결하는 서비스 버스 개념에 빠져 들었습니다. 지금까지 웹 개발을 주로하고 있었으므로 웹 계층을 ESB를 통해 서비스에 연결하기 만했습니다.클라이언트/서버 통신을위한 NServiceBus?
이제는 서버/클라이언트 연결이 필요한 데스크톱 응용 프로그램에서 시작합니다. 기본적으로 비동기 모델을 강제로 적용하고 부하 분산에 유연성을 허용하므로 ESB는 좋은 생각입니다. 또한 Pub/Sub는 많은 경우에 많은 의미가 있습니다.
ESB에서 많은 것을 읽었으며 Ayende는 요청/응답 시나리오에서 ESB를 사용하는 Alexandria App도했습니다. 그렇다면 ESB에 대한 요청/응답은 나쁜 것입니다.
내 서버/클라이언트 통신을 지원하는 ESB에서 볼 수있는 큰 문제는 무엇입니까?
CQRS (Command/Query Segregation)의 Udi Dahan의 소식을 확인하십시오. 이것은 당신이해야 할 결정 포인트를 알려줍니다. 클라이언트 응용 프로그램의 주된 문제점은 백그라운드에서 메시지 펌프를 작성하고 해당 데이터를 UI 스레드로 마샬링하는 것입니다. 웹의 경우 더 많은 비정규화된 저장소로 쿼리를 분리하는 것이 효과적이지만,이 방법론을 사용하면 UI를 작성하는 방법에 대해 약간 다르게 생각할 수 있습니다. 객체를 47 번 매핑하여 데이터를 가져올 필요가 없으므로 모델을 크게 단순화합니다. 항상 정당화에 어려움을 겪었습니다. 분명히 단점은 더 많은 움직이는 부분이지만, 우리는 그것이 가치가 있다는 것을 알았습니다.
이것은 WinForms에서 웹으로가는 반대 의견에서 동일한 질문을 한 적이 있기 때문에 나에게 정말 흥미로운 질문입니다.하지만 Yahoo 그룹에서는 그렇지 않습니다.
WinForms에서의 비동기 요청/응답은 나에게 매우 유용했습니다. UI는 쿼리 명령을 실행하고 그것에 대해 잊어 버립니다. 쿼리 결과가 포함 된 응답이 발생하고 해당 쿼리를 계속 사용할 수있는 경우 데이터가 뷰에 채워집니다.
나는 왜 ESB를 쿼리에 사용하는 것이 나쁜지에 대한 견해를 만들고 있으며, 비동기 모델이 구축 요구 사항에 쉽게 들어 가지 않는다고 생각합니다. 웹 앱용 페이지. 또한 다른 직접적인 쿼리 방법에 비해 약간의 성능 저하가 있습니다.
나는 단지 "때문에"답을 좋아하지 않으므로 다른 질문에 대한 답변에 관심을 갖길 고대합니다.
의견을 보내 주셔서 감사합니다. 웹에서 요청/응답을 사용하지 않고 ESB를 사용하여 명령을 서비스에 전파하고 거기에서 pub/sub를 사용하여 웹 클라이언트가 직접 문의 한 읽기 모델을 업데이트 할 수 있습니다. . 나는 그것이 최선의 방법인지 아직 확실하지 않다. 그러나 그것은 괜찮 았던 것이다. – Tigraine
정보 주셔서 감사합니다. 그냥 그것을 위해, 나는 비동기 쿼리 웹 페이지에서 작동하지만 이벤트를 차단하여. –
흠 .. 우리는 지금 모든 질문에 대답하지 않습니다. EventHandlers를 사용하여 업데이트 된 View-Cache를 유지 관리합니다. 이벤트가 게시되면 웹 서버가 해당 SQL 테이블을 직접 쿼리하여 데이터를 가져 오는 동안 View-Cache는 새 데이터 (완전히 비동기로 발생)를 반영하도록 SQL 테이블을 업데이트합니다. 우리는 여전히 ESB를 사용하여 명령을 전송합니다. – Tigraine
포인터 주셔서 감사. 주말에 Udi의 블로그를 파고 Distributed Systems Podcast를 듣고 나는 같은 결론에 도달했습니다. – Tigraine