పంపిణీ చేయబడిన సిస్టమ్ యొక్క సంకలన కాన్ఫిగరేషన్

ఈ పోస్ట్‌లో మేము పంపిణీ చేయబడిన సిస్టమ్ కాన్ఫిగరేషన్‌తో వ్యవహరించే ఆసక్తికరమైన మార్గాన్ని భాగస్వామ్యం చేయాలనుకుంటున్నాము.
కాన్ఫిగరేషన్ నేరుగా స్కాలా భాషలో టైప్ సురక్షిత పద్ధతిలో సూచించబడుతుంది. ఒక ఉదాహరణ అమలు వివరంగా వివరించబడింది. మొత్తం అభివృద్ధి ప్రక్రియపై ప్రభావంతో సహా ప్రతిపాదనలోని వివిధ అంశాలు చర్చించబడ్డాయి.

(రష్యన్ భాషలో)

పరిచయం

బలమైన పంపిణీ వ్యవస్థలను నిర్మించడానికి అన్ని నోడ్‌లలో సరైన మరియు పొందికైన కాన్ఫిగరేషన్‌ను ఉపయోగించడం అవసరం. పాఠ్య విస్తరణ వివరణ (టెర్రాఫార్మ్, యాన్సిబుల్ లేదా ఇలాంటిదే) మరియు స్వయంచాలకంగా రూపొందించబడిన కాన్ఫిగరేషన్ ఫైల్‌లను ఉపయోగించడం ఒక సాధారణ పరిష్కారం (తరచుగా - ప్రతి నోడ్/పాత్రకు అంకితం చేయబడింది). మేము ప్రతి కమ్యూనికేటింగ్ నోడ్‌లలో ఒకే సంస్కరణల యొక్క అదే ప్రోటోకాల్‌లను కూడా ఉపయోగించాలనుకుంటున్నాము (లేకపోతే మేము అననుకూల సమస్యలను ఎదుర్కొంటాము). JVM ప్రపంచంలో దీని అర్థం అన్ని కమ్యూనికేట్ నోడ్‌లలో కనీసం మెసేజింగ్ లైబ్రరీ ఒకే వెర్షన్‌లో ఉండాలి.

సిస్టమ్‌ను పరీక్షించడం గురించి ఏమిటి? వాస్తవానికి, ఇంటిగ్రేషన్ పరీక్షలకు వచ్చే ముందు మేము అన్ని భాగాల కోసం యూనిట్ పరీక్షలను కలిగి ఉండాలి. రన్‌టైమ్‌లో పరీక్ష ఫలితాలను ఎక్స్‌ట్రాపోలేట్ చేయడానికి, రన్‌టైమ్ మరియు టెస్టింగ్ ఎన్విరాన్‌మెంట్‌లలో అన్ని లైబ్రరీల వెర్షన్‌లు ఒకేలా ఉండేలా చూసుకోవాలి.

ఇంటిగ్రేషన్ పరీక్షలను అమలు చేస్తున్నప్పుడు, అన్ని నోడ్‌లలో ఒకే క్లాస్‌పాత్‌ను కలిగి ఉండటం చాలా సులభం. విస్తరణలో అదే క్లాస్‌పాత్ ఉపయోగించబడిందని మేము నిర్ధారించుకోవాలి. (వేర్వేరు నోడ్‌లపై విభిన్న క్లాస్‌పాత్‌లను ఉపయోగించడం సాధ్యమవుతుంది, కానీ ఈ కాన్ఫిగరేషన్‌ను సూచించడం మరియు దానిని సరిగ్గా అమలు చేయడం చాలా కష్టం.) కాబట్టి విషయాలను సరళంగా ఉంచడానికి మేము అన్ని నోడ్‌లలో ఒకే రకమైన క్లాస్‌పాత్‌లను మాత్రమే పరిశీలిస్తాము.

కాన్ఫిగరేషన్ సాఫ్ట్‌వేర్‌తో కలిసి అభివృద్ధి చెందుతుంది. మేము సాధారణంగా వివిధ రకాలను గుర్తించడానికి సంస్కరణలను ఉపయోగిస్తాము
సాఫ్ట్‌వేర్ పరిణామ దశలు. సంస్కరణ నిర్వహణలో కాన్ఫిగరేషన్‌ను కవర్ చేయడం మరియు కొన్ని లేబుల్‌లతో విభిన్న కాన్ఫిగరేషన్‌లను గుర్తించడం సహేతుకంగా కనిపిస్తుంది. ఉత్పత్తిలో ఒకే కాన్ఫిగరేషన్ ఉంటే, మేము ఐడెంటిఫైయర్‌గా ఒకే సంస్కరణను ఉపయోగించవచ్చు. కొన్నిసార్లు మనకు బహుళ ఉత్పత్తి వాతావరణాలు ఉండవచ్చు. మరియు ప్రతి పర్యావరణం కోసం మనకు ప్రత్యేక కాన్ఫిగరేషన్ శాఖ అవసరం కావచ్చు. కాబట్టి వేర్వేరు కాన్ఫిగరేషన్‌లను ప్రత్యేకంగా గుర్తించడానికి కాన్ఫిగరేషన్‌లు బ్రాంచ్ మరియు వెర్షన్‌తో లేబుల్ చేయబడవచ్చు. ప్రతి బ్రాంచ్ లేబుల్ మరియు సంస్కరణ ప్రతి నోడ్‌లో పంపిణీ చేయబడిన నోడ్‌లు, పోర్ట్‌లు, బాహ్య వనరులు, క్లాస్‌పాత్ లైబ్రరీ వెర్షన్‌ల యొక్క ఒకే కలయికకు అనుగుణంగా ఉంటాయి. ఇక్కడ మేము ఒకే శాఖను మాత్రమే కవర్ చేస్తాము మరియు ఇతర కళాఖండాల మాదిరిగానే మూడు భాగాల దశాంశ వెర్షన్ (1.2.3) ద్వారా కాన్ఫిగరేషన్‌లను గుర్తిస్తాము.

