Netty와 Apache MINA

그들은 거의 동일한 기능을 제공합니다. 고성능 TCP 서버를 개발하기 위해 어느 것을 선택해야합니까? 장단점은 무엇입니까?

참조 링크 :

Apache MINA ( 소스 )

네티 ( 출처 )

MINA와 Netty는 비슷한 야망을 가지고 있지만 실제로는 상당히 다르므로 신중하게 선택해야합니다. 우리는 MINA에 대한 많은 경험이 있었고 Netty와 함께 놀 시간이 있었기 때문에 운이 좋았습니다. 우리는 특히 더 깨끗한 API와 훨씬 더 나은 문서를 좋아했습니다. 종이에서도 성능이 좋아 보였습니다. 더 중요한 것은 Trustin Lee가 우리가 가진 모든 질문에 대답 할 수 있다는 것을 알고 있었으며 그는 분명히 그렇게했습니다.

우리는 Netty에서 모든 것을 쉽게 발견했습니다. 기간. 우리는 이미 MINA에서와 동일한 기능을 다시 구현하려고 시도했지만 처음부터 그렇게했습니다. 훌륭한 문서와 예제를 따르면 훨씬 적은 코드로 더 많은 기능을 사용할 수있게되었습니다.

Netty Pipeline은 우리에게 더 효과적이었습니다. MINA보다 훨씬 간단합니다. 여기서 모든 것이 처리기이며 업스트림 이벤트, 다운 스트림 이벤트를 처리할지 또는 더 낮은 수준의 항목을 처리할지 여부를 결정하는 것은 사용자의 몫입니다. "재생"디코더에서 바이트가 고갈되는 것은 거의 즐거움이었습니다. 파이프 라인을 즉석에서 쉽게 재구성 할 수 있다는 것도 매우 기뻤습니다.

그러나 Netty의 주요 매력 인 imho는 "하나의 범위"를 가진 파이프 라인 처리기를 만드는 기능입니다. 문서에서 이미이 커버리지 주석에 대해 읽었을 것입니다. 그러나 기본적으로 한 줄의 코드로 상태를 제공합니다. 혼란스럽지 않고 세션 맵, 동기화 및 그와 같은 것들이 없으므로 일반 변수 (예 : "username")를 선언하고 사용할 수있었습니다.

그러나 우리는 장애물에 부딪쳤다. 우리는 이미 MINA 하에서 다중 프로토콜 서버를 가지고 있었으며, 애플리케이션 프로토콜이 TCP / IP, HTTP 및 UDP를 통해 실행되었습니다. Netty로 전환했을 때 SSL과 HTTPS를 몇 분 만에 목록에 추가했습니다! 지금까지는 좋았지 만 UDP에 관해서는 우리가 미끄러 졌다는 것을 깨달았습니다. MINA는 UDP를 "연결된"프로토콜로 취급 할 수 있다는 점에서 매우 기뻤습니다. Netty에서는 그러한 추상화가 없습니다. UDP는 비 연결이며 Netty는이를 그대로 취급합니다. Netty는 MINA보다 낮은 수준에서 더 많은 UDP 연결 특성을 제공합니다. Netty에서 UDP로 할 수있는 것은 MINA가 제공하는 상위 수준 추상화에서는 불가능하지만 우리가 의존 한 것보다 더 낫습니다.

"연결된 UDP"래퍼 등을 추가하는 것은 그리 간단하지 않습니다. 시간 제약과 Trustin의 조언에 따르면 가장 좋은 방법은 Netty에서 자체 운송 업체를 구현하는 것이 었습니다. 신속하지는 않았지만 결국 Netty를 포기해야했습니다.

따라서 차이점을 자세히 살펴보고 까다로운 기능이 예상대로 작동하는지 테스트 할 수있는 단계에 빠르게 도달하십시오. Netty가 그 일을 할 것이라고 만족한다면 MINA를 통해 주저하지 않을 것입니다. MINA에서 Netty로 이전하는 경우에도 마찬가지이지만 두 API가 실제로 크게 다르므로 Netty에 대한 가상 재 작성을 고려해야합니다. 후회하지 않습니다!

MINA는 복잡성 및 상대적으로 열악한 비용으로 더 많은 기능을 제공합니다. 이러한 기능 중 일부는 사용자가 필요하지 않더라도 제거하기에 너무 긴밀하게 코어에 통합되었습니다. Netty에서는 MINA의 알려진 강점을 유지하면서 이러한 디자인 문제를 해결하려고했습니다.

