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

म तपाईंलाई वितरित प्रणालीको कन्फिगरेसनसँग काम गर्ने एउटा रोचक संयन्त्र बताउन चाहन्छु। कन्फिगरेसनलाई सुरक्षित प्रकारहरू प्रयोग गरेर कम्पाइल गरिएको भाषा (स्काला) मा प्रत्यक्ष रूपमा प्रतिनिधित्व गरिन्छ। यो पोष्टले यस्तो कन्फिगरेसनको उदाहरण प्रदान गर्दछ र समग्र विकास प्रक्रियामा कम्पाइल गरिएको कन्फिगरेसन लागू गर्ने विभिन्न पक्षहरू छलफल गर्दछ।

(अंग्रेजी)

परिचय

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

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

होस्ट नाम रिजोल्युसन

रिमोट होस्टमा जडान गर्न, हामीलाई वास्तविक आईपी ठेगाना चाहिन्छ। यो सम्भव छ कि ठेगाना बाँकी कन्फिगरेसन भन्दा पछि थाहा हुनेछ। त्यसैले हामीलाई एउटा प्रकार्य चाहिन्छ जसले नोड आईडीलाई ठेगानामा नक्सा गर्छ:

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 ठेगाना हुनेछ - 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"
  }

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

दुई प्रणाली नोड्स को कार्यान्वयन

यस कन्फिगरेसनको लागि, हामी परिवर्तन बिना समान सेवा कार्यान्वयनहरू प्रयोग गर्छौं। फरक मात्र यो हो कि हामीसँग अब दुईवटा वस्तुहरू छन् जसले सेवाहरूको विभिन्न सेटहरू लागू गर्दछ:

  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। Scala मा धेरै भाषा सुविधाहरू छन् जसले यसलाई DSL सिर्जना गर्न सजिलो बनाउँदछ। यी सुविधाहरूको फाइदा उठाउन र प्रयोगकर्ताहरूको लक्षित समूहको लागि थप सुविधाजनक कन्फिगरेसन भाषा लागू गर्न सम्भव छ, ताकि कन्फिगरेसन कम्तिमा डोमेन विशेषज्ञहरूले पढ्न योग्य होस्। विशेषज्ञहरू, उदाहरणका लागि, कन्फिगरेसन समीक्षा प्रक्रियामा भाग लिन सक्छन्।
