फिनगले में सेवाओं, फ़िल्टर और कोडेक्स के बीच सीमाएं

Question

नेटटी, जिसे फिनगेल के भीतर उपयोग किया जाता है, अनुक्रमिक रूप से बाध्य डेटा को संसाधित करने के लिए "हैंडलर" की पाइपलाइन का उपयोग करता है। नेटटी उदाहरण, और पुस्तकालयों को शामिल किया गया है, प्रमाणीकरण, प्रोटोकॉल कोडेक्स, और सेवा के वास्तविक व्यापार तर्क जैसी चीजों के लिए उपयोग किए जाने वाले विभिन्न हैंडलर दिखाएं।

फ़ाइनगेल हैंडलर अवधारणा लेता प्रतीत होता है, और इसके बजाय सीधे एपीआई उपयोगकर्ता कोडेक्स, फ़िल्टर और सेवाएं प्रदान करता है। हालांकि इनके अलग-अलग हस्ताक्षर हैं, फिनगेल के नए उपयोगकर्ता अपने समग्र सर्वर के प्रत्येक हिस्से को लागू करने के लिए उपयोग करने के लिए निर्णय लेने के कार्यों के साथ छोड़ दिए जाते हैं। विभिन्न नेटी हैंडलर में चेन को तोड़ने का निर्णय लेने के बजाय, अब उन्हें यह तय करने की आवश्यकता है कि श्रृंखला के अंत में एकवचन सेवा बनाम किसी भी फ़िल्टर के विरुद्ध कौन सा हिस्सा कोडेक का हिस्सा होना चाहिए। संक्षेप में, हालांकि फिनगेल नेटटी की तुलना में उच्च स्तरीय लाइब्रेरी है, और सेवा को आसान बनाने का कार्य करना चाहिए, एपीआई उपयोगकर्ता के पास अधिक विकल्प हो सकते हैं।

प्रसंस्करण धारा के एक विशेष भाग को कोडेक बनाम एक सिंगल सेवा बनाम फ़िल्टर करने के लिए महत्वपूर्ण निर्णय बिंदु, और पेशेवर/विपक्ष क्या हैं? यदि कोई संभावना है कि पाइपलाइन को आगे बढ़ाया जा सकता है, तो पाइपलाइन के अंत में "नोप" सेवा के साथ सेवा तर्क को फ़िल्टर में रखा जाना चाहिए? फ़िल्टर को ऑर्डर करने में लचीलापन (पाइपलाइन में हैंडलर के रूप में), एक तरफ एकवचन कोडेक बनाम और दूसरी छोर पर सेवा, "सब कुछ" फ़िल्टर क्यों नहीं होना चाहिए?

Answer 1

फिनगल और नेटटी को काफी अलग तरीके से संरचित किया गया है।

सेवाएं, फ़िल्टर और कोडेक वास्तव में काफी ऑर्थोगोनल अवधारणाएं हैं। मुझे & समझाएं। एक उपयोगकर्ता के रूप में - यानी। कोडेक के कार्यान्वयनकर्ता नहीं - आपको केवल सेवाओं और फ़िल्टर के बारे में जानना चाहिए।

सबसे पहले, एक कोडेक एक अलग अनुरोध या प्रतिक्रियाओं में बाइट्स की धारा को बदलने के लिए ज़िम्मेदार है। उदाहरण के लिए, HTTP कोडेक बाइटस्ट्रीम पढ़ता है, और HttpRequest या HttpResponse ऑब्जेक्ट्स का उत्पादन करता है।

एक Service एक उद्देश्य यह है कि, एक अनुरोध को देखते हुए, एक उत्तर के Future का उत्पादन होता है - यह एक साधारण समारोह है (और वास्तव में यह Function फैली)।सेवाओं के बारे में दिलचस्प बात यह है कि वे सममित हैं। एक ग्राहक एक सेवा का उपयोग करता है, एक सर्वर एक प्रदान करता है। सेवाओं के बारे में महत्वपूर्ण बात यह है कि (1) वे अलग-अलग अनुरोधों और प्रतिक्रियाओं पर काम करते हैं, और (2) वे प्रतिक्रियाओं के अनुरोधों से मेल खाते हैं - जिनमें से सभी इसके प्रकार से निहित हैं। यही कारण है कि हम एक "आरपीसी" प्रणाली को फाइनल कहते हैं - अनुरोध/प्रतिक्रिया जोड़े आरपीसी की परिभाषित विशेषता हैं।

