🥇वितरीत प्रणालीचे संकलित कॉन्फिगरेशन

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

(इंग्रजी)

परिचय

एक विश्वासार्ह वितरण प्रणाली तयार करणे म्हणजे सर्व नोड्स योग्य कॉन्फिगरेशन वापरतात, इतर नोड्ससह समक्रमित करतात. DevOps तंत्रज्ञान (टेराफॉर्म, उत्तरदायी किंवा असे काहीतरी) सहसा आपोआप कॉन्फिगरेशन फाइल्स (प्रत्येक नोडसाठी विशिष्ट) तयार करण्यासाठी वापरले जातात. आम्ही हे देखील सुनिश्चित करू इच्छितो की सर्व संप्रेषण नोड एकसारखे प्रोटोकॉल वापरत आहेत (समान आवृत्तीसह). अन्यथा, आमच्या वितरण प्रणालीमध्ये विसंगती तयार केली जाईल. JVM जगात, या आवश्यकतेचा एक परिणाम म्हणजे प्रोटोकॉल संदेश असलेली लायब्ररीची समान आवृत्ती सर्वत्र वापरली जाणे आवश्यक आहे.

वितरण प्रणालीच्या चाचणीबद्दल काय? अर्थात, आम्ही असे गृहीत धरतो की आम्ही एकत्रीकरण चाचणीकडे जाण्यापूर्वी सर्व घटकांच्या युनिट चाचण्या आहेत. (चाचणीचे निकाल रनटाइममध्ये एक्स्ट्रापोलेट करण्यासाठी, आम्ही चाचणी टप्प्यावर आणि रनटाइमवर लायब्ररींचा एकसमान संच देखील प्रदान केला पाहिजे.)

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

अनुप्रयोगासह कॉन्फिगरेशन विकसित होते. आम्ही प्रोग्राम उत्क्रांतीच्या वेगवेगळ्या अवस्था ओळखण्यासाठी आवृत्त्या वापरतो. कॉन्फिगरेशनच्या भिन्न आवृत्त्या देखील ओळखणे तर्कसंगत वाटते. आणि कॉन्फिगरेशन स्वतः आवृत्ती नियंत्रण प्रणालीमध्ये ठेवा. उत्पादनामध्ये फक्त एक कॉन्फिगरेशन असल्यास, आम्ही फक्त आवृत्ती क्रमांक वापरू शकतो. आपण अनेक उत्पादन उदाहरणे वापरल्यास, आपल्याला अनेकांची आवश्यकता असेल
कॉन्फिगरेशन शाखा आणि आवृत्ती व्यतिरिक्त अतिरिक्त लेबल (उदाहरणार्थ, शाखेचे नाव). अशा प्रकारे आपण अचूक कॉन्फिगरेशन स्पष्टपणे ओळखू शकतो. प्रत्येक कॉन्फिगरेशन अभिज्ञापक वितरीत नोड्स, पोर्ट्स, बाह्य संसाधने आणि लायब्ररी आवृत्त्यांच्या विशिष्ट संयोजनाशी अनन्यपणे संबंधित आहे. या पोस्टच्या उद्देशांसाठी आम्ही असे गृहीत धरू की फक्त एक शाखा आहे आणि आम्ही नेहमीच्या पद्धतीने तीन अंकांचा वापर करून कॉन्फिगरेशन ओळखू शकतो (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

नोड्स विविध भूमिका पार पाडतात, ते सेवा चालवतात आणि त्यांच्यामध्ये TCP/HTTP कनेक्शन स्थापित केले जाऊ शकतात.

TCP कनेक्शनचे वर्णन करण्यासाठी आम्हाला किमान एक पोर्ट क्रमांक आवश्यक आहे. क्लायंट आणि सर्व्हर दोघेही समान प्रोटोकॉल वापरत आहेत याची खात्री करण्यासाठी आम्ही त्या पोर्टवर समर्थित प्रोटोकॉल देखील प्रतिबिंबित करू इच्छितो. आम्ही खालील वर्ग वापरून कनेक्शनचे वर्णन करू:

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]

येथे विनंती ही url ला जोडलेली स्ट्रिंग आहे आणि प्रतिसाद HTTP प्रतिसादाच्या मुख्य भागामध्ये परत केलेली स्ट्रिंग आहे.