현재 MINA에서 사용 가능한 대부분의 기능은 Netty에서도 사용할 수 있습니다. 내 생각에 Netty는 MINA를 처음부터 재구성하고 알려진 문제를 해결하려고 시도한 결과 Netty가 더 깨끗하고 문서화 된 API를 가지고 있다고 생각합니다. 필수 기능이 누락 된 경우 포럼에 제안을 게시하십시오. 귀하의 우려 사항을 해결하게되어 기쁩니다.

Netty의 개발주기가 빠르다는 점도 중요합니다. 최근 릴리스의 릴리스 날짜를 확인하십시오. 또한 MINA 팀이 MINA 3를 다시 작성하여 API 호환성을 완전히 훼손 할 것임을 고려해야합니다.

하나는 Netty (netty-protobuf-rpc)를 기반으로하고 다른 하나는 mina (protobuf-mina-rpc)를 기반으로하는 2 개의 "Google Protobuffer RPC"구현을 테스트했습니다. Netty는 모든 메시지 크기에 대해 일관되게 더 빠른 속도 (+ -10 %)를 유지하여 Netty 웹 사이트의 전반적인 성능 주장을 뒷받침합니다. 그러한 RPC 라이브러리를 사용할 때 코드에서 모든 효율성을 없애고 싶기 때문에 Netty를 기반으로 protobuf-rpc-pro를 작성했습니다. 나는 과거에 MINA를 사용했지만 2.0 관련 자료에 대한 문서에는 큰 구멍이 있으며 API 이전 버전과의 호환성이 크게 떨어짐을 발견했습니다.

MINA와 Netty는 처음에 같은 저자가 디자인하고 제작했습니다. 그래서 그들은 서로 매우 유사합니다. MINA는 약간 더 많은 기능으로 약간 더 높은 레벨로 설계되었으며 Netty는 조금 더 빠릅니다. 나는 전혀 큰 차이가 없다고 생각합니다. 기본 개념은 동일합니다.

Netty 사이트에서 일부 성능 보고서를 찾을 수 있습니다 . 예상대로 :-) 그들은 최고의 성능을 가진 프레임 워크로 Netty를 지적합니다.

Netty를 사용한 적이 없지만 TCP 프로토콜을 구현하는 데 이미 MINA를 사용했습니다. 인코딩 및 디코딩의 구현은 쉽지만 상태 머신의 구현은 쉽지 않았습니다. MINA는 상태 머신을 구현할 때 도움이되는 몇 가지 클래스를 제공하지만 사용하기가 어렵다는 것을 알았습니다. 결국 우리는 MINA를 버리고 프로토콜을 처음부터 구현하기로 결정했으며 놀랍게도 더 빠른 서버로 끝났습니다.

나는 Netty를 선호합니다.

트위터는 또한 새로운 검색 시스템을 구축하기 위해 Netty를 선택하고 최대 3 배 더 빠르게 실행했습니다.

Ref : Twitter 검색 속도가 3 배 빨라졌습니다

우리는 Mina 및 Jetty와 같은 다른 경쟁사보다 Netty를 선택했습니다. API가 깨끗하고 문서화가 우수하고 Twitter의 다른 여러 프로젝트가이 프레임 워크를 사용하고 있기 때문입니다.

나는 MINA를 사용하여 서버와 같은 작은 http를 작성했습니다. 내가 지금까지 겪었던 가장 큰 문제 :

1. "요청"및 "응답"을 메모리에 보관합니다. 내가 사용하기로 선택한 프로토콜이 http이기 때문에 이것은 단지 문제입니다. 그러나이 문제를 해결하기 위해 자체 프로토콜을 사용할 수 있습니다.
2. 큰 파일을 제공하려는 경우 디스크에서 스트림을 제공하는 옵션이 없습니다. 자체 프로토콜을 구현하여 다시 해결할 수 있습니다.

그것에 대한 좋은 점 :

1. 많은 연결을 처리 할 수 ​​있습니다
2. 어떤 종류의 분산 작업 시스템을 구현하기로 선택한 경우, 노드 중 하나가 작동 중지되고 연결이 끊어진 것을 아는 것은 다른 노드에서 작업을 다시 시작하는 데 유용합니다.