కంపైల్డ్ డిస్ట్రిబ్యూటెడ్ సిస్టమ్ కాన్ఫిగరేషన్

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

(ఇంగ్లీష్)

పరిచయం

విశ్వసనీయ పంపిణీ వ్యవస్థను నిర్మించడం అంటే అన్ని నోడ్‌లు ఇతర నోడ్‌లతో సమకాలీకరించబడిన సరైన కాన్ఫిగరేషన్‌ను ఉపయోగిస్తాయి. 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'ov. (కేక్ నమూనా ఈ విధానం యొక్క అవసరమైన అంశం కాదు. ఇది కేవలం ఒక సాధ్యం అమలు.)

సేవల మధ్య ఆధారపడటం పోర్ట్‌లను తిరిగి ఇచ్చే పద్ధతులుగా సూచించబడుతుంది 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 చిరునామా అవసరం. మిగిలిన కాన్ఫిగరేషన్ కంటే చిరునామా తర్వాత తెలిసే అవకాశం ఉంది. కాబట్టి మనకు నోడ్ IDని చిరునామాకు మ్యాప్ చేసే ఫంక్షన్ అవసరం:

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. మరియు వివిధ నోడ్‌లలో ఎకో సర్వీస్ మరియు ఎకో క్లయింట్‌ని హోస్ట్ చేస్తోంది.

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

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

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'ఓం, మరియు క్లయింట్ నోడ్ కొంత సమయం తర్వాత ముగుస్తుంది. సెం.మీ. లాంచర్ యాప్.

సాధారణ అభివృద్ధి ప్రక్రియ

ఈ కాన్ఫిగరేషన్ విధానం మొత్తం అభివృద్ధి ప్రక్రియను ఎలా ప్రభావితం చేస్తుందో చూద్దాం.

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

ఏదైనా కాన్ఫిగరేషన్ మార్పు కోడ్ మార్పుగా మారుతుంది. అందువలన, ప్రతి
మార్పు సాధారణ నాణ్యత హామీ ప్రక్రియ ద్వారా కవర్ చేయబడుతుంది:

బగ్ ట్రాకర్‌లోని టిక్కెట్ -> PR -> సమీక్ష -> సంబంధిత శాఖలతో విలీనం ->
ఏకీకరణ -> విస్తరణ

కంపైల్డ్ కాన్ఫిగరేషన్‌ను అమలు చేయడం వల్ల కలిగే ప్రధాన పరిణామాలు:

1. పంపిణీ చేయబడిన సిస్టమ్ యొక్క అన్ని నోడ్‌లలో కాన్ఫిగరేషన్ స్థిరంగా ఉంటుంది. అన్ని నోడ్‌లు ఒకే మూలం నుండి ఒకే కాన్ఫిగరేషన్‌ను పొందుతాయి అనే వాస్తవం కారణంగా.

2. నోడ్‌లలో ఒకదానిలో మాత్రమే కాన్ఫిగరేషన్‌ను మార్చడం సమస్యాత్మకం. కాబట్టి, "కాన్ఫిగరేషన్ డ్రిఫ్ట్" అసంభవం.

3. కాన్ఫిగరేషన్‌లో చిన్న మార్పులు చేయడం మరింత కష్టమవుతుంది.

4. మొత్తం అభివృద్ధి ప్రక్రియలో భాగంగా చాలా కాన్ఫిగరేషన్ మార్పులు జరుగుతాయి మరియు సమీక్షకు లోబడి ఉంటాయి.

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

సాధ్యమైన వైవిధ్యాలు

కంపైల్ చేయబడిన కాన్ఫిగరేషన్‌ను కొన్ని సాధారణ ప్రత్యామ్నాయాలతో పోల్చడానికి ప్రయత్నిద్దాం:

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

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

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

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

ప్రోగ్రామ్‌ను పునఃప్రారంభించకుండా అరుదుగా మారుతున్న పారామితులను నవీకరించాల్సిన అవసరం ఉంటే, ఇది తరచుగా ప్రోగ్రామ్ యొక్క క్లిష్టతకు దారి తీస్తుంది, ఎందుకంటే మనం ఏదో ఒకవిధంగా పారామితులను బట్వాడా చేయడం, నిల్వ చేయడం, అన్వయించడం మరియు తనిఖీ చేయడం మరియు తప్పు విలువలను ప్రాసెస్ చేయడం అవసరం. అందువల్ల, ప్రోగ్రామ్ యొక్క సంక్లిష్టతను తగ్గించే కోణం నుండి, ప్రోగ్రామ్ ఆపరేషన్ సమయంలో మార్చగల పారామితుల సంఖ్యను తగ్గించడం అర్ధమే (లేదా అలాంటి పారామితులకు మద్దతు ఇవ్వదు).

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

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

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

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

లాభాలు మరియు నష్టాలు

ప్రతిపాదిత సాంకేతికత యొక్క లాభాలు మరియు నష్టాలపై నేను నివసించాలనుకుంటున్నాను.

ప్రయోజనాలు

కంపైల్ చేయబడిన పంపిణీ చేయబడిన సిస్టమ్ కాన్ఫిగరేషన్ యొక్క ప్రధాన లక్షణాల జాబితా క్రింద ఉంది:

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

ప్రతికూలతలు మరియు పరిమితులు

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

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

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

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

తీర్మానం

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

సహజంగానే, సంకలనం చేయబడిన కాన్ఫిగరేషన్‌కు అధిక నాణ్యత అభివృద్ధి ప్రక్రియ అవసరం. బదులుగా, కాన్ఫిగరేషన్ల యొక్క అధిక నాణ్యత మరియు విశ్వసనీయత నిర్ధారించబడుతుంది.

పరిగణించబడిన విధానాన్ని విస్తరించవచ్చు:

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

రసీదులు

ముసాయిదా కథనంపై నిర్మాణాత్మక విమర్శలు చేసినందుకు ఆండ్రీ సక్సోనోవ్, పావెల్ పోపోవ్ మరియు అంటోన్ నెఖేవ్‌లకు నేను కృతజ్ఞతలు తెలుపుతున్నాను.

మూలం: www.habr.com