संकलित वितरित सिस्टम कॉन्फ़िगरेशन

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

( अंग्रेजी )

परिचय

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

वितरित प्रणाली परीक्षण के बारे में क्या? बेशक, हम यह मानते हैं कि एकीकरण परीक्षण पर आगे बढ़ने से पहले सभी घटकों के लिए यूनिट परीक्षण प्रदान किए जाते हैं। (हमारे लिए रनटाइम के लिए परीक्षण के परिणामों को एक्सट्रपलेशन करने के लिए, हमें परीक्षण चरण में और रनटाइम में लाइब्रेरी का एक समान सेट भी प्रदान करना होगा।)

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

कॉन्फ़िगरेशन एप्लिकेशन के साथ विकसित होता है। कार्यक्रमों के विकास के विभिन्न चरणों की पहचान करने के लिए, हम संस्करणों का उपयोग करते हैं। कॉन्फ़िगरेशन के विभिन्न संस्करणों की पहचान करना भी तर्कसंगत लगता है। और कॉन्फ़िगरेशन को केवल संस्करण नियंत्रण प्रणाली में रखा जाना चाहिए। यदि उत्पादन में केवल एक कॉन्फ़िगरेशन है, तो हम बस संस्करण संख्या का उपयोग कर सकते हैं। यदि कई उत्पादन उदाहरणों का उपयोग किया जाता है, तो हमें कई की आवश्यकता है
कॉन्फ़िगरेशन शाखाएं और संस्करण के अतिरिक्त एक अतिरिक्त लेबल (उदाहरण के लिए, शाखा का नाम)। इस प्रकार, हम विशिष्ट रूप से सटीक कॉन्फ़िगरेशन की पहचान कर सकते हैं। प्रत्येक कॉन्फ़िगरेशन पहचानकर्ता विशिष्ट रूप से वितरित नोड्स, पोर्ट्स, बाहरी संसाधनों, लाइब्रेरी संस्करणों के एक निश्चित संयोजन से मेल खाता है। इस पोस्ट के ढांचे में, हम इस तथ्य से आगे बढ़ेंगे कि केवल एक शाखा है, और हम एक डॉट (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 में जोड़ा गया है, और प्रतिक्रिया HTTP प्रतिक्रिया के शरीर में दिया गया स्ट्रिंग है।

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

सेवाओं के बीच निर्भरता को उन तरीकों के रूप में दर्शाया जा सकता है जो EndPoint अन्य नोड्स EndPoint पोर्ट लौटाते हैं:

  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) } 

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

क्लाइंट कॉन्फ़िगरेशन में, हम गूंज सेवा पर निर्भरता की घोषणा करते हैं:

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

निर्भरता उसी प्रकार की है, जो 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 } 

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

 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. } 

ऑब्जेक्ट क्लाइंट और सर्वर दोनों के कॉन्फ़िगरेशन को लागू करता है। जीवनकाल के बाद कार्यक्रम को समाप्त करने के लिए जीवनकाल के विन्यास का भी उपयोग किया जाता है। (Ctrl-C भी सभी संसाधनों को सही ढंग से काम करता है और मुक्त करता है।)

विन्यास गुण और कार्यान्वयन के एक ही सेट का उपयोग दो अलग नोड्स से मिलकर एक सिस्टम बनाने के लिए किया जा सकता है:

  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 } 

सामान्य विकास प्रक्रिया

आइए देखें कि यह कॉन्फ़िगरेशन दृष्टिकोण समग्र विकास प्रक्रिया को कैसे प्रभावित करता है।

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

कोई भी कॉन्फ़िगरेशन परिवर्तन कोड परिवर्तन में बदल जाता है। और इसलिए, प्रत्येक ऐसे
परिवर्तन सामान्य गुणवत्ता आश्वासन प्रक्रिया द्वारा कवर किया जाएगा:

बगट्रैकर में एक टिकट -> पीआर -> समीक्षा -> संबंधित शाखाओं के साथ विलय ->
एकीकरण -> तैनाती

संकलित विन्यास को लागू करने के मुख्य परिणाम:

1. कॉन्फ़िगरेशन वितरित सिस्टम के सभी नोड्स पर समन्वित किया जाएगा। इस तथ्य के कारण कि सभी नोड्स एक ही स्रोत से समान कॉन्फ़िगरेशन प्राप्त करते हैं।

   
   

2. केवल एक नोड में कॉन्फ़िगरेशन को बदलना समस्याग्रस्त है। इसलिए, "कॉन्फ़िगरेशन बहाव" की संभावना नहीं है।

   
   

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

   
   

4. अधिकांश कॉन्फ़िगरेशन परिवर्तन समग्र विकास प्रक्रिया के हिस्से के रूप में होंगे और उनकी समीक्षा की जाएगी।

   
   

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

संभव विविधताएं

आइए कुछ सामान्य विकल्पों के साथ संकलित विन्यास की तुलना करने का प्रयास करें:

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

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

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

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

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

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

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

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

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

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

मैं प्रस्तावित प्रौद्योगिकी के पेशेवरों और विपक्षों पर ध्यान देना चाहूंगा।

लाभ

निम्नलिखित एक संकलित वितरित प्रणाली विन्यास की मुख्य विशेषताओं की सूची है:

1. स्थैतिक विन्यास की जाँच। आपको यह सुनिश्चित करने की अनुमति देता है कि
   कॉन्फ़िगरेशन सही है।
2. . . Scala , . ,
   trait' , , val', (DRY) . ( Seq , Map , ).
3. DSL. Scala , DSL. , , , . , , .
4. . , , , , . , . , .
5. . , , .
6. . , .
7. . , . . ( , , , , -.) — . , , , , .
8. . , . , , . . . , production'.
9. . , . , , — . production- .
10. परीक्षण। mock-, , .
11. . . , , , .

. :

1. . production', . . . .
2. . , , .
3. . , , . / .
4. . DevOps . .
5. . (CI/CD). .

, :

1. , , . , Cake Pattern' , , HList (case class') .
2. , : ( package , import , ; override def ' , ). , DSL. , (, XML), .
3. .

निष्कर्ष

Scala. xml- . , Scala, ( Kotlin, C#, Swift, ...). , , , , , .

, . .

:

1. .
2. DSL .
3. . , , (1) ; (2) .

, .