🥇वितरित प्रणाली का संकलित विन्यास

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

(अंग्रेज़ी)

परिचय

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

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

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

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

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

इस पोस्ट में हम एक संकलित आर्टिफैक्ट के अंदर एक कॉन्फ़िगरेशन का प्रतिनिधित्व करने के विचार का पता लगाएंगे।

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

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

आमतौर पर एक वितरित प्रणाली में कई नोड होते हैं। आप कुछ प्रकार के मानों का उपयोग करके नोड्स की पहचान कर सकते हैं NodeId:

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

या

case class NodeId(hostName: String)

या यहाँ तक कि

object Singleton
type NodeId = Singleton.type

नोड्स विभिन्न भूमिकाएँ निभाते हैं, वे सेवाएँ चलाते हैं और उनके बीच टीसीपी/HTTP कनेक्शन स्थापित किए जा सकते हैं।

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

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

जहां Port - बस एक पूर्णांक Int с указанием диапазона допустимых значений:

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

परिष्कृत प्रकार

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

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]

यहां अनुरोध यूआरएल से जुड़ी एक स्ट्रिंग है और प्रतिक्रिया HTTP प्रतिक्रिया के मुख्य भाग में लौटाई गई स्ट्रिंग है।

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

सेवाओं के बीच निर्भरता को पोर्ट लौटाने वाली विधियों के रूप में दर्शाया जा सकता है 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. विशेष रूप से, इको क्लाइंट में हमें समान प्रोटोकॉल की आवश्यकता होती है। इसलिए, दो सेवाओं को जोड़ते समय, हम यह सुनिश्चित कर सकते हैं कि सब कुछ सही ढंग से काम करेगा।

सेवाओं का कार्यान्वयन

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

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

जहां

Config - इस सेवा के लिए कॉन्फ़िगरेशन प्रकार
AddressResolver - एक रनटाइम ऑब्जेक्ट जो आपको अन्य नोड्स के पते ढूंढने की अनुमति देता है (नीचे देखें)

और पुस्तकालय से अन्य प्रकार cats:

F[_] - प्रभाव का प्रकार (सरलतम मामले में F[A] बस एक कार्य हो सकता है () => A. इस पोस्ट में हम प्रयोग करेंगे cats.IO.)
Reader[A,B] - कमोबेश फ़ंक्शन का पर्यायवाची A => B
cats.Resource - एक संसाधन जिसे प्राप्त और जारी किया जा सकता है
Timer - टाइमर (आपको थोड़ी देर के लिए सो जाने और समय अंतराल मापने की अनुमति देता है)
ContextShift - एनालॉग ExecutionContext
Applicative - एक प्रभाव प्रकार वर्ग जो आपको व्यक्तिगत प्रभावों (लगभग एक सन्यासी) को संयोजित करने की अनुमति देता है। अधिक जटिल अनुप्रयोगों में इसका उपयोग करना बेहतर लगता है Monad/ConcurrentEffect.

इस फ़ंक्शन हस्ताक्षर का उपयोग करके हम कई सेवाएँ कार्यान्वित कर सकते हैं। उदाहरण के लिए, एक ऐसी सेवा जो कुछ नहीं करती:

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

इस फ़ंक्शन को कार्यान्वित करने के कई तरीके हैं:

यदि तैनाती से पहले पते हमें ज्ञात हो जाते हैं, तो हम स्काला कोड उत्पन्न कर सकते हैं
पते और फिर बिल्ड चलाएँ। यह परीक्षण संकलित और चलाएगा।
इस मामले में, फ़ंक्शन को स्थिर रूप से जाना जाएगा और मैपिंग के रूप में कोड में दर्शाया जा सकता है Map[NodeId, NodeAddress].
कुछ मामलों में, वास्तविक पता नोड शुरू होने के बाद ही ज्ञात होता है।
इस मामले में, हम एक "खोज सेवा" लागू कर सकते हैं जो अन्य नोड्स से पहले चलती है और सभी नोड्स इस सेवा के साथ पंजीकृत होंगे और अन्य नोड्स के पते का अनुरोध करेंगे।
अगर हम संशोधित कर सकते हैं /etc/hosts, तो आप पूर्वनिर्धारित होस्टनाम (जैसे) का उपयोग कर सकते हैं my-project-main-node и echo-backend) और बस इन नामों को लिंक करें
तैनाती के दौरान आईपी पते के साथ।

इस पोस्ट में हम इन मामलों पर अधिक विस्तार से विचार नहीं करेंगे। हमारे लिए
खिलौने के उदाहरण में, सभी नोड्स का आईपी पता समान होगा - 127.0.0.1.

आगे, हम वितरित प्रणाली के लिए दो विकल्पों पर विचार करते हैं:

सभी सेवाओं को एक नोड पर रखना।
और विभिन्न नोड्स पर इको सेवा और इको क्लाइंट को होस्ट करना।

के लिए कॉन्फ़िगरेशन एक नोड:

एकल नोड विन्यास

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 कार्यक्रम समाप्त करें. (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
  }

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

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

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

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

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

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

संकलित कॉन्फ़िगरेशन को लागू करने के मुख्य परिणाम हैं:

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

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

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

आइए संकलित कॉन्फ़िगरेशन की तुलना कुछ सामान्य विकल्पों से करने का प्रयास करें:

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

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

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

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

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

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

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

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

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

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

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

लाभ

संकलित वितरित सिस्टम कॉन्फ़िगरेशन की मुख्य विशेषताओं की सूची नीचे दी गई है:

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

हानियाँ एवं सीमाएँ

संकलित कॉन्फ़िगरेशन अन्य कॉन्फ़िगरेशन दृष्टिकोणों से भिन्न है और कुछ अनुप्रयोगों के लिए उपयुक्त नहीं हो सकता है। नीचे कुछ नुकसान दिए गए हैं:

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

आइए हम विचारित उदाहरण की कई सीमाओं पर भी ध्यान दें जो संकलित कॉन्फ़िगरेशन के विचार से संबंधित नहीं हैं:

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

निष्कर्ष

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

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

सुविचारित दृष्टिकोण का विस्तार किया जा सकता है:

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

स्वीकृतियाँ

मैं मसौदा लेख की रचनात्मक आलोचना के लिए आंद्रेई साकसोनोव, पावेल पोपोव और एंटोन नेखाएव को धन्यवाद देना चाहता हूं।

स्रोत: www.habr.com

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