ఆధునిక పరిసరాలలో కాన్ఫిగరేషన్ ఫైల్‌లు ఇకపై మానవీయంగా సవరించబడవు. సాధారణంగా మేము ఉత్పత్తి చేస్తాము
విస్తరణ సమయంలో ఫైళ్లను config చేయండి మరియు వాటిని ఎప్పుడూ తాకవద్దు తరువాత. కాబట్టి కాన్ఫిగరేషన్ ఫైల్‌ల కోసం మనం ఇప్పటికీ టెక్స్ట్ ఫార్మాట్‌ను ఎందుకు ఉపయోగిస్తాము అని ఎవరైనా అడగవచ్చు? కాన్ఫిగరేషన్‌ను కంపైలేషన్ యూనిట్‌లో ఉంచడం మరియు కంపైల్-టైమ్ కాన్ఫిగరేషన్ ధ్రువీకరణ నుండి ప్రయోజనం పొందడం ఆచరణీయమైన ఎంపిక.

ఈ పోస్ట్‌లో మేము సంకలనం చేసిన కళాఖండంలో కాన్ఫిగరేషన్‌ను ఉంచే ఆలోచనను పరిశీలిస్తాము.

సంకలనం చేయగల కాన్ఫిగరేషన్

ఈ విభాగంలో మేము స్టాటిక్ కాన్ఫిగరేషన్ యొక్క ఉదాహరణను చర్చిస్తాము. రెండు సాధారణ సేవలు - ఎకో సర్వీస్ మరియు ఎకో సర్వీస్ యొక్క క్లయింట్ కాన్ఫిగర్ చేయబడుతున్నాయి మరియు అమలు చేయబడుతున్నాయి. రెండు సేవలతో రెండు వేర్వేరు పంపిణీ వ్యవస్థలు తక్షణమే ప్రారంభించబడతాయి. ఒకటి ఒకే నోడ్ కాన్ఫిగరేషన్ కోసం మరియు మరొకటి రెండు నోడ్ కాన్ఫిగరేషన్ కోసం.

ఒక సాధారణ పంపిణీ వ్యవస్థ కొన్ని నోడ్‌లను కలిగి ఉంటుంది. కొన్ని రకాలను ఉపయోగించి నోడ్‌లను గుర్తించవచ్చు:

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 - యొక్క అనలాగ్ 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]]
}

అటువంటి ఫంక్షన్‌ను అమలు చేయడానికి కొన్ని మార్గాలు ఉన్నాయి.

1. నోడ్ హోస్ట్ ఇన్‌స్టంటేషన్ సమయంలో, విస్తరణకు ముందు అసలు చిరునామాలు మనకు తెలిస్తే, మేము వాస్తవ చిరునామాలతో స్కాలా కోడ్‌ను రూపొందించి, ఆ తర్వాత బిల్డ్‌ను అమలు చేయవచ్చు (ఇది సమయ తనిఖీలను కంపైల్ చేసి, ఆపై ఇంటిగ్రేషన్ టెస్ట్ సూట్‌ను అమలు చేస్తుంది). ఈ సందర్భంలో మా మ్యాపింగ్ ఫంక్షన్ స్థిరంగా తెలుసు మరియు ఒక వంటి వాటికి సరళీకృతం చేయవచ్చు Map[NodeId, NodeAddress].
2. కొన్నిసార్లు మేము నోడ్ ప్రారంభించబడిన తర్వాతి సమయంలో మాత్రమే వాస్తవ చిరునామాలను పొందుతాము లేదా ఇంకా ప్రారంభించబడని నోడ్‌ల చిరునామాలు మా వద్ద లేవు. ఈ సందర్భంలో, మేము అన్ని ఇతర నోడ్‌ల కంటే ముందు ప్రారంభించబడిన డిస్కవరీ సేవను కలిగి ఉండవచ్చు మరియు ప్రతి నోడ్ ఆ సేవలో దాని చిరునామాను ప్రకటించవచ్చు మరియు డిపెండెన్సీలకు సభ్యత్వాన్ని పొందవచ్చు.
3. మనం సవరించగలిగితే /etc/hosts, మేము ముందే నిర్వచించిన హోస్ట్ పేర్లను ఉపయోగించవచ్చు (వంటి my-project-main-node మరియు echo-backend) మరియు విస్తరణ సమయంలో ఈ పేరును ip చిరునామాతో అనుబంధించండి.

