Netty ve Apache MINA

Her ikisi de aşağı yukarı aynı işlevselliği sağlar. Yüksek performanslı TCP sunucumu geliştirmek için hangisini seçmeliyim? Artıları ve eksileri nelerdir?

Referans bağlantıları:

Apache MINA ( kaynak )

Netty ( kaynak )

MINA ve Netty'nin benzer hedefleri olsa da, pratikte oldukça farklılar ve seçiminizi dikkatlice düşünmelisiniz. MINA ile çok fazla deneyimimiz olduğu ve Netty ile oyun oynayacak zamanımız olduğu için şanslıydık. Özellikle daha temiz API'yi ve çok daha iyi dokümantasyonu beğendik. Performans kağıt üzerinde de daha iyi görünüyordu. Daha da önemlisi, Trustin Lee'nin sahip olduğumuz tüm soruları yanıtlamaya hazır olacağını biliyorduk ve kesinlikle bunu yaptı.

Netty'de her şeyi daha kolay bulduk. Dönem. MINA'da zaten sahip olduğumuz işlevselliği yeniden uygulamaya çalışırken, bunu sıfırdan başardık. Mükemmel belgeleri ve örnekleri takip ederek, çok, çok daha az kodda daha fazla işlevsellik elde ettik.

Netty Pipeline bizim için daha iyi çalıştı. Her nasılsa MINA'lardan daha basittir, burada her şey bir işleyicidir ve yukarı akış olaylarını, aşağı akış olaylarını her ikisini de ele alıp almayacağınıza veya daha düşük seviyeli şeyler tüketip tüketmemeye karar vermek size bağlıdır. Kod çözücüleri "yeniden oynatırken" bayt yutmak neredeyse bir zevkti. Ayrıca boru hattını hareket halindeyken bu kadar kolay bir şekilde yeniden yapılandırabilmek de çok güzeldi.

Ancak Netty, imho'nun yıldız cazibesi, "tek bir kapsama" ile boru hattı işleyicileri yaratma becerisidir. Muhtemelen bu kapsam ek açıklamasını belgelerde zaten okumuşsunuzdur, ancak temelde size tek bir kod satırında durumu verir. Karışıklık olmadan, oturum haritaları, senkronizasyon ve benzeri şeyler olmadan, basitçe normal değişkenleri (örneğin, "kullanıcı adı") bildirip onları kullanabildik.

Ama sonra bir barikatla karşılaşırız. MINA altında, uygulama protokolümüzün TCP / IP, HTTP ve UDP üzerinden çalıştığı çok protokollü bir sunucumuz zaten vardı. Netty'ye geçtiğimizde birkaç dakika içinde listeye SSL ve HTTPS ekledik! Şimdiye kadar her şey yolunda, ama UDP'ye gelince hata yaptığımızı anladık. UDP'yi "bağlantılı" bir protokol olarak ele alabildiğimiz için MINA bize çok iyi davrandı. Netty altında böyle bir soyutlama yoktur. UDP bağlantısızdır ve Netty buna bu şekilde davranır. Netty, UDP'nin bağlantısız doğasını MINA'dan daha düşük bir seviyede ortaya çıkarır. Netty altında UDP ile yapabileceğiniz, MINA'nın sağladığı, ancak güvendiğimiz üst düzey soyutlama altında yapamayacağınız şeyler var.

Bir "bağlı UDP" sarmalayıcısı veya başka bir şey eklemek o kadar basit değil. Zaman kısıtlamaları göz önüne alındığında ve Trustin'in tavsiyesi üzerine, ilerlemenin en iyi yolu Netty'de kendi ulaşım sağlayıcımızı kurmaktı, ki bu hızlı olmayacaktı, sonunda Netty'yi terk etmek zorunda kaldık.

Bu nedenle, aralarındaki farklılıklara iyice bakın ve herhangi bir karmaşık işlevin beklendiği gibi çalışıp çalışmadığını test edebileceğiniz bir aşamaya gelin. Netty'nin işi yapacağından eminseniz, o zaman MINA'ya gitmekte tereddüt etmem. MINA'dan Netty'ye geçiyorsanız, aynı durum geçerlidir, ancak iki API'nin gerçekten önemli ölçüde farklı olduğunu ve Netty için sanal bir yeniden yazmayı düşünmeniz gerektiğini belirtmek gerekir - pişman olmayacaksınız!

Güncelleme: Sadece Netty'yi kullanın . Artık protokol istemcileri ve sunucuları oluşturmak için gereken tüm özelliklere sahip olgun bir projedir. İşletmeler tarafından desteklenen birkaç aktif katılımcının bulunduğu güçlü bir topluluğa sahiptir. Ayrıca ' Netty in Action ' adlı bir kitabı var . Bu edilmiş çok çok iyi bilinen şirketlerin ve projelerin benimsediği zaten. Netty'den farklı olarak Apache MINA, projeden ayrıldığımdan beri bakım modunda.

