WCF와 ZeroC ICE를 비교한 사람이 있나요?
https://stackoverflow.com/questions/99548
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
ZeroC의 ICE(www.zeroc.com)가 흥미로워서 WCF를 사용하는 기존 소프트웨어와 비교해 보고 싶습니다.특히 WCF 앱은 HTTP를 통해 서버 콜백을 사용합니다.
비교해본 사람 있나요?어떻게 됐나요?저는 특히 성능 측면에 관심이 있습니다. 상호 운용성은 현재 우리에게 큰 관심사가 아니기 때문입니다.감사해요!
해결책
저는 몇 년 전에 ICE에 대해 매우 간략하게 검토했습니다. 이전에 직접 비교하지는 않았지만 WCF에 대한 합리적인 지식이 있으면 제 생각이 어느 정도 관련성이 있을 수 있습니다.
첫째, ICE는 특정 원격 통신 메커니즘이고 WCF는 더 높은 수준의 원격 통신 프레임워크이기 때문에 WCF를 ICE와 비교하는 것은 전적으로 공평하지 않습니다.
WCF는 SOAP 웹 서비스를 구현하는 것으로 간주되는 경우가 많으며 실제로 이것이 현재까지 주요 용도이지만 모든 방식의 인코딩 및 전송 채널을 사용하여 원격 서비스를 구현하는 데에도 사용할 수 있습니다. 즉, 이론적으로 고성능 통신에 사용될 수 있습니다. 응용 프로그램 사이.
이에 비해 ICE는 애플리케이션 간 원활한 통신을 위해 바이너리 인코딩을 사용하는 크로스 플랫폼 원격 통신 메커니즘입니다.이는 CORBA의 단순화된 발전이며 CORBA, DCOM, .NET Remoting 및 JNI와 더 직접적으로 비교할 수 있습니다.
그러나 ICE와 WCF 사이에 직접적인 통신이 없더라도 원격 통신을 위해 .NET 앱이 필요한 경우 둘 다 경쟁자입니다.고려해야 할 몇 가지 결정 사항은 다음과 같습니다.
자원 조달.ICE 경험보다 WCF 경험이 있는 개발자를 찾는 것이 더 쉬울 것입니다.
성능.성능을 원한다면 ICE가 빠르게 수행되지만 WCF는 성능이 뛰어난 구성에서도 사용될 수 있습니다.또는 .NET Remoting은 매우 우수한 성능을 제공할 수 있으며, MS가 후원하는 벤치마크에 따르면 WCF보다 10% 더 나은 성능을 보였습니다.
크로스 플랫폼.Windows가 아닌 응용 프로그램과 통신해야 하는 경우 사용할 수 있는 WCF 옵션이 제한됩니다.게다가, 모든 SOAP 스택은 표준을 다르게 구현하는 것처럼 보이기 때문에 진정한 일반 웹 서비스를 생성하는 것은 어려울 수 있습니다(WS-I는 도움이 되지만).
첫날부터 모든 성능이 필요하지 않다면 개인적으로 WCF를 선택하고 성능이 중요해지면 ICE를 고려하겠습니다.그럼에도 불구하고 ICE로 이동하는 것보다 서비스 상자를 확장하는 것이 더 저렴할 수 있으며, 특별한 크로스 플랫폼 요구 사항이 없다면 항상 이진 인코딩 등을 위해 WCF를 재구성하는 것을 살펴볼 수 있습니다.
다른 팁
아파치 중고품 ICE와 WCF의 또 다른 경쟁자입니다.Facebook에서 개발하고 오픈 소스로 제공했습니다. 아파치 중고품 인코딩 측면에서 매우 효율적일 뿐만 아니라 모든 클라이언트를 중단하지 않고 구조에 필드를 추가하는 기능도 지원하기 때문에 어떤 면에서는 좋습니다(우리 프로젝트에 매우 유용하다고 판단한 기능).
Google 프로토콜 버퍼 홈 페이지에 .NET 지원이 언급되어 있지 않기 때문에 실제로 경쟁자는 아닌 것 같습니다.그러나 일부 커뮤니티 추가 기능은 C#을 지원합니다.게다가, 얼음 기존 서비스로 작업하는 경우 Google 프로토콜 버퍼에 대한 에뮬레이션을 제공합니다.
데이터 포인트:방금 콜백 다중 플랫폼 및 다중 언어 프로젝트를 Ice에서 Thrift로 변환하여 꽤 좋은 결과를 얻었습니다.Ice는 여러분을 위해 많은 일을 하므로 연결 해제 리스너, 연결 이벤트 등을 구현해야 했습니다.우리 스스로.그리고 어떤 경우에는 Ice가 우리에게 허용한 큰 개체 잠금에 대한 속담에 약간의 문제가 있었습니다. 이로 인해 Thrift 서버에서 교착 상태가 발생했지만 C# 측에서 덜 게으른 코딩으로 쉽게 해결되었습니다.
방금 벤치마킹을 마쳤는데, 우리 애플리케이션에서 많은 양의 데이터를 푸시하는 모든 것이 Ice보다 빠르거나 동등합니다.오버헤드가 더 많은 짧은 메시지(예: 프로토콜을 통해 상태를 업데이트하는 "하트비트")는 약간 느립니다.
가장 중요한 점은 콜백 서비스를 올바르게 구현하기 위해 Thrift 인터페이스를 확장하고 Thrift "프로세서" 및 콜백 클라이언트 서버와 함께 자체 프로토콜을 정의해야 한다는 것입니다.하지만 나는 우리 지원서가 /매우/ 특별하다는 점을 기꺼이 인정합니다.기존 프로토콜과 서버로 충분해야 합니다.그러나 .Net의 멀티플렉스 소켓을 사용하기 위해 이를 확장하는 것은 그리 어렵지 않았습니다.
우리는 ICE를 사용하여 C++, Java 및 C#으로 작성된 모듈을 통합하고 있습니다.좋은 점은 서버가 원격 시스템의 구성 요소에도 액세스할 수 있으므로 더 많은 성능이 필요한 경우 처리를 다른 시스템으로 전환할 수 있다는 것입니다.
저는 WCF와 ICE를 모두 사용해 보았는데 구현 측면에서는 ICE가 더 깔끔하다고 말하고 싶습니다.ICE에는 매우 상세하고 읽기 쉬운 문서도 있습니다.
ICE는 로드 밸런싱, 자동화된 원격 클라이언트 업데이트 등 WCF가 할 수 없는 몇 가지 작업을 지원합니다.
