एक वितरित प्रणाली का संकलन योग्य विन्यास

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

( रूसी में )

परिचय

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

सिस्टम के परीक्षण के बारे में क्या? बेशक, हमारे पास एकीकरण परीक्षणों में आने से पहले सभी घटकों के लिए इकाई परीक्षण होना चाहिए। रनटाइम पर परीक्षा परिणामों को एक्सट्रपलेट करने में सक्षम होने के लिए, हमें यह सुनिश्चित करना चाहिए कि सभी पुस्तकालयों के संस्करणों को रनटाइम और परीक्षण वातावरण दोनों में समान रखा जाए।

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

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

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

इस पोस्ट में हम संकलित विरूपण साक्ष्य में विन्यास रखने के विचार की जांच करेंगे।

संकलित विन्यास

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

एक विशिष्ट वितरित प्रणाली में कुछ नोड्स होते हैं। नोड्स को कुछ प्रकार का उपयोग करके पहचाना जा सकता है:

sealed trait NodeId case object Backend extends NodeId case object Frontend extends NodeId 

या बस

 case class NodeId(hostName: String) 

या भी

 object Singleton type NodeId = Singleton.type 

ये नोड्स विभिन्न भूमिकाएँ निभाते हैं, कुछ सेवाएँ चलाते हैं और टीसीपी / एचटीटीपी कनेक्शन द्वारा अन्य नोड्स के साथ संवाद करने में सक्षम होना चाहिए।

टीसीपी कनेक्शन के लिए कम से कम एक पोर्ट नंबर की आवश्यकता होती है। हम यह भी सुनिश्चित करना चाहते हैं कि क्लाइंट और सर्वर एक ही प्रोटोकॉल पर बात कर रहे हैं। नोड्स के बीच संबंध बनाने के लिए आइए निम्न वर्ग की घोषणा करें:

 case class TcpEndPoint[Protocol](node: NodeId, port: Port[Protocol]) 

Port जहां अनुमत सीमा के भीतर एक Int है:

 type PortNumber = Refined[Int, Closed[_0, W.`65535`.T]] 

HTTP (REST) ​​के लिए हमें सेवा के पथ की भी आवश्यकता हो सकती है:

 type UrlPathPrefix = Refined[String, MatchesRegex[W.`"[a-zA-Z_0-9/]*"`.T]] case class PortWithPrefix[Protocol](portNumber: PortNumber, pathPrefix: UrlPathPrefix) 

सबसे व्यापक रूप से इस्तेमाल किए जाने वाले प्रोटोकॉल में से एक है JSON सीरीज़ेशन के साथ REST API:

 sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage] 

जहाँ RequestMessage एक प्रकार का संदेश है जो क्लाइंट सर्वर को भेज सकता है और ResponseMessage सर्वर से प्रतिक्रिया संदेश है। बेशक, हम अन्य प्रोटोकॉल विवरण बना सकते हैं जो वांछित सटीकता के साथ संचार प्रोटोकॉल को निर्दिष्ट करते हैं।

इस पोस्ट के प्रयोजनों के लिए हम प्रोटोकॉल के एक सरल संस्करण का उपयोग करेंगे:

 sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage] 

इस प्रोटोकॉल अनुरोध में संदेश को url से जोड़ा जाता है और प्रतिक्रिया संदेश को सादे स्ट्रिंग के रूप में लौटाया जाता है।

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

अन्य नोड्स के समापन बिंदु के रूप में केक पैटर्न का उपयोग करके निर्भरता का प्रतिनिधित्व किया जा सकता है:

  type EchoProtocol[A] = SimpleHttpGetRest[A, A] trait EchoConfig[A] extends ServiceConfig { def portNumber: PortNumber = 8081 def echoPort: PortWithPrefix[EchoProtocol[A]] = PortWithPrefix[EchoProtocol[A]](portNumber, "echo") def echoService: HttpSimpleGetEndPoint[NodeId, EchoProtocol[A]] = providedSimpleService(echoPort) } 

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