MINA, karmaşıklık ve nispeten düşük performans pahasına daha fazla kullanıma hazır özelliklere sahiptir. Bu özelliklerden bazıları, bir kullanıcı tarafından ihtiyaç duyulmasa bile kaldırılamayacak kadar çekirdeğe entegre edildi. Netty'de, MINA'nın bilinen güçlerini korurken bu tür tasarım sorunlarını çözmeye çalıştım.

Şu anda, MINA'da bulunan çoğu özellik Netty'de de mevcuttur. Bence Netty, MINA'yı sıfırdan yeniden oluşturmaya ve bilinen sorunları ele almaya çalışmanın bir sonucu olduğundan, Netty daha temiz ve daha belgelenmiş bir API'ye sahip. Önemli bir özelliğin eksik olduğunu fark ederseniz, lütfen önerinizi foruma göndermekten çekinmeyin. Endişenizi gidermekten memnuniyet duyarım.

Netty'nin daha hızlı geliştirme döngüsüne sahip olduğuna dikkat etmek de önemlidir. Basitçe, son sürümlerin çıkış tarihine göz atın. Ayrıca, MINA ekibinin büyük bir yeniden yazma olan MINA 3'e geçeceğini de göz önünde bulundurmalısınız, bu da API uyumluluğunu tamamen bozacakları anlamına gelir.

Performansım, biri Netty (netty-protobuf-rpc) ve diğeri mina (protobuf-mina-rpc) temelli 2 "Google Protobuffer RPC" uygulamasını test ettim. Netty, tüm mesaj boyutları için tutarlı bir şekilde daha hızlı (+ -% 10) oldu - bu da Netty web sitesindeki genel performans iddiasını destekliyor. Böyle bir RPC kitaplığı kullandığınızda, kodunuzdaki her bir verimliliği sıkıştırmak istediğiniz için, Netty'ye dayalı protobuf-rpc-pro yazdım. Geçmişte MINA'yı kullandım, ancak 2.0 maddesinin belgelerinde büyük boşluklar olduğunu ve API geriye dönük uyumluluğun kırılmasının büyük bir eksi olduğunu gördüm.

MINA ve Netty başlangıçta aynı yazar tarafından tasarlandı ve inşa edildi. Bu yüzden birbirlerine çok benziyorlar. MINA, biraz daha fazla özellik ile biraz daha yüksek bir seviyede tasarlanırken, Netty biraz daha hızlıdır. Sanırım pek bir fark yok, temel kavramlar aynı.

Netty sitesinde bazı performans raporları bulabilirsiniz . Beklendiği gibi :-) en iyi performansa sahip çerçeve olarak Netty'yi işaret ediyorlar.

Netty'yi hiç kullanmadım, ancak bir TCP protokolü uygulamak için zaten MINA'yı kullandım. Kodlama ve kod çözme uygulaması kolaydı, ancak durum makinesinin uygulanması o kadar kolay değildi. MINA, devlet makinesini uygularken size yardımcı olacak bazı dersler veriyor, ancak ben onları kullanmakta biraz zorlandım. Sonunda MINA'yı terk edip protokolü sıfırdan uygulamaya karar verdik ve şaşırtıcı bir şekilde daha hızlı bir sunucu ile bitirdik.

Netty'yi tercih ederim.

Twitter ayrıca yeni Arama Sistemini oluşturmak için Netty'yi seçti ve 3 kata kadar daha hızlı hızlandırdı.

Ref: Twitter Araması Artık 3 Kat Daha Hızlı

Netty'yi Mina ve Jetty gibi diğer bazı rakipleri yerine seçtik çünkü daha temiz bir API'ye, daha iyi belgelere sahip ve daha da önemlisi Twitter'daki diğer birkaç proje bu çerçeveyi kullanıyor.

Küçük bir http benzeri sunucu oluşturmak için sadece MINA'yı kullandım. Şimdiye kadar karşılaştığım en büyük sorunlar:

1. "İsteğinizi" ve "yanıtınızı" bellekte tutacaktır. Bu yalnızca bir sorundur çünkü kullanmayı seçtiğim protokol http. Bununla birlikte, bunu aşmak için kendi protokolünüzü kullanabilirsiniz.
2. Büyük dosyalar sunmak istemeniz durumunda disk dışı akış sağlama seçeneği yoktur. Yine kendi protokolünüzü uygulayarak geçici olarak çalışılabilir

Bununla ilgili güzel şeyler:

1. Çok sayıda bağlantıyı idare edebilir
2. Bir çeşit dağıtılmış iş sistemi uygulamayı seçerseniz, düğümlerinizden birinin ne zaman kapandığını ve bağlantıyı kaybettiğini bilmek, başka bir düğümde çalışmayı yeniden başlatmak için yararlıdır.