अखण्डता र नोडहरू बीच सिंक्रोनी। एकल बिन्दुमा भण्डारण गरिएको सम्पूर्ण वितरण प्रणालीको कन्फिगरेसनको फाइदाहरू मध्ये एक यो हो कि सबै मानहरू ठ्याक्कै एक पटक घोषणा गरिन्छ र त्यसपछि आवश्यक भएमा पुन: प्रयोग गरिन्छ। पोर्टहरू घोषणा गर्न फ्यान्टम प्रकारहरू प्रयोग गर्दा नोडहरूले सबै सही प्रणाली कन्फिगरेसनहरूमा मिल्दो प्रोटोकलहरू प्रयोग गरिरहेको सुनिश्चित गर्दछ। नोडहरू बीच स्पष्ट अनिवार्य निर्भरता हुनुले सबै सेवाहरू जडान भएको सुनिश्चित गर्दछ।
उच्च गुणस्तर परिवर्तन। एक साझा विकास प्रक्रिया प्रयोग गरेर कन्फिगरेसनमा परिवर्तन गर्नाले कन्फिगरेसनको लागि उच्च गुणस्तर मापदण्डहरू प्राप्त गर्न सम्भव बनाउँछ।
एक साथ कन्फिगरेसन अपडेट। कन्फिगरेसन परिवर्तन पछि स्वचालित प्रणाली तैनाती सबै नोडहरू अप टु डेट छन् भनेर सुनिश्चित गर्दछ।
आवेदन सरलीकरण। अनुप्रयोगलाई पार्सिङ, कन्फिगरेसन जाँच, वा गलत मानहरू ह्यान्डल गर्न आवश्यक छैन। यसले अनुप्रयोगको जटिलता कम गर्दछ। (हाम्रो उदाहरणमा अवलोकन गरिएका केही कन्फिगरेसन जटिलताहरू कम्पाइल गरिएको कन्फिगरेसनको विशेषता होइन, तर ठूलो प्रकारको सुरक्षा प्रदान गर्ने इच्छाद्वारा संचालित एक सचेत निर्णय मात्र हो।) सामान्य कन्फिगरेसनमा फर्कन एकदमै सजिलो छ - हराएको मात्र कार्यान्वयन गर्नुहोस्। भागहरू। तसर्थ, तपाईं, उदाहरणका लागि, एक कम्पाइल गरिएको कन्फिगरेसनको साथ सुरू गर्न सक्नुहुन्छ, अनावश्यक भागहरूको कार्यान्वयनलाई वास्तवमै आवश्यक नभएसम्म स्थगित गर्दै।
प्रमाणित कन्फिगरेसन। कन्फिगरेसन परिवर्तनहरूले कुनै पनि अन्य परिवर्तनहरूको सामान्य भाग्यलाई पछ्याउने भएकोले, हामीले प्राप्त गर्ने आउटपुट एक अद्वितीय संस्करणको साथ एक कलाकृति हो। यसले हामीलाई अनुमति दिन्छ, उदाहरणका लागि, आवश्यक भएमा कन्फिगरेसनको अघिल्लो संस्करणमा फर्कन। हामी एक वर्ष पहिलेको कन्फिगरेसन पनि प्रयोग गर्न सक्छौं र प्रणालीले ठ्याक्कै उस्तै काम गर्नेछ। एक स्थिर कन्फिगरेसनले वितरित प्रणालीको भविष्यवाणी र विश्वसनीयता सुधार गर्दछ। कन्फिगरेसन संकलन चरणमा निश्चित भएकोले, उत्पादनमा यसलाई नक्कली गर्न धेरै गाह्रो छ।
मोडुलरिटी। प्रस्तावित ढाँचा मोड्युलर छ र मोड्युलहरू विभिन्न प्रणालीहरू सिर्जना गर्न विभिन्न तरिकामा जोड्न सकिन्छ। विशेष रूपमा, तपाइँ प्रणालीलाई एक अवतारमा एकल नोडमा र अर्कोमा धेरै नोडहरूमा चलाउन कन्फिगर गर्न सक्नुहुन्छ। तपाइँ प्रणालीको उत्पादन उदाहरणहरूको लागि धेरै कन्फिगरेसनहरू सिर्जना गर्न सक्नुहुन्छ।
परीक्षण। नक्कली वस्तुहरूसँग व्यक्तिगत सेवाहरू प्रतिस्थापन गरेर, तपाइँ परीक्षणको लागि सुविधाजनक प्रणालीका धेरै संस्करणहरू प्राप्त गर्न सक्नुहुन्छ।
एकीकरण परीक्षण। सम्पूर्ण वितरण प्रणालीको लागि एकल कन्फिगरेसन भएकोले एकीकरण परीक्षणको भागको रूपमा नियन्त्रित वातावरणमा सबै कम्पोनेन्टहरू चलाउन सम्भव बनाउँछ। अनुकरण गर्न सजिलो छ, उदाहरणका लागि, केही नोडहरू पहुँचयोग्य हुने अवस्था।

हानि र सीमाहरू

कम्पाइल गरिएको कन्फिगरेसन अन्य कन्फिगरेसन दृष्टिकोणहरू भन्दा फरक छ र केही अनुप्रयोगहरूको लागि उपयुक्त नहुन सक्छ। तल केही बेफाइदाहरू छन्:

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

कम्पाइल गरिएको कन्फिगरेसनको विचारसँग सम्बन्धित नभएको विचार गरिएको उदाहरणका सीमितताहरूको संख्यामा पनि ध्यान दिऔं:

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

निष्कर्षमा

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

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

विचार गरिएको दृष्टिकोण विस्तार गर्न सकिन्छ:

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

स्वीकार

म मस्यौदा लेखको रचनात्मक आलोचनाको लागि आन्द्रेई साक्सोनोभ, पावेल पोपोभ र एन्टोन नेखाएभलाई धन्यवाद दिन चाहन्छु।

स्रोत: www.habr.com

कम्पाइल गरिएको वितरित प्रणाली कन्फिगरेसन