سؤال

كلاهما توفر تقريبا نفس الوظائف.أي واحد يجب أن تختار لتطوير عالية الأداء TCP خادم ؟ ما هي إيجابيات وسلبيات?

إشارة الروابط:

أباتشي مينا (المصدر)

Netty (المصدر)

هل كانت مفيدة؟

المحلول

وعلى الرغم MINA وNetty ديك طموحات مماثلة، فهي مختلفة تماما في الممارسة، ويجب عليك أن تنظر بعناية اختيارك. كنا محظوظين في أن كان لدينا الكثير من الخبرة مع MINA، وكان الوقت للعب مع حولها Netty. كنا لا سيما API الأنظف وثائق أفضل بكثير. يبدو أداء أفضل على الورق أيضا. والأهم من ذلك أننا كنا نعلم أن Trustin لي سيكون على استعداد للإجابة على أي أسئلة كان لدينا، وفعله بالتأكيد ذلك.

ولقد وجدنا كل شيء أسهل في Netty. فترة. بينما كنا نحاول reimplement نفس الوظائف كان لدينا بالفعل على MINA، فعلنا ذلك من نقطة الصفر. من خلال اتباع وثائق ممتازة وأمثلة انتهى مع المزيد من الوظائف في الكثير، وأقل من ذلك بكثير التعليمات البرمجية.

ووNetty خط أنابيب عمل أفضل بالنسبة لنا. انها أبسط بطريقة أو بأخرى من ميناس، حيث كل شيء معالج والأمر متروك لك لتقرر ما إذا كانت معالجة الأحداث المنبع، والأحداث المصب، على حد سواء أو تستهلك أكثر الاشياء على مستوى منخفض. التهام بايت في "تعيد" كانت أجهزة فك التشفير تقريبا من دواعي سروري. وكان أيضا لطيف جدا لتكون قادرة على إعادة تكوين خط أنابيب على ذبابة على ذلك بسهولة.

ولكن جاذبية نجم Netty، إيمهو، هو القدرة على إنشاء معالجات خط أنابيب مع "تغطية واحدة". وربما كنت قد قرأت عن هذه التغطية الشرح بالفعل في وثائق، ولكن أساسا أنها تعطيك الدولة في سطر واحد من التعليمات البرمجية. ومع عدم وجود العبث، لا خرائط الدورة، تزامن وأشياء من هذا القبيل، كنا ببساطة قادرين على التصريح المتغيرات العادية (ويقول، "اسم المستخدم") واستخدامها.

ولكن بعد ذلك نحن ضرب حاجز. كان لدينا بالفعل خادم متعدد البروتوكولات تحت MINA، الذي ركض لدينا بروتوكول التطبيق عبر TCP / IP، HTTP و UDP. عندما تحولنا إلى Netty أضفنا SSL و HTTPS إلى القائمة في غضون دقائق! حتى الآن جيد جدا، ولكن عندما يتعلق الأمر UDP أدركنا أننا قد تسللوا تصل. MINA كان لطيفا جدا بالنسبة لنا لأننا يمكن علاج UDP كبروتوكول "متصل". تحت Netty لا يوجد مثل هذا التجريد. UDP هو بدون اتصال وNetty يعامل على هذا النحو. Netty يعرض أكثر من الطبيعة بدون اتصال من UDP على مستوى أدنى من MINA يفعل. هناك أشياء يمكنك القيام به مع UDP تحت Netty مما كنت لا يمكن تحت التجريد على المستوى العالي الذي يوفر MINA، ولكن الذي اعتمدنا.

وانها ليست بهذه البساطة لإضافة "اتصال UDP" المجمع أو شيء من هذا. نظرا لضيق الوقت وبناء على نصيحة Trustin بأن أفضل طريقة للمضي قدما هي تنفيذ رزقنا النقل الخاصة في Netty، والتي لن تكون سريعة، كان علينا أن التخلي عن Netty في نهاية المطاف.

وهكذا، نظرة فاحصة على الخلافات بينهما وبسرعة تصل إلى مرحلة حيث يمكنك اختبار تعمل أي وظيفة صعبة كما هو متوقع. إذا كنت مقتنعا بأن Netty سوف قيام بهذه المهمة، ثم فإنني لن أتردد للذهاب معها على MINA. إذا كنت تتحرك من MINA إلى Netty ثم ينطبق الشيء نفسه، ولكن تجدر الإشارة إلى أن واجهات برمجة التطبيقات مختلفان بشكل كبير حقا، ويجب عليك أن تنظر إعادة كتابة افتراضية لNetty - فلن نأسف لذلك

نصائح أخرى

