बड़ी संख्या में संरचित कॉन्फ़िगरेशन / संपत्ति फ़ाइलों को संभालने के लिए सर्वोत्तम अभ्यास


15

एक ऐसी प्रणाली की कल्पना करें जिसमें बड़ी संख्या में सर्वर हों। उनमें से प्रत्येक में कई सेटिंग्स हैं:

  • सर्वर के लिए कुछ विशिष्ट
  • क्षेत्र के लिए कुछ विशिष्ट
  • उन सभी में कुछ सामान्य
  • हो सकता है कि आपके पास कुछ कस्टम समूह हों, जैसे कि सर्वरों का यह समूह केवल पढ़ने के लिए है
  • आदि।

वर्तमान अभ्यास जो मेरे मन में है वह ओवरराइडिंग क्षमताओं के साथ एक सरल संपत्ति संरचना है।

उदाहरण के उद्देश्य से Google सर्वर को लेने दें। उनमें से प्रत्येक को लोड करने के लिए सेटिंग्स की एक सूची है।

उदाहरण के लिए, लंदन सर्वर हो सकता है:

rootsettings.properties, europesettings.properties, londonsettings.properties, searchengine.properties, आदि

जहां प्रत्येक फ़ाइल में गुणों का एक सेट होता है और लोडिंग अनुक्रम आपको गुणों को ओवरराइड करने की अनुमति देता है, आगे आप जाते हैं।

उदाहरण के लिए: एक डिफ़ॉल्ट के रूप में rootsettings.propertiesहो सकता है accessible=false, लेकिन searchengine.propertiesसाथ में अतिरंजित हैaccessible=true


इस संरचना से मुझे जो समस्या हो रही है, उसे नियंत्रण से बाहर करना बहुत आसान है। यह बिल्कुल संरचित नहीं है, जिसका अर्थ है कि आप किसी भी स्तर पर किसी भी संपत्ति को परिभाषित कर सकते हैं और कई आइटम अप्रचलित हो सकते हैं।

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

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

यदि आपके पास एक बेहतर विन्यास प्रबंधन वास्तुकला के कोई सुझाव / विचार हैं, तो मैं बहुत सराहना करूंगा।


1
पहली बात: स्टार्टअप पर भरी हुई सभी संपत्तियों को लॉग इन करें, कम से कम आपको पता है कि इस्तेमाल किया जा रहा है।
वल्फ्रैट

@Stoyan, क्या आप "सॉफ़्टवेयर कॉन्फ़िगरेशन" या "सर्वर कॉन्फ़िगरेशन" दृष्टिकोणों की तलाश कर रहे हैं?
युसुबोव

निराला विचार, हालांकि बहुत अच्छी तरह से नहीं: किसी ने भी इस तरह से किसी भी चीज़ के लिए "सीएसएस-जैसी" प्रणाली का उपयोग किया है? फ़ाइल नाम संरचित होने के बजाय (या इसके अलावा), उनके भीतर डेटा है।
user949300

मैं एक सीएसएस-जैसे नियम आधारित केंद्रीकृत विन्यास प्रबंधन प्रणाली का निर्माण करता हूं। यह स्रोत का उपयोग करने और खोलने के लिए स्वतंत्र है। अधिक जानकारी के लिए नीचे मेरा उत्तर देखें।
bikeman868

मेरे लिए एक उचित दृष्टिकोण की तरह लगता है।
dagnelies

जवाबों:


5

मुझे लगता है कि आपको अपने आप को पहले कुछ सवाल पूछने की ज़रूरत है, और कुछ बिंदुओं को स्पष्ट करना है, फिर आप बेहतर तरीके से तय कर सकते हैं कि अपनी समस्या को कैसे हल किया जाए।

पहला: सर्वरों पर किसका नियंत्रण होगा?

  • क्या यह एक एकल प्रशासक है जो सैकड़ों सर्वरों को नियंत्रित करने वाला है? फिर आपको यथासंभव कॉन्फ़िगरेशन को केंद्रीकृत करने की आवश्यकता है।

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

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

  • अपने सॉफ़्टवेयर को थोड़ा अधिक स्मार्ट बनाना (उदाहरण के लिए, प्रोग्राम पर्यावरण से पूछकर अपने आप क्या निर्धारित कर सकता है)?

  • निम्नलिखित रूप से "कॉन्फ़िगरेशन पर सम्मेलन" कठोरता से - उदाहरण के लिए, कुछ नामकरण परंपराओं की स्थापना करके, या कुछ विकल्पों को अन्य विकल्पों से डिफ़ॉल्ट के रूप में प्राप्त करके।

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

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