तो, हमारे पास सेवाएं हैं, लेकिन यह सेवा व्यवहार सेवा सेवा से स्वतंत्र रूप से सेवा व्यवहार को संशोधित करने के लिए उपयोगी और महत्वपूर्ण है। उदाहरण के लिए, हम टाइमआउट कार्यक्षमता, या पुनः प्रयास करना चाहते हैं। यह Filter एस है। वे सेवा व्यवहार को संशोधित करने के लिए सेवा स्वतंत्र विधि प्रदान करते हैं। यह बढ़ाया मॉड्यूलरिटी और पुन: उपयोग। उदाहरण के लिए, फाइनल में टाइमआउट फ़िल्टर के रूप में लागू किए जाते हैं, और किसी भी सेवा पर लागू किया जा सकता है।

आप में & फ़िल्टर के बारे में अधिक जानकारी प्राप्त कर सकते हैं।

*

तो चलिए Netty के संचालकों को यह विपरीत करते हैं। ये सामान्य घटना हैंडलर हैं, जो भी ढेर हैं। आप उनके साथ कई समान चीजें कर सकते हैं, लेकिन अंतर्निहित मॉडल एक कनेक्शन से जुड़े घटनाओं के धारा है। यह जेनेरिक मॉड्यूल लिखने में अधिक कठिन बनाता है (उदाहरण के लिए, रीट्रीज़, टाइमआउट्स, विफलता संचय, ट्रेसिंग, अपवाद रिपोर्टिंग इत्यादि को लागू करने के लिए ..) क्योंकि आप जिस पाइपलाइन के साथ काम कर रहे हैं उसके बारे में कई धारणाएं नहीं कर सकते हैं।

नेटटी पाइपलाइन भी एप्लिकेशन हैंडलर के साथ प्रोटोकॉल कार्यान्वयन को भंग करती है। Finagle दोनों को अलग से अलग करता है, और इसके कारण मॉड्यूलरिटी बढ़ाया जाता है।

नेटटी abstractions का एक अद्भुत सेट है, लेकिन आरपीसी सर्वर के लिए, फाइनल अधिक मॉड्यूलरिटी और composability प्रदान करता है।

*

सारांश कुदरती तौर से आप कह सकते हैं कि Netty "धारा" उन्मुख फिनेक्ल "सेवा उन्मुख" है, जबकि है। यह एक महत्वपूर्ण भेद है, और यह हमें मॉड्यूलर तरीके से मजबूत आरपीसी सेवाओं को लागू करने की अनुमति देता है। उदाहरण के लिए, कनेक्शन पूलिंग और लोड संतुलन - आरपीसी ग्राहकों के लिए महत्वपूर्ण रूप से महत्वपूर्ण - सेवा मॉडल से स्वाभाविक रूप से बाहर निकलना, लेकिन स्ट्रीम मॉडल में फिट नहीं है।

Answer 2

मुझे नहीं लगता कि यह कोडेक या फ़िल्टर के बीच एक निर्णय होना चाहिए। कोडेक्स फिल्टर में लपेटा जाएगा।

निर्णय तर्क के लिए, इसे कहां रखा जाए, यह निर्णय लेने पर निर्भर करेगा। व्यापार निर्णयों को आपके व्यापार तर्क के साथ जाना चाहिए, जबकि रूटिंग, भार संतुलन, कुछ प्रकार के अभिगम नियंत्रण इत्यादि जैसे कुछ निर्णय फ़िल्टर के रूप में अच्छी तरह से फिट हो सकते हैं।

सेवाएं आमतौर पर लाइन के अंत में बैठती हैं, और इसके फ़िल्टर के साथ फिनगेल आपको वहां ले जाएगा।

पता नहीं है कि यह समझ में आता है या नहीं?

बस एक पल के लिए तकनीकी विवरण से दूर कदम उठाएं, और तर्क देखें। इसके लिए ज़िम्मेदार होना चाहिए, और फिर अपने डिजाइन को फिट करने के लिए तकनीक प्राप्त करें। तकनीक को फिट करने के लिए अपने डिजाइन को बहुत ज्यादा मोड़ो मत।

वैसे, मैंने फिनगेल के शीर्ष पर गेटवे सर्वर लागू किया है, और मुझे यह कहना होगा: यह काम करने के लिए एक अच्छी लाइब्रेरी है।

मुझे नहीं पता कि आप क्या बनाने की कोशिश कर रहे हैं, लेकिन संभावित विकल्प भी देखें: स्प्रे, ब्लूएज़, अनफिल्टर, प्ले-मिनी इत्यादि। यह आपको कहां जाता है इसकी बेहतर समझ प्राप्त करने में मदद कर सकता है।