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

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

(रशियन मध्ये)

परिचय

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

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

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

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

हे नोड्स विविध भूमिका पार पाडतात, काही सेवा चालवतात आणि इतर नोड्सशी TCP/HTTP कनेक्शनद्वारे संवाद साधण्यास सक्षम असावेत.

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

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]

या प्रोटोकॉलमध्ये विनंती संदेश url मध्ये जोडला जातो आणि प्रतिसाद संदेश प्लेन स्ट्रिंग म्हणून परत केला जातो.

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

केक पॅटर्नचा वापर करून इतर नोड्सचे अंतिम बिंदू म्हणून अवलंबित्वांचे प्रतिनिधित्व केले जाऊ शकते:

  type EchoProtocol[A] = SimpleHttpGetRest[A, A]

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

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

आम्ही इको सर्व्हिस क्लायंटच्या कॉन्फिगरेशनमध्ये अवलंबित्व घोषित करू शकतो:

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

अवलंबित्वाचा सारखाच प्रकार आहे echoService. विशेषतः, तो समान प्रोटोकॉलची मागणी करतो. म्हणून, आपण खात्री बाळगू शकतो की आपण या दोन अवलंबनांना जोडल्यास ते योग्यरित्या कार्य करतील.

सेवा अंमलबजावणी

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

असे कार्य अंमलात आणण्याचे काही संभाव्य मार्ग आहेत.

नोड होस्ट इन्स्टंटिएशन दरम्यान, डिप्लॉयमेंटपूर्वी आम्हाला खरे पत्ते माहित असल्यास, आम्ही वास्तविक पत्त्यांसह स्काला कोड तयार करू शकतो आणि नंतर बिल्ड चालवू शकतो (जे कंपाइल टाइम चेक करते आणि नंतर इंटिग्रेशन टेस्ट सूट चालवते). या प्रकरणात आमचे मॅपिंग कार्य स्थिरपणे ओळखले जाते आणि ते a सारखे काहीतरी सोपे केले जाऊ शकते 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 मध्यांतर पास.

सेवा अंमलबजावणी आणि कॉन्फिगरेशनचा समान संच दोन स्वतंत्र नोड्ससह सिस्टमचे लेआउट तयार करण्यासाठी वापरला जाऊ शकतो. आपण फक्त तयार करणे आवश्यक आहे दोन स्वतंत्र नोड कॉन्फिग योग्य सेवांसह:

दोन नोड्स कॉन्फिगरेशन

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

एकूणच विकास प्रक्रिया

कॉन्फिगरेशनसह कार्य करण्याच्या पद्धतीत हा दृष्टिकोन कसा बदलतो ते पाहू या.

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

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

तिकीट -> PR -> पुनरावलोकन -> विलीनीकरण -> सतत एकत्रीकरण -> सतत तैनाती

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

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

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

विविधता

इतर कॉन्फिगरेशन व्यवस्थापन तंत्रांच्या तुलनेत प्रस्तावित पद्धतीचे फायदे आणि तोटे पाहू.

सर्वप्रथम, कॉन्फिगरेशन हाताळण्याच्या प्रस्तावित पद्धतीच्या विविध पैलूंसाठी आम्ही काही पर्यायांची यादी करू:

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

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

(Btw, जर शेवटी मजकूर कॉन्फिगरेशन फाइल्स वापरणे सुरू करणे आवश्यक असेल, तर आम्हाला फक्त पार्सर + व्हॅलिडेटर जोडावे लागेल जे समान तयार करू शकेल. Config टाइप करा आणि मजकूर कॉन्फिगरेशन वापरणे सुरू करण्यासाठी ते पुरेसे असेल. हे देखील दर्शविते की कंपाइल-टाइम कॉन्फिगरेशनची जटिलता मजकूर-आधारित कॉन्फिगरेशनच्या जटिलतेपेक्षा थोडी कमी आहे, कारण मजकूर-आधारित आवृत्तीमध्ये आपल्याला काही अतिरिक्त कोड आवश्यक आहेत.)

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

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

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

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

आर्टिफॅक्टची आवृत्ती ते केव्हा तयार केले गेले, त्यात कोणती मूल्ये आहेत, कोणती वैशिष्ट्ये सक्षम/अक्षम आहेत, कॉन्फिगरेशनमधील प्रत्येक बदलासाठी कोण जबाबदार आहे हे शोधण्याची परवानगी देते. एखाद्या आर्टिफॅक्टमध्ये कॉन्फिगरेशन ठेवण्यासाठी काही प्रयत्न करावे लागतील आणि ही एक डिझाइन निवड आहे.

साधक आणि बाधक

येथे आम्ही काही फायदे हायलाइट करू इच्छितो आणि प्रस्तावित पद्धतीचे काही तोटे चर्चा करू इच्छितो.

फायदे

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

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

तोटे

संकलित कॉन्फिगरेशन दृष्टीकोन "सामान्य" कॉन्फिगरेशनपेक्षा भिन्न आहे आणि ते सर्व गरजा भागवू शकत नाही. संकलित कॉन्फिगरेशनचे काही तोटे येथे आहेत:

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

अंमलात आणलेल्या उदाहरणाच्या काही मर्यादा आहेत:

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

निष्कर्ष

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

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

हा दृष्टिकोन विविध मार्गांनी वाढविला जाऊ शकतो:

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

धन्यवाद

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

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

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