सेवा कॉन्फिगरेशनचे वर्णन सेवा नाव, पोर्ट आणि अवलंबित्वांद्वारे केले जाते. हे घटक स्कालामध्ये अनेक प्रकारे दर्शविले जाऊ शकतात (उदाहरणार्थ, HList-s, बीजगणितीय डेटा प्रकार). या पोस्टच्या उद्देशांसाठी, आम्ही केक पॅटर्न वापरू आणि वापरून मॉड्यूल्सचे प्रतिनिधित्व करू 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
}

कृपया लक्षात घ्या की आम्ही या नोडसाठी आवश्यक असलेल्या कॉन्फिगरेशनचा अचूक प्रकार निर्दिष्ट करत आहोत. आम्ही एखाद्या विशिष्ट सेवेसाठी आवश्यक असलेल्या कॉन्फिगरेशन प्रकारांपैकी एक निर्दिष्ट करण्यास विसरल्यास, एक संकलन त्रुटी असेल. तसेच, आम्ही सर्व आवश्यक डेटासह योग्य प्रकारची काही वस्तू प्रदान केल्याशिवाय आम्ही नोड सुरू करू शकणार नाही.

होस्ट नाव ठराव

रिमोट होस्टशी कनेक्ट करण्यासाठी, आम्हाला वास्तविक IP पत्ता आवश्यक आहे. उर्वरित कॉन्फिगरेशनपेक्षा पत्ता नंतर ज्ञात होण्याची शक्यता आहे. म्हणून आम्हाला एका फंक्शनची आवश्यकता आहे जे पत्त्यावर नोड आयडी मॅप करते:

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) आणि फक्त ही नावे लिंक करा
तैनाती दरम्यान IP पत्त्यांसह.

या पोस्टमध्ये आम्ही या प्रकरणांचा अधिक तपशीलवार विचार करणार नाही. आमच्यासाठी
खेळण्यांच्या उदाहरणामध्ये, सर्व नोड्समध्ये समान IP पत्ता असेल - 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'om, आणि क्लायंट नोड काही काळानंतर संपुष्टात येईल. सेमी. लाँचर अॅप.

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

या कॉन्फिगरेशनचा दृष्टिकोन एकूण विकास प्रक्रियेवर कसा परिणाम करतो ते पाहू या.

उर्वरित कोडसह कॉन्फिगरेशन संकलित केले जाईल आणि एक आर्टिफॅक्ट (.jar) व्युत्पन्न केले जाईल. कॉन्फिगरेशन वेगळ्या आर्टिफॅक्टमध्ये ठेवणे अर्थपूर्ण आहे असे दिसते. कारण एकाच कोडवर आधारित अनेक कॉन्फिगरेशन्स असू शकतात. पुन्हा, वेगवेगळ्या कॉन्फिगरेशन शाखांशी संबंधित कलाकृती निर्माण करणे शक्य आहे. लायब्ररींच्या विशिष्ट आवृत्त्यांवर अवलंबित्व कॉन्फिगरेशनसह जतन केले जाते आणि जेव्हा आम्ही कॉन्फिगरेशनची ती आवृत्ती उपयोजित करण्याचा निर्णय घेतो तेव्हा या आवृत्त्या कायमच्या जतन केल्या जातात.

कोणताही कॉन्फिगरेशन बदल कोड बदलात बदलतो. आणि म्हणून, प्रत्येक
बदल सामान्य गुणवत्ता हमी प्रक्रियेद्वारे संरक्षित केला जाईल:

बग ट्रॅकरमधील तिकीट -> PR -> पुनरावलोकन -> संबंधित शाखांमध्ये विलीन करा ->
एकत्रीकरण -> उपयोजन

संकलित कॉन्फिगरेशनची अंमलबजावणी करण्याचे मुख्य परिणाम आहेत:

वितरण प्रणालीच्या सर्व नोड्समध्ये कॉन्फिगरेशन सुसंगत असेल. सर्व नोड्स एकाच स्त्रोताकडून समान कॉन्फिगरेशन प्राप्त करतात या वस्तुस्थितीमुळे.
केवळ एका नोड्समध्ये कॉन्फिगरेशन बदलणे समस्याप्रधान आहे. म्हणून, "कॉन्फिगरेशन ड्रिफ्ट" संभव नाही.
छोटे कॉन्फिगरेशन बदल करणे अधिक कठीण होते.
बहुतेक कॉन्फिगरेशन बदल संपूर्ण विकास प्रक्रियेचा भाग म्हणून होतील आणि पुनरावलोकनाच्या अधीन असतील.

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

