Netty กับ Apache MINA


144

พวกเขาทั้งสองให้ฟังก์ชั่นเดียวกันประมาณ ฉันควรเลือกเซิร์ฟเวอร์ตัวใดเพื่อพัฒนาเซิร์ฟเวอร์ TCP ที่มีประสิทธิภาพสูง ข้อดีข้อเสียคืออะไร

ลิงค์อ้างอิง:

Apache MINA ( แหล่งที่มา )

Netty ( แหล่งที่มา )


6
น่าสนใจที่จะเพิ่ม Grizzly เข้ากับการเปรียบเทียบ
Mark

Grizzly เป็นสัตว์ร้ายที่แตกต่างอย่างสิ้นเชิง แม้แต่ความคิดของ Grizzly ก็สนับสนุน MINA เมื่อทั้งสองกลุ่มพูดคุยกัน
Hardcoded

1
@Hardcoded คุณบอกว่า Grizzly เป็นสัตว์ที่แตกต่างอย่างสิ้นเชิงฉันเป็นผู้มาใหม่ในเรื่องนี้คุณช่วยชี้ให้เห็นถึงความแตกต่างหรือให้บทความเพื่ออ่านสิ่งนั้นได้หรือไม่? ฉันขอขอบคุณมันจริงๆ
arg20

1
Grizzly มีพื้นหลังที่แตกต่างกันและครั้งสุดท้ายที่ฉันดูมันส่วนใหญ่จะเหมาะกับแอพพลิเคชั่นที่ใช้ HTTP ฉันเพิ่งดูตัวอย่างและรู้สึกประหลาดใจที่เห็นว่าพวกเขาใช้โครงสร้างที่คล้ายกันมากกับ MINA หรือ Netty ดังนั้นสัตว์ร้ายจึงไม่แตกต่างกันอีกต่อไปแล้ว
ฮาร์ดโค้ด

คำตอบ:


211

ในขณะที่ MINA และ Netty มีความทะเยอทะยานเหมือนกันพวกเขาค่อนข้างแตกต่างกันในทางปฏิบัติและคุณควรพิจารณาตัวเลือกของคุณอย่างรอบคอบ เราโชคดีที่มีประสบการณ์มากมายกับ MINA และมีเวลาเล่นกับ Netty เราชอบ API ที่สะอาดกว่าและเอกสารที่ดีกว่ามาก ประสิทธิภาพดูดีขึ้นบนกระดาษด้วย ที่สำคัญกว่านั้นเรารู้ว่า Trustin Lee ยินดีที่จะตอบทุกคำถามที่เรามีและเขาก็ทำอย่างนั้น

เราพบว่าทุกอย่างง่ายขึ้นใน Netty ระยะเวลา ในขณะที่เราพยายามปรับใช้ฟังก์ชันการทำงานเดียวกันกับที่เรามีอยู่บน MINA อีกครั้งเราก็ทำเช่นนั้นตั้งแต่เริ่มต้น ด้วยการทำตามเอกสารและตัวอย่างที่ยอดเยี่ยมทำให้เราสามารถใช้งานได้มากขึ้นในรหัสที่น้อยลง

Netty Pipeline ทำงานได้ดีขึ้นสำหรับเรา มันง่ายกว่าอย่างน้อย MINA ที่ทุกอย่างเป็นตัวจัดการและมันก็ขึ้นอยู่กับคุณที่จะตัดสินใจว่าจะจัดการกับเหตุการณ์ต้นน้ำเหตุการณ์ปลายน้ำทั้งสองหรือใช้สิ่งที่ต่ำกว่ามาก ไบต์ Gobbling ในตัวถอดรหัส "เล่นซ้ำ" เกือบจะเป็นเรื่องที่น่ายินดี นอกจากนี้ยังเป็นเรื่องที่ดีมากที่สามารถกำหนดค่าไปป์ on-the-fly ได้อย่างง่ายดาย

แต่สถานที่น่าดึงดูดของ Netty คือความสามารถในการสร้างเครื่องมือจัดการท่อด้วย "ความครอบคลุมของหนึ่ง" คุณอาจได้อ่านเกี่ยวกับคำอธิบายประกอบที่ครอบคลุมนี้อยู่แล้วในเอกสาร แต่โดยพื้นฐานแล้วมันจะให้สถานะคุณในรหัสบรรทัดเดียว โดยไม่ต้องยุ่งไม่มีแผนที่เซสชั่นการซิงโครไนซ์และอะไรแบบนั้นเราก็สามารถประกาศตัวแปรปกติ (พูดว่า "ชื่อผู้ใช้") และใช้มันได้

