रेल + काफ्का पर एक सेवा उन्मुख वास्तुकला का निर्माण

नमस्कार, हेब्र! मैं आपके सामने पोस्ट प्रस्तुत करता हूं, जो कि RailsConf 2018 में स्टेला कॉटन के प्रदर्शन का एक पाठ अनुकूलन है और स्टैला कॉटन द्वारा लेख "बिल्डिंग ए सर्विस ओरिएंटेड आर्किटेक्चर विथ रेल्स एंड काफ्का" का अनुवाद है।

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

काफ्का क्या है

मुझे यकीन है कि आप इस बारे में जानकारी प्राप्त करना चाहेंगे कि आपके उपयोगकर्ता आपके प्लेटफ़ॉर्म पर कैसे आए या वे किन पृष्ठों पर जाते हैं, वे किस बटन पर क्लिक करते हैं, आदि। वास्तव में लोकप्रिय एप्लिकेशन अरबों घटनाओं को उत्पन्न कर सकता है और एनालिटिक्स सेवाओं के लिए बड़ी मात्रा में डेटा भेज सकता है, जो आपके आवेदन के लिए एक गंभीर चुनौती हो सकती है।

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



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

काफ्का में एक असफल-सुरक्षित वास्तुकला भी है। सिस्टम एक या एक से अधिक सर्वरों पर एक क्लस्टर के रूप में चलता है, जिसे नई मशीनों को जोड़कर क्षैतिज रूप से बढ़ाया जा सकता है। सभी डेटा को डिस्क पर लिखा जाता है और कई दलालों को कॉपी किया जाता है। स्केलेबिलिटी की संभावनाओं को समझने के लिए नेटफ्लिक्स, लिंक्डइन, माइक्रोसॉफ्ट जैसी कंपनियों पर कटाक्ष करने लायक है। वे सभी अपने काफ़्का समूहों के माध्यम से प्रति दिन खरबों संदेश भेजते हैं!

रेलों में काफ्का स्थापित करना

हरोकू एक काफ्का क्लस्टर ऐड प्रदान करता है जिसका उपयोग किसी भी पर्यावरण के लिए किया जा सकता है। माणिक अनुप्रयोगों के लिए, हम माणिक-काफ्का मणि का उपयोग करने की सलाह देते हैं। न्यूनतम कार्यान्वयन कुछ इस तरह दिखता है:

# config/initializers/kafka_producer.rb require "kafka" # Configure the Kafka client with the broker hosts and the Rails # logger. $kafka = Kafka.new(["kafka1:9092", "kafka2:9092"], logger: Rails.logger) # Set up an asynchronous producer that delivers its buffered messages # every ten seconds: $kafka_producer = $kafka.async_producer( delivery_interval: 10, ) # Make sure to shut down the producer when exiting. at_exit { $kafka_producer.shutdown } 

कॉन्फ़िगरेशन को कॉन्फ़िगर करने के बाद, आप संदेश भेजने के लिए मणि का उपयोग कर सकते हैं। घटनाओं के अतुल्यकालिक भेजने के लिए धन्यवाद, हम कहीं से भी संदेश भेज सकते हैं:

 class OrdersController < ApplicationController def create @comment = Order.create!(params) $kafka_producer.produce(order.to_json, topic: "user_event", partition_key: user.id) end end 

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

आपकी सेवाओं के लिए काफ्का

काफ्का को एक उपयोगी उपकरण बनाने वाली कुछ विशेषताएं भी इसे सेवाओं के बीच एक असफल आरपीसी बनाती हैं। ई-कॉमर्स एप्लिकेशन के एक उदाहरण पर एक नज़र डालें:

 def create_order create_order_record charge_credit_card # call to Payments Service send_confirmation_email # call to Email Service end 

जब उपयोगकर्ता एक आदेश देता है, तो create_order फ़ंक्शन create_order । यह सिस्टम में एक ऑर्डर बनाता है, कार्ड से पैसे काटता है और पुष्टि के साथ एक ईमेल भेजता है। जैसा कि आप देख सकते हैं, अंतिम दो कदम अलग-अलग सेवाओं में निकाले गए हैं।



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