संभाव्य भिन्नता

चला संकलित कॉन्फिगरेशनची काही सामान्य पर्यायांसह तुलना करण्याचा प्रयत्न करूया:

लक्ष्य मशीनवर मजकूर फाइल.
केंद्रीकृत की-व्हॅल्यू स्टोअर (etcd/zookeeper).
प्रक्रिया घटक जे प्रक्रिया रीस्टार्ट न करता पुन्हा कॉन्फिगर/रीस्टार्ट केले जाऊ शकतात.
आर्टिफॅक्ट आणि आवृत्ती नियंत्रणाच्या बाहेर कॉन्फिगरेशन संचयित करणे.

मजकूर फाइल्स लहान बदलांच्या बाबतीत लक्षणीय लवचिकता प्रदान करतात. सिस्टम प्रशासक रिमोट नोडमध्ये लॉग इन करू शकतो, योग्य फायलींमध्ये बदल करू शकतो आणि सेवा पुन्हा सुरू करू शकतो. मोठ्या प्रणालींसाठी, तथापि, अशी लवचिकता इष्ट असू शकत नाही. केलेल्या बदलांमुळे इतर सिस्टीममध्ये कोणतेही ट्रेस राहिले नाहीत. कोणीही बदलांचे पुनरावलोकन करत नाही. हे बदल नेमके कोणी आणि कोणत्या कारणासाठी केले हे ठरवणे कठीण आहे. बदलांची चाचणी घेतली जात नाही. जर प्रणाली वितरित केली गेली असेल, तर प्रशासक इतर नोड्सवर संबंधित बदल करण्यास विसरेल.

(हे देखील लक्षात घेतले पाहिजे की संकलित कॉन्फिगरेशन वापरणे भविष्यात मजकूर फाइल्स वापरण्याची शक्यता बंद करत नाही. आउटपुट सारख्याच प्रकारची निर्मिती करणारे पार्सर आणि सत्यापनकर्ता जोडणे पुरेसे आहे. Config, आणि तुम्ही मजकूर फाइल्स वापरू शकता. संकलित कॉन्फिगरेशनसह सिस्टमची जटिलता मजकूर फायली वापरणार्‍या सिस्टमच्या जटिलतेपेक्षा काहीशी कमी असते, हे लगेच लक्षात येते. मजकूर फाइल्सना अतिरिक्त कोड आवश्यक आहे.)

वितरित ऍप्लिकेशनच्या मेटा पॅरामीटर्सचे वितरण करण्यासाठी केंद्रीकृत की-व्हॅल्यू स्टोअर ही एक चांगली यंत्रणा आहे. कॉन्फिगरेशन पॅरामीटर्स काय आहेत आणि फक्त डेटा म्हणजे काय हे आम्हाला ठरवायचे आहे. चला एक कार्य करूया C => A => B, आणि पॅरामीटर्स C क्वचितच बदल आणि डेटा A - अनेकदा. या प्रकरणात आपण असे म्हणू शकतो C - कॉन्फिगरेशन पॅरामीटर्स, आणि A - डेटा. असे दिसते की कॉन्फिगरेशन पॅरामीटर्स डेटापेक्षा भिन्न आहेत कारण ते डेटापेक्षा कमी वारंवार बदलतात. तसेच, डेटा सामान्यतः एका स्त्रोताकडून (वापरकर्त्याकडून) आणि दुसर्‍याकडून (सिस्टम प्रशासकाकडून) कॉन्फिगरेशन पॅरामीटर्समधून येतो.

प्रोग्राम रीस्टार्ट न करता क्वचितच बदलणारे पॅरामीटर्स अपडेट करणे आवश्यक असल्यास, यामुळे प्रोग्रामची गुंतागुंत होऊ शकते, कारण आम्हाला पॅरामीटर्स वितरित करणे, संग्रहित करणे, पार्स करणे आणि तपासणे आणि चुकीच्या मूल्यांवर प्रक्रिया करणे आवश्यक आहे. म्हणून, प्रोग्रामची जटिलता कमी करण्याच्या दृष्टिकोनातून, प्रोग्राम ऑपरेशन दरम्यान बदलू शकणार्‍या पॅरामीटर्सची संख्या कमी करणे अर्थपूर्ण आहे (किंवा अशा पॅरामीटर्सना अजिबात समर्थन देत नाही).

