🥇microconfig.io के साथ माइक्रोसर्विस कॉन्फ़िगरेशन को आसानी से प्रबंधित करें

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

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

आइए एक उदाहरण देखें. मान लीजिए कि हमारे पास कॉन्फ़िगरेशन फ़ाइल के साथ एक सरल एप्लिकेशन है यमलो. यह किसी भी भाषा में कोई भी माइक्रोसर्विस हो सकता है। आइए देखें कि इस सेवा पर रूपरेखा कैसे लागू की जा सकती है।

लेकिन पहले, अधिक सुविधा के लिए, आइए इसमें माइक्रोकॉन्फिग.आईओ प्लगइन स्थापित करने के बाद आइडिया आईडीई में एक खाली प्रोजेक्ट बनाएं:

हमने प्लगइन लॉन्च कॉन्फ़िगरेशन सेट किया है, आप डिफ़ॉल्ट कॉन्फ़िगरेशन का उपयोग कर सकते हैं, जैसा कि ऊपर स्क्रीनशॉट में है।

हमारी सेवा को ऑर्डर कहा जाता है, फिर एक नए प्रोजेक्ट में हम एक समान संरचना बनाएंगे:

कॉन्फ़िगरेशन फ़ाइल को सेवा नाम वाले फ़ोल्डर में रखें - application.yaml. सभी माइक्रोसर्विसेज किसी न किसी प्रकार के वातावरण में लॉन्च किए जाते हैं, इसलिए, सेवा के लिए एक कॉन्फ़िगरेशन बनाने के अलावा, पर्यावरण का वर्णन करना भी आवश्यक है: इसके लिए हम एक फ़ोल्डर बनाएंगे envs और इसमें हमारे कार्य परिवेश के नाम के साथ एक फ़ाइल जोड़ें। इस प्रकार, फ्रेमवर्क पर्यावरण में सेवाओं के लिए कॉन्फ़िगरेशन फ़ाइलें बनाएगा देव, चूंकि यह पैरामीटर प्लगइन सेटिंग्स में सेट है।

फ़ाइल संरचना dev.yaml यह काफी सरल होगा:

mainorder:
    components:
         - order

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

सेवा सेटिंग्स फ़ाइल में ही आदेश आइए अभी केवल एक पैरामीटर निर्दिष्ट करें:

spring.application.name: order

अब प्लगइन चलाते हैं, और यह गुणों में निर्दिष्ट पथ के अनुसार हमारी सेवा के लिए आवश्यक कॉन्फ़िगरेशन उत्पन्न करेगा:

कर सकते हैं द्वारा प्राप्त और कोई प्लगइन स्थापित किए बिना, बस फ्रेमवर्क वितरण को डाउनलोड करना और इसे कमांड लाइन से चलाना।
यह समाधान बिल्ड सर्वर पर उपयोग के लिए उपयुक्त है।

यह ध्यान देने योग्य है कि रूपरेखा पूरी तरह से समझ में आती है संपत्ति वाक्यविन्यास, यानी, सामान्य संपत्ति फ़ाइलें जिन्हें एक साथ उपयोग किया जा सकता है यमलो विन्यास.

आइए एक और सेवा जोड़ें भुगतान और मौजूदा को जटिल बनाओ।
В आदेश:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

В भुगतान:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9998
spring.application.name: payments
db.url: 192.168.0.100

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

और अब आइए अपने प्रत्येक प्रोजेक्ट में लाइन जोड़ें #यूरेका शामिल करें.

फ्रेमवर्क स्वचालित रूप से यूरेका कॉन्फ़िगरेशन ढूंढेगा और इसे सेवा कॉन्फ़िगरेशन फ़ाइलों में कॉपी करेगा, जबकि एक अलग यूरेका कॉन्फ़िगरेशन नहीं बनाया जाएगा, क्योंकि हम इसे पर्यावरण फ़ाइल में निर्दिष्ट नहीं करेंगे dev.yaml. सेवा आदेश:

#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

हम आयात लाइन को बदलकर डेटाबेस सेटिंग्स को एक अलग कॉन्फ़िगरेशन में भी ले जा सकते हैं #यूरेका, ओरेकल शामिल करें.

यह ध्यान देने योग्य है कि फ्रेमवर्क कॉन्फ़िगरेशन फ़ाइलों को पुन: उत्पन्न करते समय प्रत्येक परिवर्तन को ट्रैक करता है और इसे मुख्य कॉन्फ़िगरेशन फ़ाइल के बगल में एक विशेष फ़ाइल में रखता है। इसके लॉग में प्रविष्टि इस तरह दिखती है: “संग्रहीत 1 संपत्ति में परिवर्तन होता है order/diff-application.yaml" यह आपको बड़ी कॉन्फ़िगरेशन फ़ाइलों में परिवर्तनों का तुरंत पता लगाने की अनुमति देता है।

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

एक अच्छा समाधान यह होगा कि सभी समापन बिंदुओं को एक कॉन्फ़िगरेशन में रखा जाए जिसे अन्य लोग संदर्भित कर सकें। इस प्रयोजन के लिए, प्लेसहोल्डर्स के लिए समर्थन को ढांचे में पेश किया गया है। इस प्रकार कॉन्फ़िगरेशन फ़ाइल बदल जाएगी यूरेका:

 client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/