ఈ పోస్ట్‌లో మేము ఈ కేసులను మరిన్ని వివరాలతో కవర్ చేయము. వాస్తవానికి మా బొమ్మ ఉదాహరణలో అన్ని నోడ్‌లు ఒకే IP చిరునామాను కలిగి ఉంటాయి - 127.0.0.1.

ఈ పోస్ట్‌లో మేము రెండు పంపిణీ చేయబడిన సిస్టమ్ లేఅవుట్‌లను పరిశీలిస్తాము:

1. ఒకే నోడ్ లేఅవుట్, ఇక్కడ అన్ని సేవలు ఒకే నోడ్‌లో ఉంచబడతాయి.
2. రెండు నోడ్ లేఅవుట్, ఇక్కడ సర్వీస్ మరియు క్లయింట్ వేర్వేరు నోడ్‌లలో ఉంటాయి.

a కోసం కాన్ఫిగరేషన్ ఒకే నోడ్ లేఅవుట్ క్రింది విధంగా ఉంది:

సింగిల్ నోడ్ కాన్ఫిగరేషన్

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 -> సమీక్ష -> విలీనం -> నిరంతర ఏకీకరణ -> నిరంతర విస్తరణ

విధానం యొక్క క్రింది పరిణామాలు ఉన్నాయి:

1. నిర్దిష్ట సిస్టమ్ ఉదాహరణకి కాన్ఫిగరేషన్ పొందికగా ఉంటుంది. నోడ్‌ల మధ్య తప్పు కనెక్షన్‌ని కలిగి ఉండటానికి మార్గం లేదని తెలుస్తోంది.
2. కేవలం ఒక నోడ్‌లో కాన్ఫిగరేషన్‌ని మార్చడం అంత సులభం కాదు. కొన్ని టెక్స్ట్ ఫైల్‌లను లాగిన్ చేసి మార్చడం అసమంజసంగా అనిపిస్తుంది. కాబట్టి కాన్ఫిగరేషన్ డ్రిఫ్ట్ తక్కువ సాధ్యం అవుతుంది.
3. చిన్న కాన్ఫిగరేషన్ మార్పులు చేయడం సులభం కాదు.
4. చాలా కాన్ఫిగరేషన్ మార్పులు ఒకే డెవలప్‌మెంట్ ప్రాసెస్‌ను అనుసరిస్తాయి మరియు ఇది కొంత సమీక్షను పాస్ చేస్తుంది.

ఉత్పత్తి కాన్ఫిగరేషన్ కోసం మనకు ప్రత్యేక రిపోజిటరీ అవసరమా? ప్రొడక్షన్ కాన్ఫిగరేషన్‌లో చాలా మంది వ్యక్తులకు దూరంగా ఉంచాలనుకుంటున్న సున్నితమైన సమాచారం ఉండవచ్చు. కాబట్టి ఉత్పత్తి కాన్ఫిగరేషన్‌ను కలిగి ఉండే పరిమితం చేయబడిన యాక్సెస్‌తో ప్రత్యేక రిపోజిటరీని ఉంచడం విలువైనదే కావచ్చు. మేము కాన్ఫిగరేషన్‌ను రెండు భాగాలుగా విభజించవచ్చు - ఉత్పత్తి యొక్క అత్యంత బహిరంగ పారామితులను కలిగి ఉన్న ఒకటి మరియు కాన్ఫిగరేషన్ యొక్క రహస్య భాగాన్ని కలిగి ఉంటుంది. ఇది చాలా మంది డెవలపర్‌లకు చాలా ఎక్కువ పారామీటర్‌లకు యాక్సెస్‌ను ఎనేబుల్ చేస్తుంది, అదే సమయంలో చాలా సున్నితమైన విషయాలకు యాక్సెస్‌ని పరిమితం చేస్తుంది. డిఫాల్ట్ పారామీటర్ విలువలతో ఇంటర్మీడియట్ లక్షణాలను ఉపయోగించి దీన్ని సాధించడం సులభం.

బేధాలు

ఇతర కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ టెక్నిక్‌లతో పోలిస్తే ప్రతిపాదిత విధానం యొక్క లాభాలు మరియు నష్టాలను చూద్దాం.

అన్నింటిలో మొదటిది, కాన్ఫిగరేషన్‌తో వ్యవహరించే ప్రతిపాదిత మార్గం యొక్క విభిన్న అంశాలకు మేము కొన్ని ప్రత్యామ్నాయాలను జాబితా చేస్తాము:

1. లక్ష్య యంత్రంలో టెక్స్ట్ ఫైల్.
2. కేంద్రీకృత కీ-విలువ నిల్వ (వంటి etcd/zookeeper).
3. ప్రక్రియను పునఃప్రారంభించకుండానే తిరిగి కాన్ఫిగర్ చేయబడే/పునఃప్రారంభించబడే ఉపప్రాసెస్ భాగాలు.
4. కళాకృతి మరియు సంస్కరణ నియంత్రణ వెలుపల కాన్ఫిగరేషన్.