แต่แล้วเราก็เจอสิ่งกีดขวางบนถนน เรามีเซิร์ฟเวอร์หลายโปรโตคอลภายใต้ MINA ซึ่งโปรโตคอลแอปพลิเคชันของเราทำงานผ่าน TCP / IP, HTTP และ UDP เมื่อเราเปลี่ยนเป็น Netty เราได้เพิ่ม SSL และ HTTPS ไปยังรายการในไม่กี่นาที! จนถึงตอนนี้ดีมาก แต่เมื่อมาถึง UDP เราก็ตระหนักว่าเราพลาดไปแล้ว MINA เป็นคนดีมากที่เราสามารถใช้ UDP เป็นโปรโตคอล "เชื่อมต่อ" ได้ ภายใต้ Netty ไม่มีสิ่งที่เป็นนามธรรม UDP นั้นไม่มีการเชื่อมต่อและ Netty ถือว่ามันเป็นเช่นนั้น Netty เปิดเผยลักษณะการเชื่อมต่อของ UDP ที่ระดับต่ำกว่า MINA มีสิ่งที่คุณสามารถทำกับ UDP ภายใต้ Netty ได้มากกว่าที่คุณไม่สามารถทำได้ภายใต้นามธรรมระดับสูงที่ MINA นำเสนอ แต่เป็นสิ่งที่เราไว้วางใจ

ไม่ง่ายนักที่จะเพิ่ม wrapper "ที่เชื่อมต่อ UDP" หรืออะไรบางอย่าง กำหนดเวลา จำกัด และตามคำแนะนำของ Trustin ว่าวิธีที่ดีที่สุดในการดำเนินการคือการใช้ผู้ให้บริการขนส่งของเราใน Netty ซึ่งจะไม่รวดเร็วเราต้องละทิ้ง Netty ในที่สุด

ดังนั้นดูความแตกต่างระหว่างพวกเขาอย่างหนักและไปถึงขั้นที่คุณสามารถทดสอบการทำงานที่ยุ่งยากใด ๆ ได้ตามที่คาดไว้ หากคุณพอใจว่า Netty จะทำงานได้ฉันก็ไม่ลังเลเลยที่จะไปกับ MINA หากคุณย้ายจาก MINA ไปยัง Netty แล้วจะมีผลเช่นเดียวกัน แต่ก็น่าสังเกตว่าทั้งสอง API นั้นมีความแตกต่างกันอย่างมากและคุณควรพิจารณาการเขียนเสมือนใหม่สำหรับ Netty - คุณจะไม่เสียใจเลย!


3
Re: ความคิดเห็นก่อนหน้านี้โดย Josh ที่ขาดการสนับสนุน UDP ใน Netty: ฉันไม่เข้าใจว่าทำไมคุณไม่สามารถใช้โค้ดที่สร้างขึ้นด้วยมือสองสามหน้าเพื่อทำสิ่งที่คุณต้องการแทนที่จะละทิ้ง Netty UDP กำลังฟังบนพอร์ตอื่นอยู่แล้ว ฉันทดสอบ Netty กับ Nginx แล้วและค่อนข้างประทับใจ (Netty ให้คะแนนเท่าเดิมหรือดีกว่าภายใต้ภาระงาน)

137

MINA มีคุณสมบัตินอกกรอบในราคาที่ซับซ้อนและมีประสิทธิภาพค่อนข้างต่ำ ฟีเจอร์เหล่านั้นบางส่วนได้ถูกรวมเข้าไว้ในแกนกลางจนแน่นเกินไปที่จะลบออกแม้ว่าผู้ใช้จะไม่ต้องการก็ตาม ใน Netty ฉันพยายามแก้ไขปัญหาการออกแบบในขณะที่ยังคงรักษาจุดแข็งที่รู้จักของ MINA

ปัจจุบันคุณสมบัติส่วนใหญ่ที่มีอยู่ใน MINA ก็มีให้ใน Netty เช่นกัน ในความเห็นของฉัน Netty มี API ที่สะอาดและมีเอกสารมากขึ้นเนื่องจาก Netty เป็นผลมาจากการพยายามสร้าง MINA ใหม่อีกครั้งตั้งแต่เริ่มต้นและแก้ไขปัญหาที่ทราบแล้ว หากคุณพบว่าคุณสมบัติที่สำคัญขาดหายไปโปรดโพสต์ข้อเสนอแนะของคุณในฟอรัม ฉันยินดีที่จะตอบข้อกังวลของคุณ

สิ่งสำคัญคือต้องทราบว่า Netty มีวงจรการพัฒนาที่เร็วขึ้น เพียงตรวจสอบวันที่วางจำหน่ายของรุ่นล่าสุด นอกจากนี้คุณควรพิจารณาว่าทีม MINA จะดำเนินการเขียนใหม่ที่สำคัญคือ MINA 3 ซึ่งหมายความว่าพวกเขาจะทำลายความเข้ากันได้ของ API อย่างสมบูรณ์


21
โอ้ @trustin เป็นผู้แต่งทั้ง MINA และ Netty
Jason Heo

@trustin ฉันพบว่า Netty 5.0 ไม่ได้ให้เอกสารขั้นสูงมากนักและเนื้อหาเว็บในปัจจุบันที่มีเวอร์ชันอื่นจะไม่ทำงาน คุณมีลิงค์แนะนำสำหรับการสอนมินาขั้นกลางและขั้นสูงหรือไม่? ขอบคุณ
Korben