हम गूंज सेवा क्लाइंट के विन्यास में एक निर्भरता की घोषणा कर सकते हैं:

  trait EchoClientConfig[A] { def testMessage: String = "test" def pollInterval: FiniteDuration def echoServiceDependency: HttpSimpleGetEndPoint[_, EchoProtocol[A]] } 

निर्भरता की echoService तरह ही echoService । विशेष रूप से, यह उसी प्रोटोकॉल की मांग करता है। इसलिए, हम यह सुनिश्चित कर सकते हैं कि यदि हम इन दो निर्भरताओं को जोड़ते हैं तो वे सही तरीके से काम करेंगे।

  type ResourceReader[F[_], Config, A] = Reader[Config, Resource[F, A]] trait ServiceImpl[F[_]] { type Config def resource( implicit resolver: AddressResolver[F], timer: Timer[F], contextShift: ContextShift[F], ec: ExecutionContext, applicative: Applicative[F] ): ResourceReader[F, Config, Unit] } 

  trait ZeroServiceImpl[F[_]] extends ServiceImpl[F] { type Config <: Any def resource(...): ResourceReader[F, Config, Unit] = Reader(_ => Resource.pure[F, Unit](())) } 

(अन्य सेवाओं के कार्यान्वयन के लिए स्रोत कोड देखें - इको सेवा ,
इको क्लाइंट और आजीवन नियंत्रक ।)

नोड एक एकल ऑब्जेक्ट है जो कुछ सेवाओं को चलाता है (केक पैटर्न द्वारा संसाधनों की एक श्रृंखला शुरू करना सक्षम है):

 object SingleNodeImpl extends ZeroServiceImpl[IO] with EchoServiceService with EchoClientService with FiniteDurationLifecycleServiceImpl { type Config = EchoConfig[String] with EchoClientConfig[String] with FiniteDurationLifecycleConfig } 

ध्यान दें कि नोड में हम सटीक प्रकार का कॉन्फ़िगरेशन निर्दिष्ट करते हैं जो इस नोड द्वारा आवश्यक है। कंपाइलर हमें ऑब्जेक्ट (केक) को अपर्याप्त प्रकार से बनाने की अनुमति नहीं देगा, क्योंकि प्रत्येक सेवा गुण Config प्रकार पर एक बाधा की घोषणा करता है। इसके अलावा हम पूर्ण कॉन्फ़िगरेशन प्रदान किए बिना नोड शुरू करने में सक्षम नहीं होंगे।

 case class NodeAddress[NodeId](host: Uri.Host) trait AddressResolver[F[_]] { def resolve[NodeId](nodeId: NodeId): F[NodeAddress[NodeId]] } 

इस पोस्ट में हम दो वितरित सिस्टम लेआउट पर विचार करेंगे:

1. एकल नोड लेआउट, जहां सभी सेवाओं को एकल नोड पर रखा गया है।
2. दो नोड लेआउट, जहां सेवा और ग्राहक विभिन्न नोड्स पर हैं।