టెక్స్ట్ ఫైల్ తాత్కాలిక పరిష్కారాల పరంగా కొంత సౌలభ్యాన్ని ఇస్తుంది. సిస్టమ్ అడ్మినిస్ట్రేటర్ టార్గెట్ నోడ్‌కి లాగిన్ చేసి, మార్పు చేసి, సేవను పునఃప్రారంభించవచ్చు. ఇది పెద్ద సిస్టమ్‌లకు అంత మంచిది కాకపోవచ్చు. మార్పు వెనుక ఎలాంటి జాడలు మిగిలి లేవు. మార్పుని మరొక జత కళ్ళు సమీక్షించలేదు. మార్పుకు కారణమేమిటో కనుగొనడం కష్టంగా ఉండవచ్చు. ఇది పరీక్షించబడలేదు. పంపిణీ చేయబడిన సిస్టమ్ దృక్కోణం నుండి ఒక నిర్వాహకుడు ఇతర నోడ్‌లలో ఒకదానిలో కాన్ఫిగరేషన్‌ను నవీకరించడం మర్చిపోవచ్చు.

(Btw, చివరికి టెక్స్ట్ కాన్ఫిగర్ ఫైల్‌లను ఉపయోగించడం ప్రారంభించాల్సిన అవసరం ఉంటే, మేము పార్సర్ + వాలిడేటర్‌ను మాత్రమే జోడించాలి. Config టైప్ చేయండి మరియు టెక్స్ట్ కాన్ఫిగర్‌లను ఉపయోగించడం ప్రారంభించడానికి ఇది సరిపోతుంది. కంపైల్-టైమ్ కాన్ఫిగరేషన్ యొక్క సంక్లిష్టత టెక్స్ట్-ఆధారిత కాన్ఫిగరేషన్‌ల సంక్లిష్టత కంటే కొంచెం తక్కువగా ఉందని ఇది చూపిస్తుంది, ఎందుకంటే టెక్స్ట్-ఆధారిత సంస్కరణలో మనకు కొంత అదనపు కోడ్ అవసరం.)

అప్లికేషన్ మెటా పారామితులను పంపిణీ చేయడానికి కేంద్రీకృత కీ-విలువ నిల్వ ఒక మంచి విధానం. ఇక్కడ మనం కాన్ఫిగరేషన్ విలువలుగా పరిగణించే వాటిని మరియు కేవలం డేటా అంటే ఏమిటో ఆలోచించాలి. ఒక ఫంక్షన్ ఇచ్చారు C => A => B మనం సాధారణంగా అరుదుగా మారుతున్న విలువలను పిలుస్తాము C "కాన్ఫిగరేషన్", తరచుగా మారుతున్న డేటా A - కేవలం ఇన్పుట్ డేటా. డేటా కంటే ముందుగా ఫంక్షన్‌కు కాన్ఫిగరేషన్ అందించాలి A. ఈ ఆలోచనను బట్టి, కాన్ఫిగరేషన్ డేటాను కేవలం డేటా నుండి వేరు చేయడానికి ఉపయోగించే మార్పుల యొక్క అంచనా ఫ్రీక్వెన్సీ అని మేము చెప్పగలం. డేటా సాధారణంగా ఒక మూలం (యూజర్) నుండి వస్తుంది మరియు కాన్ఫిగరేషన్ వేరే మూలం (అడ్మిన్) నుండి వస్తుంది. ప్రారంభ ప్రక్రియ తర్వాత మార్చగల పారామితులతో వ్యవహరించడం అప్లికేషన్ సంక్లిష్టత పెరుగుదలకు దారితీస్తుంది. అటువంటి పారామితుల కోసం మేము వాటి డెలివరీ మెకానిజం, పార్సింగ్ మరియు ధ్రువీకరణ, తప్పు విలువలను నిర్వహించడం వంటివి నిర్వహించాలి. అందువల్ల, ప్రోగ్రామ్ సంక్లిష్టతను తగ్గించడానికి, మేము రన్‌టైమ్‌లో మార్చగల పారామితుల సంఖ్యను తగ్గించడం మంచిది (లేదా వాటిని పూర్తిగా తొలగించడం కూడా).

ఈ పోస్ట్ యొక్క దృక్కోణం నుండి మనం స్టాటిక్ మరియు డైనమిక్ పారామితుల మధ్య తేడాను గుర్తించాలి. సర్వీస్ లాజిక్‌కు రన్‌టైమ్‌లో కొన్ని పారామీటర్‌ల అరుదైన మార్పు అవసరమైతే, మేము వాటిని డైనమిక్ పారామీటర్‌లు అని పిలుస్తాము. లేకపోతే అవి స్థిరంగా ఉంటాయి మరియు ప్రతిపాదిత విధానాన్ని ఉపయోగించి కాన్ఫిగర్ చేయవచ్చు. డైనమిక్ రీకాన్ఫిగరేషన్ కోసం ఇతర విధానాలు అవసరం కావచ్చు. ఉదాహరణకు, పంపిణీ చేయబడిన సిస్టమ్ యొక్క ప్రత్యేక ప్రక్రియలను పునఃప్రారంభించే విధంగా సిస్టమ్ యొక్క భాగాలు కొత్త కాన్ఫిగరేషన్ పారామితులతో పునఃప్రారంభించబడవచ్చు.
(రన్‌టైమ్ రీకాన్ఫిగరేషన్‌ను నివారించాలనేది నా వినయపూర్వకమైన అభిప్రాయం ఎందుకంటే ఇది సిస్టమ్ యొక్క సంక్లిష్టతను పెంచుతుంది.
రీస్టార్ట్ ప్రాసెస్‌ల OS మద్దతుపై ఆధారపడటం మరింత సరళంగా ఉండవచ్చు. అయినప్పటికీ, ఇది ఎల్లప్పుడూ సాధ్యం కాకపోవచ్చు.)