या पोस्टच्या उद्देशांसाठी, आम्ही स्थिर आणि डायनॅमिक पॅरामीटर्समध्ये फरक करू. सेवेच्या लॉजिकला प्रोग्रामच्या ऑपरेशन दरम्यान पॅरामीटर्स बदलण्याची आवश्यकता असल्यास, आम्ही अशा पॅरामीटर्सला डायनॅमिक म्हणू. अन्यथा पर्याय स्थिर आहेत आणि संकलित कॉन्फिगरेशन वापरून कॉन्फिगर केले जाऊ शकतात. डायनॅमिक रीकॉन्फिगरेशनसाठी, आम्हाला नवीन पॅरामीटर्ससह प्रोग्रामचे भाग रीस्टार्ट करण्यासाठी एक यंत्रणा आवश्यक असू शकते, जसे ऑपरेटिंग सिस्टम प्रक्रिया पुन्हा सुरू केल्या जातात. (आमच्या मते, रिअल-टाइम रीकॉन्फिगरेशन टाळण्याचा सल्ला दिला जातो, कारण यामुळे सिस्टमची जटिलता वाढते. शक्य असल्यास, प्रक्रिया पुन्हा सुरू करण्यासाठी मानक OS क्षमता वापरणे चांगले.)

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

आता आर्टिफॅक्टच्या आत किंवा बाहेर कॉन्फिगरेशन संचयित करण्याच्या समस्येचा विचार करूया. जर आम्ही एखाद्या आर्टिफॅक्टमध्ये कॉन्फिगरेशन संग्रहित केले, तर किमान आम्हाला आर्टिफॅक्टच्या असेंब्ली दरम्यान कॉन्फिगरेशनची शुद्धता सत्यापित करण्याची संधी होती. कॉन्फिगरेशन नियंत्रित आर्टिफॅक्टच्या बाहेर असल्यास, या फाइलमध्ये बदल कोणी केले आणि का केले याचा मागोवा घेणे कठीण आहे. ते किती महत्त्वाचे आहे? आमच्या मते, बर्याच उत्पादन प्रणालींसाठी स्थिर आणि उच्च-गुणवत्तेचे कॉन्फिगरेशन असणे महत्वाचे आहे.

आर्टिफॅक्टची आवृत्ती तुम्हाला ते केव्हा तयार केले गेले, त्यात कोणती मूल्ये आहेत, कोणती कार्ये सक्षम/अक्षम आहेत आणि कॉन्फिगरेशनमधील कोणत्याही बदलासाठी कोण जबाबदार आहे हे निर्धारित करण्याची परवानगी देते. अर्थात, आर्टिफॅक्टमध्ये कॉन्फिगरेशन संचयित करण्यासाठी काही प्रयत्न करावे लागतील, म्हणून तुम्हाला माहितीपूर्ण निर्णय घेणे आवश्यक आहे.

साधक आणि बाधक

मी प्रस्तावित तंत्रज्ञानाच्या साधक आणि बाधकांवर लक्ष देऊ इच्छितो.

फायदे

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

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

तोटे आणि मर्यादा

संकलित कॉन्फिगरेशन इतर कॉन्फिगरेशन पद्धतींपेक्षा भिन्न आहे आणि काही अनुप्रयोगांसाठी योग्य असू शकत नाही. खाली काही तोटे आहेत:

स्थिर कॉन्फिगरेशन. काहीवेळा आपल्याला सर्व संरक्षणात्मक यंत्रणांना मागे टाकून उत्पादनातील कॉन्फिगरेशन द्रुतपणे दुरुस्त करण्याची आवश्यकता असते. या दृष्टिकोनाने ते अधिक कठीण होऊ शकते. कमीतकमी, संकलन आणि स्वयंचलित उपयोजन अद्याप आवश्यक असेल. हे दृष्टिकोनाचे एक उपयुक्त वैशिष्ट्य आणि काही प्रकरणांमध्ये गैरसोय दोन्ही आहे.
कॉन्फिगरेशन निर्मिती. जर कॉन्फिगरेशन फाइल स्वयंचलित साधनाद्वारे तयार केली गेली असेल तर, बिल्ड स्क्रिप्ट एकत्रित करण्यासाठी अतिरिक्त प्रयत्नांची आवश्यकता असू शकते.
साधने. सध्या, कॉन्फिगरेशनसह कार्य करण्यासाठी डिझाइन केलेली उपयुक्तता आणि तंत्रे मजकूर फाइल्सवर आधारित आहेत. अशा सर्व उपयुक्तता/तंत्रे संकलित कॉन्फिगरेशनमध्ये उपलब्ध नसतील.
दृष्टिकोनात बदल आवश्यक आहे. विकसक आणि DevOps मजकूर फायलींच्या नित्याचा आहेत. कॉन्फिगरेशन संकलित करण्याची कल्पना काहीसे अनपेक्षित आणि असामान्य असू शकते आणि नकार कारणीभूत असू शकते.
उच्च दर्जाची विकास प्रक्रिया आवश्यक आहे. संकलित कॉन्फिगरेशनचा आरामात वापर करण्यासाठी, अनुप्रयोग (CI/CD) तयार आणि तैनात करण्याच्या प्रक्रियेचे संपूर्ण ऑटोमेशन आवश्यक आहे. अन्यथा ते खूप गैरसोयीचे होईल.

आपण संकलित कॉन्फिगरेशनच्या कल्पनेशी संबंधित नसलेल्या विचारात घेतलेल्या उदाहरणाच्या अनेक मर्यादांवर देखील राहू या:

जर आम्ही अनावश्यक कॉन्फिगरेशन माहिती दिली जी नोडद्वारे वापरली जात नाही, तर कंपाइलर गहाळ अंमलबजावणी शोधण्यात आम्हाला मदत करणार नाही. केक पॅटर्नचा त्याग करून आणि अधिक कठोर प्रकार वापरून ही समस्या सोडवली जाऊ शकते, उदाहरणार्थ, HList किंवा कॉन्फिगरेशनचे प्रतिनिधित्व करण्यासाठी बीजगणितीय डेटा प्रकार (केस वर्ग).
कॉन्फिगरेशन फाइलमध्ये अशा ओळी आहेत ज्या कॉन्फिगरेशनशी संबंधित नाहीत: (package, import,वस्तू घोषणा; override defडीफॉल्ट मूल्ये असलेल्या पॅरामीटर्ससाठी s). तुम्ही तुमचा स्वतःचा DSL अंमलात आणल्यास हे अंशतः टाळता येऊ शकते. याव्यतिरिक्त, इतर प्रकारचे कॉन्फिगरेशन (उदाहरणार्थ, XML) देखील फाइल संरचनेवर काही निर्बंध लादतात.
या पोस्टच्या हेतूंसाठी, आम्ही समान नोड्सच्या क्लस्टरच्या डायनॅमिक पुनर्रचनाचा विचार करत नाही.

निष्कर्ष

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

स्वाभाविकच, संकलित कॉन्फिगरेशनसाठी उच्च दर्जाची विकास प्रक्रिया आवश्यक आहे. त्या बदल्यात, कॉन्फिगरेशनची उच्च गुणवत्ता आणि विश्वासार्हता सुनिश्चित केली जाते.

विचारात घेतलेल्या दृष्टिकोनाचा विस्तार केला जाऊ शकतो:

कंपाइल-टाइम चेक करण्यासाठी तुम्ही मॅक्रो वापरू शकता.
अंतिम वापरकर्त्यांना प्रवेश करण्यायोग्य अशा प्रकारे कॉन्फिगरेशन सादर करण्यासाठी तुम्ही DSL लागू करू शकता.
आपण स्वयंचलित कॉन्फिगरेशन समायोजनासह डायनॅमिक संसाधन व्यवस्थापन लागू करू शकता. उदाहरणार्थ, क्लस्टरमधील नोड्सची संख्या बदलण्यासाठी (1) प्रत्येक नोडला थोडे वेगळे कॉन्फिगरेशन प्राप्त करणे आवश्यक आहे; (2) क्लस्टर व्यवस्थापकाला नवीन नोड्सबद्दल माहिती मिळाली.

पोचपावती

आंद्रेई सकसोनोव्ह, पावेल पोपोव्ह आणि अँटोन नेखाएव यांचे मसुदा लेखाच्या रचनात्मक टीकाबद्दल मी आभार मानू इच्छितो.

स्त्रोत: www.habr.com

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