22

ฉันทดสอบการใช้งาน 2 "Google Protobuffer RPC" โดยที่หนึ่งใช้ Netty (netty-protobuf-rpc) และอีกอันอิงตาม mina (protobuf-mina-rpc) Netty สิ้นสุดลงเร็วขึ้นอย่างต่อเนื่อง (+ - 10%) สำหรับทุกขนาดข้อความ - ซึ่งสำรองข้อมูลการเรียกร้องประสิทธิภาพโดยรวมในเว็บไซต์ Netty เนื่องจากคุณต้องการบีบประสิทธิภาพออกมาเล็กน้อยเมื่อคุณใช้ไลบรารี่ RPC ฉันก็เลยเขียนprotobuf-rpc-proขึ้นอยู่กับ Netty ฉันเคยใช้ MINA ในอดีต แต่พบว่าเอกสารของพวกเขาในเนื้อหา 2.0 มีรูขนาดใหญ่และการทำลายความเข้ากันได้ของ API แบบย้อนหลังเป็นเรื่องใหญ่


16

MINA และ Netty เริ่มแรกออกแบบและสร้างโดยผู้เขียนคนเดียวกัน นั่นเป็นเหตุผลที่พวกเขามีความคุ้นเคยกัน MINA ได้รับการออกแบบในระดับที่สูงขึ้นเล็กน้อยพร้อมกับคุณสมบัติเพิ่มเติมเล็กน้อยในขณะที่ Netty นั้นเร็วกว่าเล็กน้อย ฉันคิดว่ามันไม่แตกต่างกันมากแนวคิดพื้นฐานเหมือนกัน


9

ในไซต์ Netty คุณสามารถค้นหารายงานประสิทธิภาพได้ ตามที่คาดไว้ :-) พวกเขาชี้ให้เห็นว่า Netty เป็นกรอบที่มีประสิทธิภาพที่ดีที่สุด

ฉันไม่เคยใช้ Netty แต่ฉันใช้ MINA เพื่อใช้โปรโตคอล TCP แล้ว การใช้การเข้ารหัสและถอดรหัสนั้นง่าย แต่การใช้งานเครื่องรัฐนั้นไม่ง่ายนัก MINA ให้ชั้นเรียนบางอย่างเพื่อช่วยเหลือคุณเมื่อใช้งานเครื่องรัฐ แต่ฉันพบว่ามันใช้งานยาก ในตอนท้ายเราตัดสินใจทิ้ง MINA และใช้โปรโตคอลตั้งแต่เริ่มต้นและแปลกใจที่เราจบลงด้วยเซิร์ฟเวอร์ที่เร็วขึ้น


5

ฉันชอบ Netty

Twitter เลือก Netty เพื่อสร้างระบบการค้นหาใหม่และเร็วขึ้นถึง 3 เท่า

Ref: การค้นหา Twitter เร็วขึ้น 3 เท่า

เราเลือก Netty มากกว่าคู่แข่งรายอื่น ๆ เช่น Mina และ Jetty เนื่องจากมี API ที่สะอาดกว่าเอกสารที่ดีกว่าและที่สำคัญกว่านั้นเพราะโครงการอื่น ๆ ที่ Twitter กำลังใช้เฟรมเวิร์กนี้


4

ฉันเคยใช้ MINA เพื่อสร้าง http เช่นเซิร์ฟเวอร์ขนาดเล็ก ปัญหาที่ใหญ่ที่สุดที่ฉันเคยพบมาจนถึงตอนนี้:

  1. จะถือ "คำขอ" และ "ตอบสนอง" ของคุณในหน่วยความจำ นี่เป็นเพียงปัญหาเนื่องจากโปรโตคอลที่ฉันเลือกใช้คือ http คุณสามารถใช้โปรโตคอลของคุณเองเพื่อหลีกเลี่ยงปัญหานี้
  2. ไม่มีตัวเลือกให้สตรีมดิสก์ในกรณีที่คุณต้องการแสดงไฟล์ขนาดใหญ่ สามารถแก้ไขได้อีกครั้งโดยใช้โปรโตคอลของคุณเอง

สิ่งที่ดีเกี่ยวกับมัน:

  1. สามารถรองรับการเชื่อมต่อได้มากมาย
  2. หากคุณเลือกที่จะใช้ระบบงานแบบกระจายบางอย่างดังนั้นเมื่อรู้ว่าโหนดใดโหนดหนึ่งของคุณล่มและสูญเสียการเชื่อมต่อจะมีประโยชน์สำหรับการรีสตาร์ทงานบนโหนดอื่น

เมื่อคุณพูดว่า "สตรีมดิสก์สำหรับไฟล์ขนาดใหญ่" คนทั่วไปจะไม่ใช้ UDP สำหรับสิ่งนั้น
djangofan

1
ไม่พวกเขาใช้เคอร์เนล sendfile (เปิดเผยใน Java เป็น FileChannel.transferTo) ผ่าน TCP
jbellis
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.