उदाहरण के लिए:



इस घटना-संचालित दृष्टिकोण में, एक बेहतर सेवा कफका में एक घटना रिकॉर्ड कर सकती है कि एक आदेश बनाया गया है। तथाकथित कम से कम एक बार दृष्टिकोण के कारण, घटना कम से कम एक बार काफ्का में दर्ज की जाएगी और पढ़ने के लिए डाउनस्ट्रीम उपभोक्ताओं के लिए उपलब्ध होगी। यदि पत्र भेजने की सेवा झूठ है, तो घटना डिस्क पर इंतजार करेगी जब तक कि उपभोक्ता उठता है और इसे पढ़ता है।

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

सेवा उन्मुख वास्तुकला में घटनाओं को एकीकृत करना

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

आइए नज़र डालते हैं कि ये पैटर्न क्या हैं। यदि आप अधिक जानना चाहते हैं, तो मैं आपको GOTO शिकागो 2017 में उनकी रिपोर्ट पढ़ने की सलाह देता हूं।

घटना की सूचना

पहले Fowler पैटर्न को इवेंट नोटिफिकेशन कहा जाता है। इस परिदृश्य में, निर्माता सेवा घटना के उपभोक्ताओं को न्यूनतम जानकारी के साथ सूचित करती है:

 { "event": "order_created", "published_at": "2016-03-15T16:35:04Z" } 

यदि उपभोक्ताओं को घटना के बारे में अधिक जानकारी की आवश्यकता होती है, तो वे निर्माता से अनुरोध करते हैं और अधिक डेटा प्राप्त करते हैं।

ईवेंट-आधारित राज्य स्थानांतरण

दूसरे टेम्पलेट को इवेंट-कैरीड स्टेट ट्रांसफर कहा जाता है। इस परिदृश्य में, निर्माता ईवेंट के बारे में अतिरिक्त जानकारी प्रदान करता है और उपभोक्ता अतिरिक्त कॉल किए बिना इस डेटा की एक प्रति संग्रहीत कर सकता है:

 { "event": "order_created", "order": { "order_id": 98765, "size": "medium", "color": "blue" }, "published_at": "2016-03-15T16:35:04Z" } 

घटना के सहयोग से

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

इस दृष्टिकोण के साथ बड़ी समस्या यह है कि एप्लिकेशन कोड हमेशा बदलता रहता है, और इसके साथ निर्माता जो डेटा देता है उसका प्रारूप या राशि बदल सकता है। यह अनुप्रयोग समस्याग्रस्त स्थिति को पुनर्स्थापित करता है।

कमांड क्वेरी जिम्मेदारी अलगाव

और अंतिम टेम्पलेट कमांड क्वेरी रिस्पॉन्सिबिलिटी सेग्रिगेशन या CQRS है। विचार यह है कि आप जिन कार्यों को ऑब्जेक्ट पर लागू करते हैं, उदाहरण के लिए: बनाएं, पढ़ें, अपडेट करें, उन्हें अलग-अलग डोमेन में विभाजित किया जाना चाहिए। इसका मतलब है कि एक सेवा को निर्माण के लिए जिम्मेदार होना चाहिए, दूसरे को अपडेट के लिए, आदि। ऑब्जेक्ट-ओरिएंटेड सिस्टम में, सब कुछ अक्सर एक सेवा में संग्रहीत किया जाता है।



एक सेवा जो डेटाबेस को लिखती है वह घटनाओं और प्रक्रिया आदेशों के प्रवाह को पढ़ेगी। लेकिन कोई भी अनुरोध केवल पढ़ने के लिए केवल डेटाबेस में होता है। पढ़ने और लिखने के तर्क को दो अलग-अलग सेवाओं में विभाजित करने से जटिलता बढ़ जाती है, लेकिन आप इन प्रणालियों के लिए अलग से प्रदर्शन का अनुकूलन कर सकते हैं।