अब देखते हैं कि यह प्लेसहोल्डर कैसे काम करता है। सिस्टम नाम का एक घटक ढूंढता है अंतबिंदु और उसमें अर्थ ढूंढता है यूरेकेइप, और फिर इसे हमारे कॉन्फ़िगरेशन में प्रतिस्थापित करता है। लेकिन विभिन्न वातावरणों के बारे में क्या? ऐसा करने के लिए, एक सेटिंग फ़ाइल बनाएं अंतबिंदु निम्न प्रकार application.dev.yaml. फ़ाइल एक्सटेंशन के आधार पर फ़्रेमवर्क स्वतंत्र रूप से यह तय करता है कि यह कॉन्फ़िगरेशन किस वातावरण से संबंधित है और इसे लोड करता है:

देव फ़ाइल सामग्री:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

हम अपनी सेवाओं के पोर्ट के लिए समान कॉन्फ़िगरेशन बना सकते हैं:

server.port: ${ports@order}.

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

फ़्रेमवर्क कई तैयार प्लेसहोल्डर प्रदान करता है, उदाहरण के लिए, आप उस निर्देशिका का नाम प्राप्त कर सकते हैं जिसमें कॉन्फ़िगरेशन फ़ाइल स्थित है और इसे असाइन करें:

#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}

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

client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/
 spring.application.name: ${this@name}

कॉन्फ़िगरेशन फ़ाइल आदेश एक पंक्ति में सिमट जाएगा:

#include eureka, oracle
server.port: ${ports@order}

यदि हमें मूल कॉन्फ़िगरेशन से किसी सेटिंग की आवश्यकता नहीं है, तो हम इसे अपनी कॉन्फ़िगरेशन में निर्दिष्ट कर सकते हैं और इसे पीढ़ी के दौरान लागू किया जाएगा। यानी, अगर किसी कारण से हमें ऑर्डर सेवा के लिए एक अद्वितीय नाम की आवश्यकता है, तो हम केवल पैरामीटर छोड़ देंगे वसंत.अनुप्रयोग.नाम.

मान लीजिए कि आपको सेवा में कस्टम लॉगिंग सेटिंग्स जोड़ने की आवश्यकता है, जो एक अलग फ़ाइल में संग्रहीत हैं, उदाहरण के लिए, लॉगबैक.एक्सएमएल. आइए इसके लिए सेटिंग्स का एक अलग समूह बनाएं:

बुनियादी कॉन्फ़िगरेशन में, हम प्लेसहोल्डर का उपयोग करके फ्रेमवर्क को बताएंगे कि हमें आवश्यक लॉगिंग सेटिंग्स फ़ाइल को कहां रखना है @ConfigDir:

microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml

फाइल मैं लॉगबैक.एक्सएमएल हम मानक परिशिष्टों को कॉन्फ़िगर करते हैं, जिसमें बदले में प्लेसहोल्डर भी शामिल हो सकते हैं कि कॉन्फ़िगरेशन की पीढ़ी के दौरान रूपरेखा बदल जाएगी, उदाहरण के लिए:

<file>logs/${this@name}.log</file>

सेवा कॉन्फ़िगरेशन में आयात जोड़कर लॉगबैक, हम स्वचालित रूप से प्रत्येक सेवा के लिए कॉन्फ़िगर लॉगिंग प्राप्त करते हैं:

#include eureka, oracle, logback
server.port: ${ports@order}

अब फ्रेमवर्क के सभी उपलब्ध प्लेसहोल्डर्स से अधिक विस्तार से परिचित होने का समय आ गया है:

${this@env} - वर्तमान परिवेश का नाम लौटाता है।
${…@नाम} - घटक का नाम लौटाता है।
${...@configDir} - घटक की कॉन्फ़िगरेशन निर्देशिका का पूरा पथ लौटाता है।
${…@resultDir} - घटक की गंतव्य निर्देशिका का पूरा पथ लौटाता है (परिणामस्वरूप फ़ाइलें इस निर्देशिका में रखी जाएंगी)।
${this@configRoot} - कॉन्फ़िगरेशन स्टोर की रूट डायरेक्टरी का पूरा पथ लौटाता है।

सिस्टम आपको पर्यावरण चर प्राप्त करने की भी अनुमति देता है, उदाहरण के लिए जावा का पथ:
${env@JAVA_HOME}
या तो, चूंकि रूपरेखा में लिखा गया है जावा, हम कॉल के समान सिस्टम वेरिएबल प्राप्त कर सकते हैं सिस्टम:: संपत्ति प्राप्त करें इस तरह की संरचना का उपयोग करना:
${[ईमेल संरक्षित]}
यह विस्तार भाषा के लिए समर्थन का उल्लेख करने योग्य है स्प्रिंग ईएल. निम्नलिखित अभिव्यक्तियाँ कॉन्फ़िगरेशन में लागू होती हैं:

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10}

और आप अभिव्यक्ति का उपयोग करके कॉन्फ़िगरेशन फ़ाइलों में स्थानीय चर का उपयोग कर सकते हैं #वर:

#var feedRoot: ${[email protected]}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

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

यदि आप इस ढांचे में रुचि रखते हैं, तो मेरा सुझाव है कि आप इसके आधिकारिक पृष्ठ पर जाएं और पूरी जानकारी से परिचित हो जाएं प्रलेखन, या स्रोतों में खोदो यहां.

स्रोत: www.habr.com

Microconfig.io के साथ माइक्रोसर्विस कॉन्फ़िगरेशन को आसानी से प्रबंधित करें

एक टिप्पणी जोड़ें उत्तर रद्द