స్టాటిక్ కాన్ఫిగరేషన్‌ని ఉపయోగించడంలో ఒక ముఖ్యమైన అంశం కొన్నిసార్లు డైనమిక్ కాన్ఫిగరేషన్‌ను (ఇతర కారణాలు లేకుండా) పరిగణించేలా చేస్తుంది, కాన్ఫిగరేషన్ అప్‌డేట్ సమయంలో సర్వీస్ డౌన్‌టైమ్. నిజానికి, మనం స్టాటిక్ కాన్ఫిగరేషన్‌లో మార్పులు చేయవలసి వస్తే, కొత్త విలువలు ప్రభావవంతంగా ఉండేలా సిస్టమ్‌ను పునఃప్రారంభించాలి. వివిధ సిస్టమ్‌ల కోసం డౌన్‌టైమ్ అవసరాలు మారుతూ ఉంటాయి, కాబట్టి ఇది అంత క్లిష్టమైనది కాకపోవచ్చు. ఇది క్లిష్టమైనది అయితే, ఏదైనా సిస్టమ్ పునఃప్రారంభం కావడానికి మనం ముందుగానే ప్లాన్ చేసుకోవాలి. ఉదాహరణకు, మేము అమలు చేయవచ్చు AWS ELB కనెక్షన్ ఖాళీ అవుతోంది. ఈ దృష్టాంతంలో మనం సిస్టమ్‌ను పునఃప్రారంభించవలసి వచ్చినప్పుడల్లా, మేము సిస్టమ్ యొక్క కొత్త ఉదాహరణను సమాంతరంగా ప్రారంభిస్తాము, ఆపై ELBని దానికి మారుస్తాము, అయితే ఇప్పటికే ఉన్న కనెక్షన్‌లకు సర్వీసింగ్ పూర్తి చేయడానికి పాత సిస్టమ్‌ను అనుమతిస్తుంది.

కాన్ఫిగరేషన్‌ను వెర్షన్ చేసిన ఆర్టిఫ్యాక్ట్ లోపల లేదా వెలుపల ఉంచడం గురించి ఏమిటి? ఆర్టిఫ్యాక్ట్ లోపల కాన్ఫిగరేషన్‌ను ఉంచడం అంటే చాలా సందర్భాలలో ఈ కాన్ఫిగరేషన్ ఇతర కళాఖండాల మాదిరిగానే నాణ్యత హామీ ప్రక్రియను ఆమోదించింది. కాబట్టి కాన్ఫిగరేషన్ మంచి నాణ్యత మరియు నమ్మదగినదని ఒకరు ఖచ్చితంగా అనుకోవచ్చు. దీనికి విరుద్ధంగా ప్రత్యేక ఫైల్‌లో కాన్ఫిగరేషన్ అంటే ఆ ఫైల్‌లో ఎవరు మరియు ఎందుకు మార్పులు చేసారు అనే జాడలు లేవు. ఇది ముఖ్యమా? చాలా ఉత్పత్తి సిస్టమ్‌లకు స్థిరమైన మరియు అధిక నాణ్యత గల కాన్ఫిగరేషన్‌ను కలిగి ఉండటం మంచిదని మేము నమ్ముతున్నాము.

కళాకృతి యొక్క సంస్కరణ అది ఎప్పుడు సృష్టించబడింది, దానిలో ఏ విలువలు ఉన్నాయి, ఏ ఫీచర్లు ప్రారంభించబడ్డాయి/నిలిపివేయబడ్డాయి, కాన్ఫిగరేషన్‌లో ప్రతి మార్పు చేయడానికి ఎవరు బాధ్యత వహిస్తారో తెలుసుకోవడానికి అనుమతిస్తుంది. ఆర్టిఫ్యాక్ట్‌లో కాన్ఫిగరేషన్‌ను ఉంచడానికి కొంత ప్రయత్నం అవసరం కావచ్చు మరియు ఇది డిజైన్ ఎంపిక.

లాభాలు

ఇక్కడ మేము కొన్ని ప్రయోజనాలను హైలైట్ చేయాలనుకుంటున్నాము మరియు ప్రతిపాదిత విధానం యొక్క కొన్ని ప్రతికూలతలను చర్చించాలనుకుంటున్నాము.

ప్రయోజనాలు

పూర్తి పంపిణీ వ్యవస్థ యొక్క సంకలన కాన్ఫిగరేషన్ యొక్క లక్షణాలు:

1. కాన్ఫిగరేషన్ యొక్క స్టాటిక్ చెక్. ఇది అధిక స్థాయి విశ్వాసాన్ని ఇస్తుంది, కాన్ఫిగరేషన్ ఇచ్చిన రకం పరిమితులు సరైనవని.
2. కాన్ఫిగరేషన్ యొక్క గొప్ప భాష. సాధారణంగా ఇతర కాన్ఫిగరేషన్ విధానాలు చాలా వేరియబుల్ ప్రత్యామ్నాయానికి పరిమితం చేయబడతాయి.
   Scalaని ఉపయోగించడం ద్వారా కాన్ఫిగరేషన్‌ను మెరుగ్గా చేయడానికి విస్తృత శ్రేణి భాషా లక్షణాలను ఉపయోగించవచ్చు. ఉదాహరణకు, మేము డిఫాల్ట్ విలువలను అందించడానికి లక్షణాలను ఉపయోగించవచ్చు, విభిన్న పరిధిని సెట్ చేయడానికి ఆబ్జెక్ట్‌లు, మేము వీటిని సూచించవచ్చు valలు బాహ్య పరిధిలో (DRY) ఒక్కసారి మాత్రమే నిర్వచించబడ్డాయి. లిటరల్ సీక్వెన్స్‌లు లేదా కొన్ని తరగతుల ఉదంతాలను ఉపయోగించడం సాధ్యమవుతుంది (Seq, Map, మొదలైనవి).
3. DSL. స్కాలాకు DSL రచయితలకు మంచి మద్దతు ఉంది. తుది కాన్ఫిగరేషన్ డొమైన్ వినియోగదారులు కనీసం చదవగలిగేలా, మరింత సౌకర్యవంతంగా మరియు తుది వినియోగదారుకు అనుకూలమైన కాన్ఫిగరేషన్ భాషను ఏర్పాటు చేయడానికి ఈ లక్షణాలను ఉపయోగించవచ్చు.
4. నోడ్స్ అంతటా సమగ్రత మరియు పొందిక. మొత్తం పంపిణీ చేయబడిన సిస్టమ్ కోసం ఒకే చోట కాన్ఫిగరేషన్‌ను కలిగి ఉండటం వల్ల కలిగే ప్రయోజనాల్లో ఒకటి, అన్ని విలువలు ఖచ్చితంగా ఒకసారి నిర్వచించబడతాయి మరియు మనకు అవసరమైన అన్ని ప్రదేశాలలో మళ్లీ ఉపయోగించబడతాయి. సురక్షిత పోర్ట్ డిక్లరేషన్‌లను టైప్ చేయండి, సాధ్యమయ్యే అన్ని సరైన కాన్ఫిగరేషన్‌లలో సిస్టమ్ నోడ్‌లు ఒకే భాష మాట్లాడతాయని నిర్ధారిస్తుంది. నోడ్‌ల మధ్య స్పష్టమైన డిపెండెన్సీలు ఉన్నాయి, ఇది కొన్ని సేవలను అందించడం మర్చిపోవడాన్ని కష్టతరం చేస్తుంది.
5. మార్పుల యొక్క అధిక నాణ్యత. సాధారణ PR ప్రక్రియ ద్వారా కాన్ఫిగరేషన్ మార్పులను ఆమోదించే మొత్తం విధానం కాన్ఫిగరేషన్‌లో కూడా అధిక నాణ్యత ప్రమాణాలను ఏర్పాటు చేస్తుంది.
6. ఏకకాల కాన్ఫిగరేషన్ మార్పులు. మేము కాన్ఫిగరేషన్‌లో ఏవైనా మార్పులు చేసినప్పుడల్లా ఆటోమేటిక్ డిప్లాయ్‌మెంట్ అన్ని నోడ్‌లు నవీకరించబడుతున్నాయని నిర్ధారిస్తుంది.
7. అప్లికేషన్ సరళీకరణ. అప్లికేషన్ కాన్ఫిగరేషన్‌ను అన్వయించడం మరియు ధృవీకరించడం మరియు తప్పు కాన్ఫిగరేషన్ విలువలను నిర్వహించడం అవసరం లేదు. ఇది మొత్తం అప్లికేషన్‌ను సులభతరం చేస్తుంది. (కొంత సంక్లిష్టత పెరుగుదల కాన్ఫిగరేషన్‌లోనే ఉంది, కానీ ఇది భద్రత పట్ల అవగాహనతో కూడిన ట్రేడ్-ఆఫ్.) సాధారణ కాన్ఫిగరేషన్‌కు తిరిగి రావడం చాలా సూటిగా ఉంటుంది - కేవలం తప్పిపోయిన ముక్కలను జోడించండి. కంపైల్డ్ కాన్ఫిగరేషన్‌తో ప్రారంభించడం సులభం మరియు అదనపు భాగాల అమలును కొన్ని తర్వాతి సమయాలకు వాయిదా వేయండి.
8. సంస్కరణ కాన్ఫిగరేషన్. కాన్ఫిగరేషన్ మార్పులు అదే డెవలప్‌మెంట్ ప్రాసెస్‌ను అనుసరిస్తాయనే వాస్తవం కారణంగా, ఫలితంగా మేము ప్రత్యేకమైన సంస్కరణతో ఒక కళాఖండాన్ని పొందుతాము. ఇది అవసరమైతే కాన్ఫిగరేషన్‌ను తిరిగి మార్చడానికి అనుమతిస్తుంది. మేము ఒక సంవత్సరం క్రితం ఉపయోగించిన కాన్ఫిగరేషన్‌ను కూడా అమలు చేయవచ్చు మరియు ఇది సరిగ్గా అదే విధంగా పని చేస్తుంది. స్థిరమైన కాన్ఫిగరేషన్ పంపిణీ చేయబడిన సిస్టమ్ యొక్క ఊహాజనిత మరియు విశ్వసనీయతను మెరుగుపరుస్తుంది. కంపైల్ సమయంలో కాన్ఫిగరేషన్ పరిష్కరించబడింది మరియు ఉత్పత్తి వ్యవస్థలో సులభంగా పాడు చేయబడదు.
9. మాడ్యులారిటీ. ప్రతిపాదిత ఫ్రేమ్‌వర్క్ మాడ్యులర్ మరియు మాడ్యూల్‌లను వివిధ మార్గాల్లో కలపవచ్చు
   విభిన్న కాన్ఫిగరేషన్‌లకు (సెటప్‌లు/లేఅవుట్‌లు) మద్దతు ఇవ్వండి. ప్రత్యేకించి, చిన్న స్కేల్ సింగిల్ నోడ్ లేఅవుట్ మరియు పెద్ద స్కేల్ మల్టీ నోడ్ సెట్టింగ్‌ని కలిగి ఉండటం సాధ్యమవుతుంది. బహుళ ఉత్పత్తి లేఅవుట్‌లను కలిగి ఉండటం సహేతుకమైనది.