समस्याओं

आइए काफ़्का को अपने सेवा-उन्मुख अनुप्रयोग में एकीकृत करते समय आपके सामने आने वाली कुछ समस्याओं के बारे में बात करें।

पहली समस्या धीमी उपभोक्ता वाली हो सकती है। एक इवेंट-ओरिएंटेड सिस्टम में, आपकी सेवाओं को किसी बेहतर सेवा से प्राप्त होने पर तुरंत घटनाओं को संसाधित करने में सक्षम होना चाहिए। अन्यथा, वे समस्या या टाइमआउट के बारे में किसी भी अलर्ट के बिना बस लटकाएंगे। एकमात्र स्थान जहां आप टाइमआउट परिभाषित कर सकते हैं, काफ्का दलालों के साथ एक सॉकेट कनेक्शन है। यदि सेवा घटना को जल्दी से संसाधित नहीं करती है, तो कनेक्शन को टाइमआउट द्वारा बाधित किया जा सकता है, लेकिन सेवा को पुनर्स्थापित करने के लिए अतिरिक्त समय की आवश्यकता होती है, क्योंकि ऐसी सॉकेट्स बनाना महंगा है।

यदि उपभोक्ता धीमा है, तो आप घटना प्रसंस्करण की गति कैसे बढ़ा सकते हैं? काफ्का में, आप एक समूह में उपभोक्ताओं की संख्या बढ़ा सकते हैं, इसलिए अधिक घटनाओं को समानांतर में संसाधित किया जा सकता है। लेकिन एक सेवा के लिए कम से कम 2 उपभोक्ताओं की आवश्यकता होगी: यदि एक गिरता है, तो क्षतिग्रस्त वर्गों को फिर से सौंपा जा सकता है।

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

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

डेटा प्रारूप

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

इवेंट-ओरिएंटेड आर्किटेक्चर बनाने से पहले, एक डेटा फॉर्मेट चुनें और विश्लेषण करें कि भविष्य में योजनाओं को पंजीकृत करने और विकसित करने में कैसे मदद मिलेगी।

उपयोग के लिए अनुशंसित प्रारूपों में से एक, निश्चित रूप से JSON है। यह प्रारूप मानव-पठनीय है और सभी ज्ञात प्रोग्रामिंग भाषाओं द्वारा समर्थित है। लेकिन वहाँ नुकसान कर रहे हैं। उदाहरण के लिए, JSON में अंतिम डेटा का आकार भयावह रूप से बड़ा हो सकता है। कुंजी-मूल्य जोड़े को संग्रहीत करने के लिए प्रारूप की आवश्यकता होती है, जो काफी लचीला होता है, लेकिन प्रत्येक घटना में डेटा को डुप्लिकेट किया जाता है। स्कीमा को बदलना भी एक मुश्किल काम है क्योंकि यदि आपको फ़ील्ड का नाम बदलने की आवश्यकता है, तो एक कुंजी को दूसरे पर ओवरले करने के लिए कोई अंतर्निहित समर्थन नहीं है।

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

एवरो-बिल्डर Salsify द्वारा निर्मित एक रत्न है जो स्कीमा बनाने के लिए रूबी जैसा डीएसएल प्रदान करता है। आप इस लेख में एवरो के बारे में अधिक पढ़ सकते हैं।

अतिरिक्त जानकारी

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

जेफ चाओ के DataEngConf SF '17 में " 50,000 से अधिक विभाजन: कैसे हेरोकू संचालित होता है और स्केल पर काफ्का की सीमा को बढ़ाता है"

ड्रीमफुल '16 'में पावेल प्रोवोसुद " डॉगफूडिंग काफ्का: हमने हरकोक का रियल-टाइम प्लेटफ़ॉर्म इवेंट स्ट्रीम सम्मेलन" कैसे बनाया

अच्छा दृश्य है!