😓 🔝 🍞 Mikroservisy। एकीकरण और यह इतना महत्वपूर्ण क्यों है। भाग 1

परिचय

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

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

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

मैं हर किसी से बिल्ली के नीचे दिलचस्पी लेने के लिए कहता हूं।

समस्या

शायद एक सेवा को विकसित करने में आपके सामने पहली चीज इसकी कॉन्फ़िगरेशन विधियां हैं। माइक्रोसॉर्स्क आर्किटेक्चर में, यह मुद्दा और भी तीव्र हो जाता है।

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

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

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

विनिर्देश

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

सिस्टम की आवश्यकताएं

आइए अपने सिस्टम और इसके लिए आवश्यकताओं को परिभाषित करके शुरू करें।

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

कॉन्फ़िगरेशन विधि आवश्यकताएँ

अब हम तय करते हैं कि सभी आवश्यकताओं को पूरा करने के लिए हम अपने कॉन्फ़िगरेशन विधि से क्या देखना चाहते हैं।

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

कॉन्फ़िगरेशन उदाहरण

मान लीजिए कि हमारे पास एक ऐसी सेवा है जिसे पोस्टग्रेज से कनेक्ट करने के लिए सेटिंग्स को स्टोर करने की आवश्यकता है, साथ ही साथ अपने बारे में कुछ जानकारी भी

सबसे पहले आपको STAGE = चूक के लिए एक कॉन्फिगर परिभाषित करना होगा। इसमें हम सामान्य संरचना का वर्णन करेंगे, साथ ही साथ डेटा को चरण से स्वतंत्र करेंगे।

चूक

# configuration/defaults/service.yaml defaults: version: 1.0.0 name: "config-example" # configuration/defaults/redis.yaml defaults: redis: host: "host" db: 0 port: 6379 password: "password"

देव

 # configuration/dev/redis.yaml dev: redis: host: "localhost" password: "hard_pwd"

परिणामी विन्यास

 version: 1.0.0 name: "config-example" redis: host: "localhost" db: 0 port: 6379 password: "hard_pwd"

निष्कर्ष

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

उन लोगों के लिए जो "नंगे रूप" में इस कॉन्फ़िगरेशन विधि में रुचि रखते हैं:

विभिन्न प्रोग्रामिंग भाषाओं के लिए हमारे पैकेज

लेखन में मदद के लिए Roque , SMGladkovskiy के लिए एक विशेष धन्यवाद बनें

Mikroservisy। एकीकरण और यह इतना महत्वपूर्ण क्यों है। भाग 1 - विन्यास