10. పరీక్షిస్తోంది. పరీక్ష ప్రయోజనాల కోసం ఒకరు మాక్ సేవను అమలు చేయవచ్చు మరియు దానిని ఒక రకమైన సురక్షితమైన మార్గంలో డిపెండెన్సీగా ఉపయోగించవచ్చు. మాక్స్ ద్వారా భర్తీ చేయబడిన వివిధ భాగాలతో కొన్ని విభిన్న టెస్టింగ్ లేఅవుట్‌లను ఏకకాలంలో నిర్వహించవచ్చు.
11. ఇంటిగ్రేషన్ పరీక్ష. కొన్నిసార్లు పంపిణీ చేయబడిన సిస్టమ్‌లలో ఏకీకరణ పరీక్షలను అమలు చేయడం కష్టం. పూర్తి పంపిణీ చేయబడిన సిస్టమ్ యొక్క సురక్షిత కాన్ఫిగరేషన్‌ని టైప్ చేయడానికి వివరించిన విధానాన్ని ఉపయోగించి, మేము పంపిణీ చేయబడిన అన్ని భాగాలను ఒకే సర్వర్‌లో నియంత్రించదగిన విధంగా అమలు చేయవచ్చు. పరిస్థితిని అనుకరించడం సులభం
    సేవల్లో ఒకటి అందుబాటులో లేనప్పుడు.

ప్రతికూలతలు

కంపైల్డ్ కాన్ఫిగరేషన్ విధానం "సాధారణ" కాన్ఫిగరేషన్ నుండి భిన్నంగా ఉంటుంది మరియు ఇది అన్ని అవసరాలకు సరిపోకపోవచ్చు. సంకలనం చేయబడిన కాన్ఫిగరేషన్ యొక్క కొన్ని ప్రతికూలతలు ఇక్కడ ఉన్నాయి:

1. స్టాటిక్ కాన్ఫిగరేషన్. ఇది అన్ని అప్లికేషన్‌లకు తగినది కాకపోవచ్చు. కొన్ని సందర్భాల్లో, అన్ని భద్రతా చర్యలను దాటవేసి ఉత్పత్తిలో కాన్ఫిగరేషన్‌ను త్వరగా పరిష్కరించాల్సిన అవసరం ఉంది. ఈ విధానం మరింత కష్టతరం చేస్తుంది. కాన్ఫిగరేషన్‌లో ఏదైనా మార్పు చేసిన తర్వాత కంపైలేషన్ మరియు రీడెప్లాయ్‌మెంట్ అవసరం. ఇది లక్షణం మరియు భారం రెండూ.
2. కాన్ఫిగరేషన్ జనరేషన్. కొన్ని ఆటోమేషన్ సాధనం ద్వారా కాన్ఫిగర్ రూపొందించబడినప్పుడు ఈ విధానానికి తదుపరి సంకలనం అవసరం (ఇది విఫలం కావచ్చు). బిల్డ్ సిస్టమ్‌లో ఈ అదనపు దశను ఏకీకృతం చేయడానికి అదనపు ప్రయత్నం అవసరం కావచ్చు.
3. వాయిద్యాలు. టెక్స్ట్-ఆధారిత కాన్ఫిగరేషన్‌లపై ఆధారపడే అనేక సాధనాలు నేడు వాడుకలో ఉన్నాయి. వాళ్ళలో కొందరు
   కాన్ఫిగరేషన్ కంపైల్ చేయబడినప్పుడు వర్తించదు.