एकल नोड लेआउट के लिए विन्यास इस प्रकार है:

 object SingleNodeConfig extends EchoConfig[String] with EchoClientConfig[String] with FiniteDurationLifecycleConfig { case object Singleton // identifier of the single node // configuration of server type NodeId = Singleton.type def nodeId = Singleton /** Type safe service port specification. */ override def portNumber: PortNumber = 8088 // configuration of client /** We'll use the service provided by the same host. */ def echoServiceDependency = echoService override def testMessage: UrlPathElement = "hello" def pollInterval: FiniteDuration = 1.second // lifecycle controller configuration def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 requests, not 9. } 

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

सेवा कार्यान्वयन और कॉन्फ़िगरेशन के एक ही सेट का उपयोग सिस्टम के लेआउट को दो अलग नोड्स के साथ बनाने के लिए किया जा सकता है। हमें उचित सेवाओं के साथ दो अलग नोड कॉन्फिगरेशन बनाने की आवश्यकता है:

  object NodeServerConfig extends EchoConfig[String] with SigTermLifecycleConfig { type NodeId = NodeIdImpl def nodeId = NodeServer override def portNumber: PortNumber = 8080 } object NodeClientConfig extends EchoClientConfig[String] with FiniteDurationLifecycleConfig { // NB! dependency specification def echoServiceDependency = NodeServerConfig.echoService def pollInterval: FiniteDuration = 1.second def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 request, not 9. def testMessage: String = "dolly" } 

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

  object TwoJvmNodeServerImpl extends ZeroServiceImpl[IO] with EchoServiceService with SigIntLifecycleServiceImpl { type Config = EchoConfig[String] with SigTermLifecycleConfig } object TwoJvmNodeClientImpl extends ZeroServiceImpl[IO] with EchoClientService with FiniteDurationLifecycleServiceImpl { type Config = EchoClientConfig[String] with FiniteDurationLifecycleConfig } 

समग्र विकास की प्रक्रिया

आइए देखें कि यह तरीका कैसे कॉन्फ़िगरेशन के साथ काम करता है।

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

एक कॉन्फ़िगरेशन परिवर्तन कोड परिवर्तन हो जाता है। तो इसे उसी गुणवत्ता आश्वासन प्रक्रिया द्वारा कवर किया जाना चाहिए:

टिकट -> पीआर -> समीक्षा -> मर्ज -> निरंतर एकीकरण -> निरंतर तैनाती

दृष्टिकोण के निम्नलिखित परिणाम हैं:

1. कॉन्फ़िगरेशन किसी विशेष सिस्टम के उदाहरण के लिए सुसंगत है। ऐसा लगता है कि नोड्स के बीच गलत कनेक्शन होने का कोई तरीका नहीं है।

   
   

2. कॉन्फ़िगरेशन को केवल एक नोड में बदलना आसान नहीं है। कुछ पाठ फ़ाइलों को लॉग इन करना और बदलना अनुचित है। तो कॉन्फ़िगरेशन बहाव कम संभव हो जाता है।

   
   

3. छोटे विन्यास परिवर्तन करना आसान नहीं है।

   
   

4. अधिकांश कॉन्फ़िगरेशन परिवर्तन समान विकास प्रक्रिया का पालन करेंगे, और यह कुछ समीक्षा पास करेगा।

   
   

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

बदलाव

आइए अन्य विन्यास प्रबंधन तकनीकों की तुलना में प्रस्तावित दृष्टिकोण के पेशेवरों और विपक्षों को देखें।

सबसे पहले, हम विन्यास से निपटने के प्रस्तावित तरीके के विभिन्न पहलुओं के लिए कुछ विकल्पों की सूची देंगे:

1. लक्ष्य मशीन पर पाठ फ़ाइल।
2. केंद्रीकृत की-वैल्यू स्टोरेज (जैसे etcd / zookeeper )।
3. उपप्रक्रम घटक जिन्हें पुन: आरंभ किया जा सकता है / पुनः आरंभ करने की प्रक्रिया के बिना।
4. विरूपण साक्ष्य और संस्करण नियंत्रण के बाहर विन्यास।

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

(Btw, अगर अंततः टेक्स्ट कॉन्फिग फाइलों का उपयोग शुरू करने की आवश्यकता होगी, तो हमें केवल पार्सर + सत्यापनकर्ता को जोड़ना होगा जो समान Config प्रकार का उत्पादन कर सकता है और जो टेक्स्ट कॉन्फिगर का उपयोग शुरू करने के लिए पर्याप्त होगा। यह भी दिखाता है कि संकलन-समय कॉन्फ़िगरेशन की जटिलता थोड़ी छोटी है कि पाठ-आधारित कॉन्फ़िगरेशन की जटिलता, क्योंकि पाठ-आधारित संस्करण में हमें कुछ अतिरिक्त कोड की आवश्यकता होती है।)

केंद्रीकृत की-वैल्यू स्टोरेज, एप्लिकेशन मेटा मापदंडों को वितरित करने के लिए एक अच्छा तंत्र है। यहां हमें यह सोचने की ज़रूरत है कि हम कॉन्फ़िगरेशन मानों को क्या मानते हैं और केवल डेटा क्या है। किसी फ़ंक्शन C => A => B को देखते हुए हम आम तौर पर शायद ही कभी बदलते मूल्यों C "कॉन्फ़िगरेशन" को कहते हैं, जबकि अक्सर बदले गए डेटा A - बस इनपुट डेटा। डेटा A से पहले फ़ंक्शन को कॉन्फ़िगरेशन प्रदान किया जाना चाहिए A इस विचार को देखते हुए हम कह सकते हैं कि यह परिवर्तन की अपेक्षित आवृत्ति है, जिसका उपयोग केवल डेटा से कॉन्फ़िगरेशन डेटा को अलग करने के लिए किया जा सकता है। इसके अलावा डेटा आम तौर पर एक स्रोत (उपयोगकर्ता) से आता है और कॉन्फ़िगरेशन एक अलग स्रोत (व्यवस्थापक) से आता है। प्रक्रिया आरंभीकरण के बाद बदले जा सकने वाले मापदंडों से निपटना आवेदन की जटिलता को बढ़ाता है। ऐसे मापदंडों के लिए हमें उनके वितरण तंत्र, पार्सिंग और सत्यापन को संभालना होगा, गलत मानों को संभालना होगा। इसलिए, कार्यक्रम की जटिलता को कम करने के लिए, हम उन मापदंडों की संख्या को बेहतर ढंग से कम कर सकते हैं जो रनटाइम में बदल सकते हैं (या उन्हें पूरी तरह से समाप्त भी कर सकते हैं)।

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

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

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

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

पेशेवरों और विपक्ष

यहां हम कुछ लाभों पर प्रकाश डालना चाहते हैं और प्रस्तावित दृष्टिकोण के कुछ नुकसानों पर चर्चा करना चाहते हैं।

लाभ

एक पूर्ण वितरित प्रणाली के संकलन योग्य विन्यास की विशेषताएं:

1. विन्यास की स्थैतिक जाँच। यह एक उच्च स्तर का विश्वास दिलाता है, कि विन्यास सही प्रकार की अड़चनें देता है।
2. विन्यास की समृद्ध भाषा। आमतौर पर अन्य कॉन्फ़िगरेशन दृष्टिकोण अधिकांश चर प्रतिस्थापन पर सीमित होते हैं।
   स्काला का उपयोग करके विन्यास को बेहतर बनाने के लिए भाषा सुविधाओं की एक विस्तृत श्रृंखला का उपयोग किया जा सकता है। उदाहरण के लिए, हम डिफ़ॉल्ट मान प्रदान करने के लिए लक्षणों का उपयोग कर सकते हैं, वस्तुओं को अलग-अलग गुंजाइश बनाने के लिए, हम केवल बाहरी दायरे (DRY) में केवल एक बार परिभाषित s को संदर्भित कर सकते हैं। शाब्दिक अनुक्रमों या कुछ वर्गों (उदाहरण, Map , आदि) के उदाहरणों का उपयोग करना संभव है।
3. डीएसएल। Scala को DSL लेखकों के लिए अच्छा समर्थन प्राप्त है। एक कॉन्फ़िगरेशन भाषा को स्थापित करने के लिए इन सुविधाओं का उपयोग किया जा सकता है जो अधिक सुविधाजनक और अंतिम-उपयोगकर्ता के अनुकूल है, ताकि अंतिम कॉन्फ़िगरेशन डोमेन उपयोगकर्ताओं के लिए कम से कम पठनीय हो।
4. नोड्स के पार अखंडता और सुसंगतता। एक स्थान पर पूरे वितरित सिस्टम के लिए कॉन्फ़िगरेशन होने का एक लाभ यह है कि सभी मूल्यों को एक बार सख्ती से परिभाषित किया जाता है और फिर उन सभी स्थानों पर पुन: उपयोग किया जाता है जहां हमें उनकी आवश्यकता होती है। साथ ही सुरक्षित पोर्ट घोषणाएं यह सुनिश्चित करती हैं कि सभी संभावित सही कॉन्फ़िगरेशन में सिस्टम के नोड्स एक ही भाषा बोलेंगे। नोड्स के बीच स्पष्ट निर्भरताएं हैं जो कुछ सेवाओं को प्रदान करने के लिए भूलना मुश्किल बनाता है।
5. परिवर्तनों की उच्च गुणवत्ता। सामान्य पीआर प्रक्रिया के माध्यम से पासिंग परिवर्तन का समग्र दृष्टिकोण, कॉन्फ़िगरेशन में भी गुणवत्ता के उच्च मानकों को स्थापित करता है।
6. एक साथ कॉन्फ़िगरेशन बदलता है। जब भी हम कॉन्फ़िगरेशन में कोई बदलाव करते हैं तो स्वचालित परिनियोजन यह सुनिश्चित करता है कि सभी नोड्स अपडेट किए जा रहे हैं।
7. आवेदन सरलीकरण। एप्लिकेशन को कॉन्फ़िगरेशन को पार्स और मान्य करने और गलत कॉन्फ़िगरेशन मानों को संभालने की आवश्यकता नहीं है। यह समग्र अनुप्रयोग को सरल करता है। (कुछ जटिलता वृद्धि कॉन्फ़िगरेशन में ही है, लेकिन यह सुरक्षा के प्रति एक सचेत व्यापार-बंद है।) साधारण कॉन्फ़िगरेशन में वापस आना बहुत सरल है - बस लापता टुकड़े जोड़ें। बाद में संकलित विन्यास और अतिरिक्त टुकड़ों के कार्यान्वयन को स्थगित करना आसान है।
8. वर्जन कॉन्फ़िगरेशन। इस तथ्य के कारण कि कॉन्फ़िगरेशन परिवर्तन समान विकास प्रक्रिया का पालन करते हैं, जिसके परिणामस्वरूप हमें अद्वितीय संस्करण के साथ एक कलाकृति मिलती है। यदि आवश्यक हो तो यह हमें कॉन्फ़िगरेशन को वापस स्विच करने की अनुमति देता है। हम एक कॉन्फ़िगरेशन भी तैनात कर सकते हैं जो एक साल पहले इस्तेमाल किया गया था और यह ठीक उसी तरह काम करेगा। स्थिर विन्यास वितरित प्रणाली की भविष्यवाणी और विश्वसनीयता में सुधार करता है। कॉन्फ़िगरेशन को संकलन समय पर तय किया गया है और इसे आसानी से एक उत्पादन प्रणाली पर छेड़छाड़ नहीं किया जा सकता है।
9. प्रतिरूपकता। प्रस्तावित ढांचा मॉड्यूलर है और मॉड्यूल को विभिन्न तरीकों से जोड़ा जा सकता है
   विभिन्न कॉन्फ़िगरेशन (सेटअप / लेआउट) का समर्थन करें। विशेष रूप से, छोटे पैमाने पर एकल नोड लेआउट और बड़े पैमाने पर बहु ​​नोड सेटिंग होना संभव है। यह कई उत्पादन लेआउट के लिए उचित है।
10. परीक्षण। परीक्षण के उद्देश्यों के लिए, कोई मॉक सेवा को लागू कर सकता है और इसे एक प्रकार से सुरक्षित तरीके से निर्भरता के रूप में उपयोग कर सकता है। मोक्स द्वारा प्रतिस्थापित विभिन्न भागों के साथ कुछ अलग परीक्षण लेआउट को एक साथ बनाए रखा जा सकता है।
11. एकीकरण परीक्षण। कभी-कभी वितरित प्रणालियों में एकीकरण परीक्षण चलाना मुश्किल होता है। पूर्ण वितरित सिस्टम के सुरक्षित कॉन्फ़िगरेशन को टाइप करने के लिए वर्णित दृष्टिकोण का उपयोग करके, हम सभी वितरित भागों को एक सर्वर पर चलाया जा सकता है। स्थिति का अनुकरण करना आसान है
    जब सेवाओं में से एक अनुपलब्ध हो जाती है।

नुकसान

संकलित कॉन्फ़िगरेशन दृष्टिकोण "सामान्य" कॉन्फ़िगरेशन से अलग है और यह सभी आवश्यकताओं के अनुरूप नहीं हो सकता है। यहाँ संकलित विन्यास के कुछ नुकसान हैं:

1. स्थैतिक विन्यास। यह सभी अनुप्रयोगों के लिए उपयुक्त नहीं हो सकता है। कुछ मामलों में सभी सुरक्षा उपायों को दरकिनार करके उत्पादन में कॉन्फ़िगरेशन को जल्दी से ठीक करने की आवश्यकता है। यह दृष्टिकोण इसे और कठिन बनाता है। कॉन्फ़िगरेशन में कोई भी बदलाव करने के बाद संकलन और पुन: तैनाती की आवश्यकता होती है। यह सुविधा और बोझ दोनों है।
2. कॉन्फ़िगरेशन पीढ़ी। जब कुछ ऑटोमेशन टूल द्वारा कॉन्फिगरेशन जनरेट किया जाता है, तो इस एप्रोच को बाद के संकलन की आवश्यकता होती है (जो कि विफल हो सकता है)। निर्माण प्रणाली में इस अतिरिक्त कदम को एकीकृत करने के लिए अतिरिक्त प्रयास की आवश्यकता हो सकती है।
3. उपकरण। आज उपयोग में बहुत सारे उपकरण हैं जो पाठ-आधारित कॉन्फ़िगरेशन पर निर्भर हैं। उनमें से कुछ
   कॉन्फ़िगरेशन संकलित होने पर लागू नहीं होगा।
4. मानसिकता में बदलाव की जरूरत है। डेवलपर्स और DevOps टेक्स्ट कॉन्फ़िगरेशन फ़ाइलों से परिचित हैं। कॉन्फ़िगरेशन को संकलित करने का विचार उन्हें अजीब लग सकता है।
5. संकलित विन्यास शुरू करने से पहले एक उच्च गुणवत्ता सॉफ्टवेयर विकास प्रक्रिया की आवश्यकता होती है।

कार्यान्वित उदाहरण की कुछ सीमाएँ हैं:

1. यदि हम अतिरिक्त कॉन्फ़िगरेशन प्रदान करते हैं जो नोड कार्यान्वयन द्वारा मांग नहीं की जाती है, तो संकलक अनुपस्थित कार्यान्वयन का पता लगाने में हमारी मदद नहीं करेगा। यह लक्षण और केक पैटर्न के बजाय नोड कॉन्फ़िगरेशन के लिए HList या HList (केस क्लासेस) का उपयोग करके संबोधित किया जा सकता है।
2. हमें कॉन्फ़िगर फ़ाइल में कुछ बॉयलरप्लेट प्रदान करना होगा: ( package , import , object घोषणाएं;
   डिफ़ॉल्ट मानों वाले पैरामीटर के लिए override def )। यह एक DSL का उपयोग करके आंशिक रूप से संबोधित किया जा सकता है।
3. इस पोस्ट में हम समान नोड्स के समूहों के गतिशील पुन: संयोजन को कवर नहीं करते हैं।

निष्कर्ष

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

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

इस दृष्टिकोण को विभिन्न तरीकों से बढ़ाया जा सकता है:

1. किसी भी व्यावसायिक-तर्क की विफलता के मामले में संकलन समय पर संकलन सत्यापन और विफल होने के लिए मैक्रोज़ का उपयोग किया जा सकता है।
2. डोमेन-उपयोगकर्ता के अनुकूल तरीके से कॉन्फ़िगरेशन का प्रतिनिधित्व करने के लिए एक डीएसएल को लागू किया जा सकता है।
3. स्वचालित कॉन्फ़िगरेशन समायोजन के साथ गतिशील संसाधन प्रबंधन। उदाहरण के लिए, जब हम क्लस्टर नोड्स की संख्या को समायोजित करते हैं, तो हम (1) नोड्स को थोड़ा संशोधित कॉन्फ़िगरेशन प्राप्त करना चाहते हैं; (2) क्लस्टर प्रबंधक नई नोड्स जानकारी प्राप्त करने के लिए।

धन्यवाद

मैं इस पोस्ट के मसौदे पर प्रेरणादायक प्रतिक्रिया देने के लिए एंड्री सकसनोव, पावेल पोपोव, एंटोन नेहाव को धन्यवाद कहना चाहूंगा जिन्होंने मुझे इसे स्पष्ट करने में मदद की।