सेवा उन्मुख वास्तुकला - परिवहन परत (मैसेजिंग बनाम http)

Question

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

HTTP (REST, SOAP, आदि) के बजाय मैसेजिंग सिस्टम (रेडिस, खरगोश, ईएमएस, अन्य उल्लेखनीय अपवाद जिन्हें मैंने नहीं सुना है) का उपयोग करने में बड़ा प्रदर्शन/कार्यक्षमता लाभ होगा।

मैं इस विषय पर अच्छी जानकारी और खोजने के लिए संघर्ष किया है (जैसा कि आप शायद बता सकते हैं) मैं काफी इस तरफ क्षेत्र के लिए नया हूँ, इसलिए किसी भी सलाह या अच्छे संसाधन की सराहना की होगी!

Thnaks

Answer 1

क्या @Will Hartung उल्लेख के अलावा, मैं भी यही कहूंगा कि यह आप अपने सिस्टम के साथ क्या करने जा रहे हैं पर निर्भर करता है। यदि आपके पास अधिकतर क्लाइंट-सर्वर प्रकार के अनुप्रयोग हैं, जहां आपके पास कुछ सर्वर/सेवाएं हैं और वे पूरी तरह से स्वतंत्र हैं, तो संभवतः HTTP पर आरईएसटी के माध्यम से सेवा अनुबंधों को कार्यान्वित करना आसान होगा।

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

संदेश का उपयोग करने के लिए उन्हें मुख्य लाभ यह है कि आप प्रत्येक प्रकार के संदेश के लिए कतार प्राप्त कर सकते हैं, ताकि आपकी प्रणाली विस्तार और परिवर्तन हो सके, कतार/संदेश समान हो सकते हैं, लेकिन सेवा जो उन्हें संभालने वाली सेवा नीचे बदल सकती है। यह परतों को अलग करने को बढ़ावा देता है।

अंत में, और यह मेरी राय में एक बड़ी बात है, संदेश का उचित उपयोग कोड के छोटे, स्वतंत्र टुकड़े को बढ़ावा देता है। ये दोनों अधिक टेस्टेबल और अधिक रखरखाव योग्य हैं, और सामान्य रूप से यह आपके उद्यम वास्तुकला को सरल बनाता है। यदि आप HTTP एंडपॉइंट्स से बहुत सी सेवाओं को संभालने का प्रयास करते हैं, तो आप अंततः (एक या दो साल के दौरान) अंत में (1) रास्ते को ट्रैक रखने के लिए बहुत से अंतराल या (2) स्पेगेटी कोड की एक अनजान गड़बड़ी के साथ समाप्त हो जाएंगे ।

मेरी कंपनी ने एक संदेश-आधारित ढांचे का उपयोग शुरू किया, और यह हमारे लिए बहुत अच्छा काम करता है। RabbitMQ सर्वर आसानी से सबसे विश्वसनीय घटक रहा है। यह पूछने के लिए स्वतंत्र महसूस करें कि संदेश या एसओए के बारे में आपके कोई और प्रश्न हैं या नहीं।

Answer 2

संदेश आप एक अधिक शिथिल युग्मित वास्तुकला देने के लिए जाता है। यह संभावित रूप से अधिक मजबूत हो सकता है, क्योंकि व्यक्तिगत घटक पूरे बुनियादी ढांचे को मारने के बिना असफल हो सकते हैं।

नकारात्मक पक्ष यह जटिलता, एक अतुल्यकालिक मॉडल के लिए बदलाव, और संभवतः प्रदर्शन है (खासकर यदि आप संदेशों बने रहे हर जगह)।

तुम भी सुनिश्चित करें कि आपके संदेश प्रणाली विशेष रूप से मजबूत है की जरूरत है। आपके तर्क का एक पहलू नीचे जा सकता है और सबकुछ प्रभावित किए बिना पुनरारंभ हो सकता है, लेकिन यदि आप अपना मूल संदेश आधार खो देते हैं, तो आपके सभी तर्क मैसेजिंग का बैकअप लेने की प्रतीक्षा कर रहे हैं।

सौभाग्य से, संदेश बस नगण्य है और यह, किसी भी प्रणाली में त्रुटियों और अस्थिरता का सबसे बड़ा स्रोत को छूने के मनुष्यों के बिना लंबे समय तक चल रहा है हो सकता है।