4. ఆలోచనా విధానంలో మార్పు అవసరం. డెవలపర్‌లు మరియు DevOpsకి టెక్స్ట్ కాన్ఫిగరేషన్ ఫైల్‌లు బాగా తెలుసు. కాన్ఫిగరేషన్‌ను కంపైల్ చేయాలనే ఆలోచన వారికి వింతగా అనిపించవచ్చు.
5. కంపైల్ చేయదగిన కాన్ఫిగరేషన్‌ను పరిచయం చేయడానికి ముందు అధిక నాణ్యత గల సాఫ్ట్‌వేర్ అభివృద్ధి ప్రక్రియ అవసరం.

అమలు చేయబడిన ఉదాహరణకి కొన్ని పరిమితులు ఉన్నాయి:

1. నోడ్ ఇంప్లిమెంటేషన్ ద్వారా డిమాండ్ చేయని అదనపు కాన్ఫిగరేషన్‌ను మేము అందిస్తే, ఆబ్సెంట్ ఇంప్లిమెంటేషన్‌ను గుర్తించడంలో కంపైలర్ మాకు సహాయం చేయదు. దీనిని ఉపయోగించడం ద్వారా పరిష్కరించవచ్చు HList లేదా లక్షణాలు మరియు కేక్ నమూనాకు బదులుగా నోడ్ కాన్ఫిగరేషన్ కోసం ADTలు (కేస్ క్లాసులు).
2. మేము కాన్ఫిగరేషన్ ఫైల్‌లో కొంత బాయిలర్‌ప్లేట్‌ను అందించాలి: (package, import, object ప్రకటనలు;
   override defడిఫాల్ట్ విలువలను కలిగి ఉన్న పారామితుల కోసం). ఇది DSLని ఉపయోగించి పాక్షికంగా పరిష్కరించబడవచ్చు.
3. ఈ పోస్ట్‌లో మేము సారూప్య నోడ్‌ల క్లస్టర్‌ల డైనమిక్ రీకాన్ఫిగరేషన్‌ను కవర్ చేయము.

ముగింపు

ఈ పోస్ట్‌లో మేము కాన్ఫిగరేషన్‌ను నేరుగా సోర్స్ కోడ్‌లో టైప్ సేఫ్ మార్గంలో సూచించే ఆలోచనను చర్చించాము. ఈ విధానం xml- మరియు ఇతర టెక్స్ట్-ఆధారిత కాన్ఫిగరేషన్‌లకు ప్రత్యామ్నాయంగా అనేక అప్లికేషన్‌లలో ఉపయోగించబడుతుంది. మా ఉదాహరణ స్కాలాలో అమలు చేయబడినప్పటికీ, ఇది ఇతర సంకలనం చేయదగిన భాషలకు (కోట్లిన్, C#, స్విఫ్ట్, మొదలైనవి) కూడా అనువదించబడుతుంది. ఒక కొత్త ప్రాజెక్ట్‌లో ఈ విధానాన్ని ప్రయత్నించవచ్చు మరియు అది సరిగ్గా సరిపోకపోతే, పాత పద్ధతికి మారవచ్చు.

వాస్తవానికి, కంపైల్ చేయదగిన కాన్ఫిగరేషన్‌కు అధిక నాణ్యత అభివృద్ధి ప్రక్రియ అవసరం. బదులుగా ఇది సమానంగా అధిక నాణ్యతతో కూడిన దృఢమైన కాన్ఫిగరేషన్‌ను అందజేస్తుందని వాగ్దానం చేస్తుంది.

ఈ విధానాన్ని వివిధ మార్గాల్లో విస్తరించవచ్చు:

1. కాన్ఫిగరేషన్ ధ్రువీకరణను నిర్వహించడానికి మాక్రోలను ఉపయోగించవచ్చు మరియు ఏదైనా వ్యాపార-లాజిక్ పరిమితుల వైఫల్యాల విషయంలో కంపైల్ సమయంలో విఫలమవుతుంది.
2. డొమైన్-యూజర్-ఫ్రెండ్లీ మార్గంలో కాన్ఫిగరేషన్‌ను సూచించడానికి DSL అమలు చేయబడుతుంది.
3. ఆటోమేటిక్ కాన్ఫిగరేషన్ సర్దుబాట్లతో డైనమిక్ రిసోర్స్ మేనేజ్‌మెంట్. ఉదాహరణకు, మేము క్లస్టర్ నోడ్‌ల సంఖ్యను సర్దుబాటు చేసినప్పుడు (1) నోడ్‌లు కొద్దిగా సవరించిన కాన్ఫిగరేషన్‌ను పొందాలి; (2) కొత్త నోడ్‌ల సమాచారాన్ని స్వీకరించడానికి క్లస్టర్ మేనేజర్.

ధన్యవాదాలు

ఈ పోస్ట్ యొక్క ముసాయిదాపై స్ఫూర్తిదాయకమైన అభిప్రాయాన్ని అందించినందుకు ఆండ్రీ సక్సోనోవ్, పావెల్ పోపోవ్, అంటోన్ నెహెవ్‌లకు నేను కృతజ్ఞతలు చెప్పాలనుకుంటున్నాను.

మూలం: www.habr.com