भले ही यह सीधे समाधान प्रदान नहीं करता है, लेकिन यह सबसे अधिक समझ में आता है कि पहले से खराब हो चुकी स्थिति को कैसे संभालना है। विशेष रूप से अपने सॉफ़्टवेयर को थोड़ा अधिक स्मार्ट बनाना
एसडीकेव

2

मुझे व्यक्तिगत रूप से विन्यास फाइल विरासत पसंद नहीं है। आप एक लोडिंग अनुक्रम होने का उल्लेख करते हैं, यह निश्चित नहीं है कि यह कैसे परिभाषित या व्युत्पन्न है। हो सकता है कि यह एक डायरेक्टरी स्ट्रक्चर में मिरर करके आप सीक्वेंस को स्पष्ट करने में मदद करता हो।

rootsettings.properties
rootsettings.eurosettings.properties
rootsettings.eurosettings.londonsettings.properties

यह कुछ हद तक काम करेगा जहां आपके पास कॉन्फ़िगरेशन मानों का एक समूह है जो एक क्षेत्र में संरेखित नहीं करता है। इसलिए आपको अपने द्वारा चुने गए संगठनात्मक अक्ष पर विचार करने की आवश्यकता है।

मुझे जो अधिक पसंद है वह कॉन्फ़िगरेशन मानों को अपनी फ़ाइलों में अलग कर रहा है और एक (पत्ती) कॉन्फ़िगरेशन फ़ाइल बिंदु को एक में रखता है।

एक उदाहरण:

bigcity.searchsettings.properties
regional.searchsettings.properties

आपके अंदर londonsettings.propertiesएक मूल्य हो सकता है जैसे:

searchsettings:bigcity.searchsettings.properties

यह स्वतंत्रता की अधिक डिग्री या एक अतिरिक्त के लिए अनुमति देता है।


2

मेरे पास एक ही समस्या थी और मेरे समाधान को खोल दिया। आप स्रोत कोड यहाँ पा सकते हैं https://github.com/Bikeman868/Urchin

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

अगर आपको जमीन से उतरने में मदद चाहिए तो आप मुझसे सीधे संपर्क कर सकते हैं।

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

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

सर्वर में एक REST + JSON इंटरफ़ेस है, इसलिए अधिकांश विकास प्रणालियों के साथ काम करता है, और इसके पास .Net अनुप्रयोगों के लिए एक सुविधाजनक क्लाइंट लाइब्रेरी भी है।


1

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

एक क्षेत्र के लिए एक एपीआई सर्वर स्थापित करने के बजाय, आपी कॉल के साथ क्षेत्र को पास करें और सभी क्षेत्रों के लिए एक एकल सर्वर सेटअप को संभालने दें।

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

इसके बजाय, प्रति सर्वर प्रकार में आपके परिनियोजन उपकरण में संग्रहीत सेटिंग्स हैं। (ऑक्टोपस परिनियोजन सेटिंग्स, टीमसिटी फाइल रीराइट्स, आदि) यह आपको यह सुनिश्चित करने की अनुमति देता है कि आप वही कॉन्फिगरेशन सेटिंग्स तैनात कर रहे हैं जो आपने पिछली बार सॉफ्टवेयर अपग्रेड करते समय की थी और आपको बदलावों पर ठीक-ठाक नियंत्रण देता है।

आप उस स्थिति में नहीं रहना चाहते हैं जहाँ आप अपनी मेटा-कॉन्फिग फाइलों में बदलाव करते हैं और फिर यह परीक्षण करना होता है कि आपके विभिन्न क्षेत्रों / सर्वरों / कस्टम ग्रुपिंग में कौन सी कॉन्फिग फाइल तैयार होती है।


0

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

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

यह मेरा सुझाव है।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.