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

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

(на русском)

परिचय

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

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

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

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

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

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

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

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

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

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

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

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

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

प्रेत प्रकार

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

सबसे व्यापक रूप से उपयोग किए जाने वाले प्रोटोकॉल में से एक JSON क्रमबद्धता के साथ REST API है:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

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

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

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

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

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

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

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

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

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

ऐसे फ़ंक्शन को कार्यान्वित करने के कुछ संभावित तरीके हैं।

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

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

दो नोड्स विन्यास

  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, जबकि इको क्लाइंट कॉन्फ़िगर की गई सीमित अवधि के बाद समाप्त हो जाएगा। देखें स्टार्टर आवेदन ब्योरा हेतु।

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

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

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

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

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

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

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

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

विविधतायें

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

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

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

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

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

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

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

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

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

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

फायदे नुकसान

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

फायदे

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

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

नुकसान

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

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

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

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

निष्कर्ष

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

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

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

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

धन्यवाद

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

स्रोत: www.habr.com

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