وMINA ديه المزيد من الميزات خارج المربع، وعلى حساب من التعقيد وفقيرة نسبيا الأداء. تم دمج بعض تلك الميزات في صلب محكم جدا بحيث لا يمكن إزالتها حتى لو لم تكن هناك حاجة إليها من قبل مستخدم. في Netty، حاولت لمعالجة القضايا تصميم هذه مع الإبقاء على نقاط القوة المعروفة MINA.

وحاليا، معظم الميزات المتوفرة في MINA تتوفر في Netty أيضا. في رأيي، Netty ديه API أكثر نظافة وموثقة منذ Netty هو نتيجة لمحاولة إعادة بناء MINA من الصفر ومعالجة المشكلات المعروفة. إذا وجدت أن سمة أساسية مفقود، لا تتردد في الرد على اقتراحك للمنتدى. سأكون سعيدا لمعالجة مشكلتك.

ومن المهم أيضا أن نلاحظ أن Netty ديه دورة تطوير أسرع. ببساطة، تحقق من تاريخ إصدار النشرات الأخيرة. أيضا، يجب أن تفكر في أن فريق MINA سوف تشرع في إعادة كتابة الرئيسية، MINA 3، وهو ما يعني أنها سوف كسر التوافق API تماما.

اختبار

وأداء I 2 "جوجل Protobuffer RPC" تطبيقات حيث استند على واحد Netty (netty-protobuf جنة الحماية من الإشعاع) والآخر على أساس مينا (protobuf-مينا-RPC). انتهت Netty الأمر أسرع باستمرار (+ - 10٪) لجميع الأحجام الرسالة - التي تدعم المطالبة الأداء الكلي على موقع على شبكة الإنترنت Netty. منذ كنت تريد للضغط على كل شيء من الكفاءة من التعليمات البرمجية الخاصة بك عند استخدام مثل مكتبة RPC، انتهى بي الأمر كتابة <لأ href = "http://code.google.com/p/protobuf-rpc-pro/" يختلط = "noreferrer"> protobuf جنة الحماية من الإشعاع المؤيد على أساس Netty. ولقد استخدمت MINA في الماضي، ولكن العثور على وثائق من الاشياء 2.0 لديه ثقوب كبيرة، وكسر API التوافق ناقص كبير.

وMINA وNetty صممت في البداية، وبناء من قبل المؤلف نفسه. هذا هو السبب في أنها مماثلة وذلك لبعضها البعض. تم تصميم MINA على مستوى أعلى قليلا مع القليل من المزيد من الميزات، بينما Netty هو أسرع قليلا. أعتقد أن ليس هناك فرق كبير في كل شيء، والمفاهيم الأساسية هي نفسها.

في الموقع Netty يمكنك أن تجد بعض أداء تقارير . كما هو متوقع :-) يشيرون Netty كإطار مع أفضل أداء.

وأنا لم تستخدم قط Netty، ولكني استخدمت بالفعل MINA لتنفيذ بروتوكول TCP. وكان تنفيذ فك التشفير والترميز سهلا، ولكن كان تنفيذ جهاز الدولة ليس من السهل. يوفر MINA بعض الفئات لمساعدتك عند تنفيذ جهاز الدولة، ولكن وجدت لها نوع من الصعب استخدام. في النهاية قررنا التخلي MINA وتنفيذ بروتوكول من نقطة الصفر، والغريب أننا انتهت خادم أسرع.

وأنا أفضل Netty.

كما اختار

وتويتر Netty لبناء نظام البحث الجديد، وأسرعت ليصل إلى 3x أسرع.

المرجع: تويتر بحث والآن 3x أسرع

<اقتباس فقرة>   

ولقد اخترنا Netty على بعض منافسيها الآخرين، مثل منى وجيتي، لأنه يحتوي على API الأنظف، وثائق أفضل، والأهم من ذلك، لأن العديد من المشاريع الأخرى في تويتر يستخدمون هذا الإطار.

لقد استخدمت من أي وقت مضى مينا لبناء صغيرة مثل http server.أكبر المشاكل التي واجهتني مع ذلك حتى الآن:

  1. أنه سوف يعقد الخاص بك "طلب" و "الاستجابة" في الذاكرة.هذه هي المشكلة فقط لأن البروتوكول اخترت استخدام http.يمكنك استخدام الخاص بك بروتوكول ومع ذلك للالتفاف حول هذا.
  2. لا خيار لتوفير تيار قبالة القرص في حال كنت تريد أن تخدم حتى الملفات الكبيرة.مرة أخرى يمكن عمل حول تنفيذ البروتوكول الخاص

أشياء لطيفة حول هذا الموضوع:

  1. يمكن التعامل مع الكثير من الاتصالات
  2. إذا اخترت لتنفيذ بعض نوع من توزيع نظام العمل ثم معرفة عند واحد من العقد الخاص بك وتنخفض يفقد اتصال مفيدة في إعادة العمل على عقدة أخرى.
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top