കംപൈൽ ചെയ്ത ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റം കോൺഫിഗറേഷൻ

വിതരണം ചെയ്ത സിസ്റ്റത്തിന്റെ കോൺഫിഗറേഷനുമായി പ്രവർത്തിക്കുന്നതിനുള്ള രസകരമായ ഒരു സംവിധാനം നിങ്ങളോട് പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. സുരക്ഷിതമായ തരങ്ങൾ ഉപയോഗിച്ച് കംപൈൽ ചെയ്ത ഭാഷയിൽ (സ്കാല) കോൺഫിഗറേഷൻ നേരിട്ട് പ്രതിനിധീകരിക്കുന്നു. ഈ പോസ്റ്റ് അത്തരമൊരു കോൺഫിഗറേഷന്റെ ഒരു ഉദാഹരണം നൽകുകയും മൊത്തത്തിലുള്ള വികസന പ്രക്രിയയിലേക്ക് ഒരു സമാഹരിച്ച കോൺഫിഗറേഷൻ നടപ്പിലാക്കുന്നതിന്റെ വിവിധ വശങ്ങൾ ചർച്ച ചെയ്യുകയും ചെയ്യുന്നു.

(ഇംഗ്ലീഷ്)

ആമുഖം

ഒരു വിശ്വസനീയമായ വിതരണ സംവിധാനം നിർമ്മിക്കുന്നത് അർത്ഥമാക്കുന്നത് എല്ലാ നോഡുകളും മറ്റ് നോഡുകളുമായി സമന്വയിപ്പിച്ച ശരിയായ കോൺഫിഗറേഷൻ ഉപയോഗിക്കുന്നു എന്നാണ്. DevOps സാങ്കേതികവിദ്യകൾ (ടെറാഫോം, അൻസിബിൾ അല്ലെങ്കിൽ അതുപോലുള്ള എന്തെങ്കിലും) സാധാരണയായി കോൺഫിഗറേഷൻ ഫയലുകൾ സ്വയമേവ സൃഷ്ടിക്കാൻ ഉപയോഗിക്കുന്നു (പലപ്പോഴും ഓരോ നോഡിനും പ്രത്യേകം). എല്ലാ ആശയവിനിമയ നോഡുകളും ഒരേ പ്രോട്ടോക്കോളുകൾ ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാനും ഞങ്ങൾ ആഗ്രഹിക്കുന്നു (ഒരേ പതിപ്പ് ഉൾപ്പെടെ). അല്ലെങ്കിൽ, പൊരുത്തക്കേട് ഞങ്ങളുടെ വിതരണ സംവിധാനത്തിൽ നിർമ്മിക്കപ്പെടും. JVM ലോകത്ത്, പ്രോട്ടോക്കോൾ സന്ദേശങ്ങൾ അടങ്ങിയ ലൈബ്രറിയുടെ അതേ പതിപ്പ് എല്ലായിടത്തും ഉപയോഗിക്കണം എന്നതാണ് ഈ ആവശ്യകതയുടെ ഒരു അനന്തരഫലം.

ഒരു വിതരണ സംവിധാനം പരിശോധിക്കുന്നതിനെക്കുറിച്ച്? തീർച്ചയായും, ഞങ്ങൾ ഇന്റഗ്രേഷൻ ടെസ്റ്റിംഗിലേക്ക് പോകുന്നതിന് മുമ്പ് എല്ലാ ഘടകങ്ങൾക്കും യൂണിറ്റ് ടെസ്റ്റുകൾ ഉണ്ടെന്ന് ഞങ്ങൾ അനുമാനിക്കുന്നു. (റൺടൈമിലേക്ക് ടെസ്റ്റ് ഫലങ്ങൾ എക്സ്ട്രാപോളേറ്റ് ചെയ്യുന്നതിന്, ടെസ്റ്റിംഗ് ഘട്ടത്തിലും റൺടൈമിലും ഞങ്ങൾ സമാനമായ ലൈബ്രറികൾ നൽകണം.)

ഇന്റഗ്രേഷൻ ടെസ്റ്റുകൾക്കൊപ്പം പ്രവർത്തിക്കുമ്പോൾ, എല്ലാ നോഡുകളിലും എല്ലായിടത്തും ഒരേ ക്ലാസ്പാത്ത് ഉപയോഗിക്കുന്നത് എളുപ്പമാണ്. റൺടൈമിൽ ഒരേ ക്ലാസ്പാത്ത് ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുകയാണ് നമ്മൾ ചെയ്യേണ്ടത്. (വ്യത്യസ്‌ത ക്ലാസ്‌പാത്തുകൾ ഉപയോഗിച്ച് വ്യത്യസ്‌ത നോഡുകൾ പ്രവർത്തിപ്പിക്കുന്നത് പൂർണ്ണമായും സാധ്യമാണെങ്കിലും, ഇത് മൊത്തത്തിലുള്ള കോൺഫിഗറേഷനിൽ സങ്കീർണ്ണതയും വിന്യാസത്തിന്റെയും ഇന്റഗ്രേഷൻ ടെസ്റ്റുകളുടെയും ബുദ്ധിമുട്ടുകൾ വർദ്ധിപ്പിക്കുന്നു.) ഈ പോസ്റ്റിന്റെ ഉദ്ദേശ്യങ്ങൾക്കായി, എല്ലാ നോഡുകളും ഒരേ ക്ലാസ്പാത്ത് ഉപയോഗിക്കുമെന്ന് ഞങ്ങൾ അനുമാനിക്കുന്നു.

ആപ്ലിക്കേഷൻ ഉപയോഗിച്ച് കോൺഫിഗറേഷൻ വികസിക്കുന്നു. പ്രോഗ്രാം പരിണാമത്തിന്റെ വിവിധ ഘട്ടങ്ങൾ തിരിച്ചറിയാൻ ഞങ്ങൾ പതിപ്പുകൾ ഉപയോഗിക്കുന്നു. കോൺഫിഗറേഷനുകളുടെ വ്യത്യസ്ത പതിപ്പുകൾ തിരിച്ചറിയുന്നതും യുക്തിസഹമാണെന്ന് തോന്നുന്നു. പതിപ്പ് നിയന്ത്രണ സംവിധാനത്തിൽ കോൺഫിഗറേഷൻ തന്നെ സ്ഥാപിക്കുക. നിർമ്മാണത്തിൽ ഒരു കോൺഫിഗറേഷൻ മാത്രമേ ഉള്ളൂ എങ്കിൽ, നമുക്ക് പതിപ്പ് നമ്പർ ഉപയോഗിക്കാം. ഞങ്ങൾ നിരവധി പ്രൊഡക്ഷൻ ഇൻസ്‌റ്റൻസുകൾ ഉപയോഗിക്കുകയാണെങ്കിൽ, നമുക്ക് പലതും വേണ്ടിവരും
കോൺഫിഗറേഷൻ ശാഖകളും പതിപ്പിന് പുറമേ ഒരു അധിക ലേബലും (ഉദാഹരണത്തിന്, ബ്രാഞ്ചിന്റെ പേര്). ഇതുവഴി നമുക്ക് കൃത്യമായ കോൺഫിഗറേഷൻ വ്യക്തമായി തിരിച്ചറിയാൻ കഴിയും. ഓരോ കോൺഫിഗറേഷൻ ഐഡന്റിഫയറും വിതരണം ചെയ്ത നോഡുകൾ, പോർട്ടുകൾ, ബാഹ്യ ഉറവിടങ്ങൾ, ലൈബ്രറി പതിപ്പുകൾ എന്നിവയുടെ ഒരു പ്രത്യേക സംയോജനവുമായി അദ്വിതീയമായി യോജിക്കുന്നു. ഈ പോസ്റ്റിന്റെ ഉദ്ദേശ്യങ്ങൾക്കായി, ഒരു ബ്രാഞ്ച് മാത്രമേ ഉള്ളൂവെന്നും ഒരു ഡോട്ട് കൊണ്ട് വേർതിരിച്ച മൂന്ന് സംഖ്യകൾ ഉപയോഗിച്ച് സാധാരണ രീതിയിൽ കോൺഫിഗറേഷൻ തിരിച്ചറിയാമെന്നും ഞങ്ങൾ അനുമാനിക്കും (1.2.3).

ആധുനിക പരിതസ്ഥിതികളിൽ, കോൺഫിഗറേഷൻ ഫയലുകൾ അപൂർവ്വമായി സ്വമേധയാ സൃഷ്ടിക്കപ്പെടുന്നു. മിക്കപ്പോഴും അവ വിന്യാസസമയത്ത് ജനറേറ്റുചെയ്യുന്നു, അവ മേലിൽ സ്പർശിക്കില്ല (അതിനാൽ ഒന്നും തകർക്കരുത്). ഒരു സ്വാഭാവിക ചോദ്യം ഉയർന്നുവരുന്നു: കോൺഫിഗറേഷൻ സംഭരിക്കുന്നതിന് ഞങ്ങൾ ഇപ്പോഴും ടെക്സ്റ്റ് ഫോർമാറ്റ് ഉപയോഗിക്കുന്നത് എന്തുകൊണ്ട്? കോൺഫിഗറേഷനും കംപൈൽ-ടൈം ചെക്കുകളിൽ നിന്നുള്ള പ്രയോജനത്തിനും റെഗുലർ കോഡ് ഉപയോഗിക്കാനുള്ള കഴിവ് ഒരു പ്രായോഗിക ബദലായി തോന്നുന്നു.

ഈ പോസ്റ്റിൽ ഒരു സമാഹരിച്ച ആർട്ടിഫാക്റ്റിനുള്ളിൽ ഒരു കോൺഫിഗറേഷനെ പ്രതിനിധീകരിക്കുന്ന ആശയം ഞങ്ങൾ പര്യവേക്ഷണം ചെയ്യും.

സമാഹരിച്ച കോൺഫിഗറേഷൻ

ഈ വിഭാഗം ഒരു സ്റ്റാറ്റിക് കംപൈൽ ചെയ്ത കോൺഫിഗറേഷന്റെ ഒരു ഉദാഹരണം നൽകുന്നു. രണ്ട് ലളിതമായ സേവനങ്ങൾ നടപ്പിലാക്കുന്നു - എക്കോ സേവനവും എക്കോ സേവന ക്ലയന്റും. ഈ രണ്ട് സേവനങ്ങളെ അടിസ്ഥാനമാക്കി, രണ്ട് സിസ്റ്റം ഓപ്ഷനുകൾ കൂട്ടിച്ചേർക്കുന്നു. ഒരു ഓപ്ഷനിൽ, രണ്ട് സേവനങ്ങളും ഒരേ നോഡിൽ സ്ഥിതിചെയ്യുന്നു, മറ്റൊരു ഓപ്ഷനിൽ - വ്യത്യസ്ത നോഡുകളിൽ.

സാധാരണയായി ഒരു വിതരണം ചെയ്ത സിസ്റ്റത്തിൽ നിരവധി നോഡുകൾ അടങ്ങിയിരിക്കുന്നു. ചില തരത്തിലുള്ള മൂല്യങ്ങൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് നോഡുകൾ തിരിച്ചറിയാൻ കഴിയും NodeId:

sealed trait NodeId
case object Backend extends NodeId
case object Frontend extends NodeId

അഥവാ

case class NodeId(hostName: String)

അല്ലെങ്കിൽ പോലും

object Singleton
type NodeId = Singleton.type

നോഡുകൾ വിവിധ റോളുകൾ ചെയ്യുന്നു, അവ സേവനങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നു, അവയ്ക്കിടയിൽ TCP/HTTP കണക്ഷനുകൾ സ്ഥാപിക്കാൻ കഴിയും.

ഒരു TCP കണക്ഷൻ വിവരിക്കുന്നതിന് ഞങ്ങൾക്ക് കുറഞ്ഞത് ഒരു പോർട്ട് നമ്പറെങ്കിലും ആവശ്യമാണ്. ക്ലയന്റും സെർവറും ഒരേ പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ ആ പോർട്ടിൽ പിന്തുണയ്ക്കുന്ന പ്രോട്ടോക്കോൾ പ്രതിഫലിപ്പിക്കാനും ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഇനിപ്പറയുന്ന ക്ലാസ് ഉപയോഗിച്ച് ഞങ്ങൾ കണക്ഷൻ വിവരിക്കും:

case class TcpEndPoint[Protocol](node: NodeId, port: Port[Protocol])

എവിടെ Port - ഒരു പൂർണ്ണസംഖ്യ Int സ്വീകാര്യമായ മൂല്യങ്ങളുടെ ശ്രേണി സൂചിപ്പിക്കുന്നു:

type PortNumber = Refined[Int, Closed[_0, W.`65535`.T]]

ശുദ്ധീകരിച്ച തരങ്ങൾ

ലൈബ്രറി കാണുക പരിഷ്‌ക്കരിച്ചു и എന്റെ റിപ്പോർട്ട്. ചുരുക്കത്തിൽ, കംപൈൽ സമയത്ത് പരിശോധിക്കുന്ന തരങ്ങളിലേക്ക് നിയന്ത്രണങ്ങൾ ചേർക്കാൻ ലൈബ്രറി നിങ്ങളെ അനുവദിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, സാധുവായ പോർട്ട് നമ്പർ മൂല്യങ്ങൾ 16-ബിറ്റ് പൂർണ്ണസംഖ്യകളാണ്. കംപൈൽ ചെയ്‌ത കോൺഫിഗറേഷനായി, ശുദ്ധീകരിച്ച ലൈബ്രറി ഉപയോഗിക്കുന്നത് നിർബന്ധമല്ല, പക്ഷേ കോൺഫിഗറേഷൻ പരിശോധിക്കാനുള്ള കമ്പൈലറിന്റെ കഴിവ് ഇത് മെച്ചപ്പെടുത്തുന്നു.

HTTP (REST) ​​പ്രോട്ടോക്കോളുകൾക്കായി, പോർട്ട് നമ്പറിന് പുറമേ, ഞങ്ങൾക്ക് സേവനത്തിലേക്കുള്ള പാതയും ആവശ്യമായി വന്നേക്കാം:

type UrlPathPrefix = Refined[String, MatchesRegex[W.`"[a-zA-Z_0-9/]*"`.T]]
case class PortWithPrefix[Protocol](portNumber: PortNumber, pathPrefix: UrlPathPrefix)

ഫാന്റം തരങ്ങൾ

കംപൈൽ സമയത്ത് പ്രോട്ടോക്കോൾ തിരിച്ചറിയാൻ, ഞങ്ങൾ ക്ലാസിൽ ഉപയോഗിക്കാത്ത ഒരു തരം പാരാമീറ്റർ ഉപയോഗിക്കുന്നു. റൺടൈമിൽ ഞങ്ങൾ ഒരു പ്രോട്ടോക്കോൾ ഇൻസ്‌റ്റൻസ് ഉപയോഗിക്കാത്തതാണ് ഈ തീരുമാനത്തിന് കാരണം, എന്നാൽ കംപൈലർ പ്രോട്ടോക്കോളുകളുടെ അനുയോജ്യത പരിശോധിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. പ്രോട്ടോക്കോൾ വ്യക്തമാക്കുന്നതിലൂടെ, അനുചിതമായ ഒരു സേവനം ആശ്രിതത്വമായി കൈമാറാൻ ഞങ്ങൾക്ക് കഴിയില്ല.

Json സീരിയലൈസേഷനോടുകൂടിയ REST API ആണ് പൊതുവായ പ്രോട്ടോക്കോളുകളിൽ ഒന്ന്:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

എവിടെ RequestMessage - അഭ്യർത്ഥന തരം, ResponseMessage - പ്രതികരണ തരം.
തീർച്ചയായും, ഞങ്ങൾക്ക് ആവശ്യമായ വിവരണത്തിന്റെ കൃത്യത നൽകുന്ന മറ്റ് പ്രോട്ടോക്കോൾ വിവരണങ്ങൾ ഉപയോഗിക്കാം.

ഈ പോസ്റ്റിന്റെ ആവശ്യങ്ങൾക്കായി, ഞങ്ങൾ പ്രോട്ടോക്കോളിന്റെ ലളിതമായ ഒരു പതിപ്പ് ഉപയോഗിക്കും:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

ഇവിടെ അഭ്യർത്ഥന url-ൽ ചേർത്തിരിക്കുന്ന ഒരു സ്ട്രിംഗ് ആണ്, പ്രതികരണം HTTP പ്രതികരണത്തിന്റെ ബോഡിയിലെ റിട്ടേൺ സ്ട്രിംഗ് ആണ്.

സേവന കോൺഫിഗറേഷൻ സേവന നാമം, പോർട്ടുകൾ, ഡിപൻഡൻസികൾ എന്നിവയാൽ വിവരിച്ചിരിക്കുന്നു. ഈ ഘടകങ്ങളെ പല തരത്തിൽ സ്കാലയിൽ പ്രതിനിധീകരിക്കാം (ഉദാഹരണത്തിന്, HList-s, ബീജഗണിത ഡാറ്റ തരങ്ങൾ). ഈ പോസ്റ്റിന്റെ ആവശ്യങ്ങൾക്കായി, ഞങ്ങൾ കേക്ക് പാറ്റേൺ ഉപയോഗിക്കുകയും മൊഡ്യൂളുകളെ പ്രതിനിധീകരിക്കുകയും ചെയ്യും traitഎസ്. (കേക്ക് പാറ്റേൺ ഈ സമീപനത്തിന്റെ ആവശ്യമായ ഘടകമല്ല. ഇത് സാധ്യമായ ഒരു നടപ്പാക്കൽ മാത്രമാണ്.)

സേവനങ്ങൾ തമ്മിലുള്ള ആശ്രിതത്വത്തെ പോർട്ടുകൾ തിരികെ നൽകുന്ന രീതികളായി പ്രതിനിധീകരിക്കാം EndPointമറ്റ് നോഡുകളുടെ:

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

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

ഒരു എക്കോ സേവനം സൃഷ്‌ടിക്കുന്നതിന്, നിങ്ങൾക്ക് വേണ്ടത് ഒരു പോർട്ട് നമ്പറും പോർട്ട് എക്കോ പ്രോട്ടോക്കോളിനെ പിന്തുണയ്ക്കുന്നു എന്നതിന്റെ സൂചനയും മാത്രമാണ്. ഞങ്ങൾ ഒരു നിർദ്ദിഷ്ട പോർട്ട് വ്യക്തമാക്കിയേക്കില്ല, കാരണം... നടപ്പിലാക്കാതെ തന്നെ രീതികൾ പ്രഖ്യാപിക്കാൻ സവിശേഷതകൾ നിങ്ങളെ അനുവദിക്കുന്നു (അമൂർത്ത രീതികൾ). ഈ സാഹചര്യത്തിൽ, ഒരു കോൺക്രീറ്റ് കോൺഫിഗറേഷൻ സൃഷ്ടിക്കുമ്പോൾ, കംപൈലർ ഞങ്ങളോട് അമൂർത്ത രീതി നടപ്പിലാക്കാനും ഒരു പോർട്ട് നമ്പർ നൽകാനും ആവശ്യപ്പെടും. ഞങ്ങൾ രീതി നടപ്പിലാക്കിയതിനാൽ, ഒരു നിർദ്ദിഷ്ട കോൺഫിഗറേഷൻ സൃഷ്ടിക്കുമ്പോൾ, ഞങ്ങൾ മറ്റൊരു പോർട്ട് വ്യക്തമാക്കിയേക്കില്ല. ഡിഫോൾട്ട് മൂല്യം ഉപയോഗിക്കും.

ക്ലയന്റ് കോൺഫിഗറേഷനിൽ ഞങ്ങൾ എക്കോ സേവനത്തെ ആശ്രയിക്കുന്നതായി പ്രഖ്യാപിക്കുന്നു:

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

കയറ്റുമതി ചെയ്ത സേവനത്തിന്റെ അതേ തരത്തിലുള്ളതാണ് ആശ്രിതത്വം echoService. പ്രത്യേകിച്ചും, എക്കോ ക്ലയന്റിലും ഞങ്ങൾക്ക് ഒരേ പ്രോട്ടോക്കോൾ ആവശ്യമാണ്. അതിനാൽ, രണ്ട് സേവനങ്ങൾ ബന്ധിപ്പിക്കുമ്പോൾ, എല്ലാം ശരിയായി പ്രവർത്തിക്കുമെന്ന് ഞങ്ങൾക്ക് ഉറപ്പിക്കാം.

സേവനങ്ങൾ നടപ്പിലാക്കൽ

സേവനം ആരംഭിക്കുന്നതിനും നിർത്തുന്നതിനും ഒരു ഫംഗ്ഷൻ ആവശ്യമാണ്. (സേവനം നിർത്താനുള്ള കഴിവ് പരിശോധനയ്ക്ക് നിർണ്ണായകമാണ്.) വീണ്ടും, അത്തരമൊരു സവിശേഷത നടപ്പിലാക്കുന്നതിന് നിരവധി ഓപ്ഷനുകൾ ഉണ്ട് (ഉദാഹരണത്തിന്, കോൺഫിഗറേഷൻ തരം അടിസ്ഥാനമാക്കി നമുക്ക് ടൈപ്പ് ക്ലാസുകൾ ഉപയോഗിക്കാം). ഈ പോസ്റ്റിന്റെ ആവശ്യങ്ങൾക്കായി, ഞങ്ങൾ കേക്ക് പാറ്റേൺ ഉപയോഗിക്കും. ഒരു ക്ലാസ് ഉപയോഗിച്ച് ഞങ്ങൾ സേവനത്തെ പ്രതിനിധീകരിക്കും cats.Resource, കാരണം പ്രശ്‌നങ്ങൾ ഉണ്ടായാൽ ഉറവിടങ്ങളുടെ റിലീസ് സുരക്ഷിതമായി ഉറപ്പുനൽകുന്നതിനുള്ള മാർഗങ്ങൾ ഈ ക്ലാസ് ഇതിനകം നൽകുന്നു. ഒരു റിസോഴ്സ് ലഭിക്കുന്നതിന്, ഞങ്ങൾ കോൺഫിഗറേഷനും ഒരു റെഡിമെയ്ഡ് റൺടൈം സന്ദർഭവും നൽകേണ്ടതുണ്ട്. സർവീസ് സ്റ്റാർട്ടപ്പ് പ്രവർത്തനം ഇതുപോലെയാകാം:

  type ResourceReader[F[_], Config, A] = Reader[Config, Resource[F, A]]

  trait ServiceImpl[F[_]] {
    type Config
    def resource(
      implicit
      resolver: AddressResolver[F],
      timer: Timer[F],
      contextShift: ContextShift[F],
      ec: ExecutionContext,
      applicative: Applicative[F]
    ): ResourceReader[F, Config, Unit]
  }

എവിടെ

• Config - ഈ സേവനത്തിനായുള്ള കോൺഫിഗറേഷൻ തരം
• AddressResolver - മറ്റ് നോഡുകളുടെ വിലാസങ്ങൾ കണ്ടെത്താൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു റൺടൈം ഒബ്‌ജക്റ്റ് (ചുവടെ കാണുക)

ലൈബ്രറിയിൽ നിന്നുള്ള മറ്റ് തരങ്ങളും cats:

• F[_] - ഇഫക്റ്റിന്റെ തരം (ലളിതമായ സാഹചര്യത്തിൽ F[A] ഒരു ചടങ്ങ് മാത്രമായിരിക്കാം () => A. ഈ പോസ്റ്റിൽ ഞങ്ങൾ ഉപയോഗിക്കും cats.IO.)
• Reader[A,B] - ഫംഗ്ഷന്റെ കൂടുതലോ കുറവോ പര്യായമായി A => B
• cats.Resource - നേടാനും റിലീസ് ചെയ്യാനും കഴിയുന്ന ഒരു വിഭവം
• Timer - ടൈമർ (കുറച്ച് സമയം ഉറങ്ങാനും സമയ ഇടവേളകൾ അളക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു)
• ContextShift - അനലോഗ് ExecutionContext
• Applicative - വ്യക്തിഗത ഇഫക്റ്റുകൾ (ഏതാണ്ട് ഒരു മൊണാഡ്) സംയോജിപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു ഇഫക്റ്റ് തരം ക്ലാസ്. കൂടുതൽ സങ്കീർണ്ണമായ ആപ്ലിക്കേഷനുകളിൽ ഇത് ഉപയോഗിക്കുന്നതാണ് നല്ലത് Monad/ConcurrentEffect.

ഈ ഫംഗ്ഷൻ സിഗ്നേച്ചർ ഉപയോഗിച്ച് നമുക്ക് നിരവധി സേവനങ്ങൾ നടപ്പിലാക്കാൻ കഴിയും. ഉദാഹരണത്തിന്, ഒന്നും ചെയ്യാത്ത ഒരു സേവനം:

  trait ZeroServiceImpl[F[_]] extends ServiceImpl[F] {
    type Config <: Any
    def resource(...): ResourceReader[F, Config, Unit] =
      Reader(_ => Resource.pure[F, Unit](()))
  }

(സെമി. ഉറവിടം, ഇതിൽ മറ്റ് സേവനങ്ങൾ നടപ്പിലാക്കുന്നു - പ്രതിധ്വനി സേവനം, എക്കോ ക്ലയന്റ്
и ആജീവനാന്ത കൺട്രോളറുകൾ.)

നിരവധി സേവനങ്ങൾ സമാരംഭിക്കാൻ കഴിയുന്ന ഒരു വസ്തുവാണ് നോഡ് (വിഭവങ്ങളുടെ ഒരു ശൃംഖലയുടെ സമാരംഭം കേക്ക് പാറ്റേൺ ഉറപ്പാക്കുന്നു):

object SingleNodeImpl extends ZeroServiceImpl[IO]
  with EchoServiceService
  with EchoClientService
  with FiniteDurationLifecycleServiceImpl
{
  type Config = EchoConfig[String] with EchoClientConfig[String] with FiniteDurationLifecycleConfig
}

ഈ നോഡിന് ആവശ്യമായ കോൺഫിഗറേഷന്റെ കൃത്യമായ തരം ഞങ്ങൾ വ്യക്തമാക്കുന്നുവെന്നത് ശ്രദ്ധിക്കുക. ഒരു പ്രത്യേക സേവനത്തിന് ആവശ്യമായ കോൺഫിഗറേഷൻ തരങ്ങളിൽ ഒന്ന് വ്യക്തമാക്കാൻ ഞങ്ങൾ മറന്നാൽ, ഒരു കംപൈലേഷൻ പിശക് ഉണ്ടാകും. കൂടാതെ, ആവശ്യമായ എല്ലാ ഡാറ്റയും ഉപയോഗിച്ച് ഉചിതമായ തരത്തിലുള്ള ചില ഒബ്‌ജക്‌റ്റുകൾ നൽകിയില്ലെങ്കിൽ ഞങ്ങൾക്ക് ഒരു നോഡ് ആരംഭിക്കാൻ കഴിയില്ല.

ഹോസ്റ്റ് നെയിം റെസല്യൂഷൻ

ഒരു റിമോട്ട് ഹോസ്റ്റിലേക്ക് കണക്റ്റുചെയ്യുന്നതിന്, ഞങ്ങൾക്ക് ഒരു യഥാർത്ഥ IP വിലാസം ആവശ്യമാണ്. ബാക്കിയുള്ള കോൺഫിഗറേഷനേക്കാൾ പിന്നീട് വിലാസം അറിയാൻ സാധ്യതയുണ്ട്. അതിനാൽ, ഒരു വിലാസത്തിലേക്ക് നോഡ് ഐഡി മാപ്പ് ചെയ്യുന്ന ഒരു ഫംഗ്ഷൻ ആവശ്യമാണ്:

case class NodeAddress[NodeId](host: Uri.Host)
trait AddressResolver[F[_]] {
  def resolve[NodeId](nodeId: NodeId): F[NodeAddress[NodeId]]
}

ഈ ഫംഗ്ഷൻ നടപ്പിലാക്കാൻ നിരവധി മാർഗങ്ങളുണ്ട്:

1. വിന്യാസത്തിന് മുമ്പ് വിലാസങ്ങൾ ഞങ്ങൾക്ക് അറിയാമെങ്കിൽ, നമുക്ക് സ്കാല കോഡ് സൃഷ്ടിക്കാൻ കഴിയും
   വിലാസങ്ങൾ തുടർന്ന് ബിൽഡ് പ്രവർത്തിപ്പിക്കുക. ഇത് കംപൈൽ ചെയ്യുകയും ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുകയും ചെയ്യും.
   ഈ സാഹചര്യത്തിൽ, ഫംഗ്ഷൻ സ്ഥിരമായി അറിയപ്പെടും കൂടാതെ കോഡിൽ ഒരു മാപ്പിംഗ് ആയി പ്രതിനിധീകരിക്കാനും കഴിയും Map[NodeId, NodeAddress].
2. ചില സന്ദർഭങ്ങളിൽ, നോഡ് ആരംഭിച്ചതിനുശേഷം മാത്രമേ യഥാർത്ഥ വിലാസം അറിയൂ.
   ഈ സാഹചര്യത്തിൽ, മറ്റ് നോഡുകൾക്ക് മുമ്പായി പ്രവർത്തിക്കുന്ന ഒരു "കണ്ടെത്തൽ സേവനം" നടപ്പിലാക്കാം, കൂടാതെ എല്ലാ നോഡുകളും ഈ സേവനത്തിൽ രജിസ്റ്റർ ചെയ്യുകയും മറ്റ് നോഡുകളുടെ വിലാസങ്ങൾ അഭ്യർത്ഥിക്കുകയും ചെയ്യും.
3. നമുക്ക് പരിഷ്കരിക്കാൻ കഴിയുമെങ്കിൽ /etc/hosts, അപ്പോൾ നിങ്ങൾക്ക് മുൻകൂട്ടി നിശ്ചയിച്ചിട്ടുള്ള ഹോസ്റ്റ്നാമങ്ങൾ ഉപയോഗിക്കാം (പോലെ my-project-main-node и echo-backend) കൂടാതെ ഈ പേരുകൾ ലിങ്ക് ചെയ്യുക
   വിന്യാസ സമയത്ത് 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"
  }

പ്രധാനം! സേവനങ്ങൾ എങ്ങനെ ബന്ധിപ്പിച്ചിരിക്കുന്നു എന്ന് ശ്രദ്ധിക്കുക. ഒരു നോഡ് നടപ്പിലാക്കിയ സേവനം മറ്റൊരു നോഡിന്റെ ഡിപൻഡൻസി രീതിയുടെ നിർവ്വഹണമായി ഞങ്ങൾ വ്യക്തമാക്കുന്നു. ഡിപൻഡൻസി തരം കംപൈലർ പരിശോധിക്കുന്നു, കാരണം പ്രോട്ടോക്കോൾ തരം അടങ്ങിയിരിക്കുന്നു. റൺ ചെയ്യുമ്പോൾ, ഡിപൻഡൻസിയിൽ ശരിയായ ടാർഗെറ്റ് നോഡ് ഐഡി അടങ്ങിയിരിക്കും. ഈ സ്കീമിന് നന്ദി, ഞങ്ങൾ പോർട്ട് നമ്പർ കൃത്യമായി ഒരു പ്രാവശ്യം വ്യക്തമാക്കുകയും ശരിയായ പോർട്ട് റഫർ ചെയ്യാൻ എപ്പോഴും ഉറപ്പുനൽകുകയും ചെയ്യുന്നു.

രണ്ട് സിസ്റ്റം നോഡുകൾ നടപ്പിലാക്കൽ

ഈ കോൺഫിഗറേഷനായി, മാറ്റങ്ങളില്ലാതെ ഞങ്ങൾ അതേ സേവന നിർവ്വഹണങ്ങൾ ഉപയോഗിക്കുന്നു. വ്യത്യസ്ത സെറ്റ് സേവനങ്ങൾ നടപ്പിലാക്കുന്ന രണ്ട് ഒബ്‌ജക്റ്റുകൾ ഇപ്പോൾ ഞങ്ങളുടെ പക്കലുണ്ട് എന്നതാണ് ഒരേയൊരു വ്യത്യാസം:

  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) സൃഷ്ടിക്കുകയും ചെയ്യും. കോൺഫിഗറേഷൻ ഒരു പ്രത്യേക ആർട്ടിഫാക്‌റ്റിൽ ഇടുന്നത് അർത്ഥമാക്കുന്നതായി തോന്നുന്നു. കാരണം ഒരേ കോഡിനെ അടിസ്ഥാനമാക്കി നമുക്ക് ഒന്നിലധികം കോൺഫിഗറേഷനുകൾ ഉണ്ടാകാം. വീണ്ടും, വ്യത്യസ്ത കോൺഫിഗറേഷൻ ശാഖകൾക്ക് അനുയോജ്യമായ പുരാവസ്തുക്കൾ സൃഷ്ടിക്കാൻ കഴിയും. ലൈബ്രറികളുടെ നിർദ്ദിഷ്ട പതിപ്പുകളെ ആശ്രയിക്കുന്നത് കോൺഫിഗറേഷനോടൊപ്പം സംരക്ഷിക്കപ്പെടുന്നു, കൂടാതെ കോൺഫിഗറേഷന്റെ ആ പതിപ്പ് വിന്യസിക്കാൻ ഞങ്ങൾ തീരുമാനിക്കുമ്പോഴെല്ലാം ഈ പതിപ്പുകൾ ശാശ്വതമായി സംരക്ഷിക്കപ്പെടും.

ഏത് കോൺഫിഗറേഷൻ മാറ്റവും ഒരു കോഡ് മാറ്റമായി മാറുന്നു. അതിനാൽ, ഓരോന്നും
സാധാരണ ഗുണമേന്മ ഉറപ്പുനൽകുന്ന പ്രക്രിയയിൽ മാറ്റം വരുത്തും:

ബഗ് ട്രാക്കറിലെ ടിക്കറ്റ് -> പിആർ -> അവലോകനം -> പ്രസക്തമായ ശാഖകളുമായി ലയിപ്പിക്കുക ->
സംയോജനം -> വിന്യാസം

കംപൈൽ ചെയ്ത കോൺഫിഗറേഷൻ നടപ്പിലാക്കുന്നതിന്റെ പ്രധാന അനന്തരഫലങ്ങൾ ഇവയാണ്:

1. വിതരണം ചെയ്ത സിസ്റ്റത്തിന്റെ എല്ലാ നോഡുകളിലും കോൺഫിഗറേഷൻ സ്ഥിരമായിരിക്കും. ഒരൊറ്റ ഉറവിടത്തിൽ നിന്ന് എല്ലാ നോഡുകളും ഒരേ കോൺഫിഗറേഷൻ സ്വീകരിക്കുന്ന വസ്തുത കാരണം.

2. ഒരു നോഡിൽ മാത്രം കോൺഫിഗറേഷൻ മാറ്റുന്നത് പ്രശ്നമാണ്. അതിനാൽ, "കോൺഫിഗറേഷൻ ഡ്രിഫ്റ്റ്" സാധ്യതയില്ല.

3. കോൺഫിഗറേഷനിൽ ചെറിയ മാറ്റങ്ങൾ വരുത്തുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാണ്.

4. മൊത്തത്തിലുള്ള വികസന പ്രക്രിയയുടെ ഭാഗമായി മിക്ക കോൺഫിഗറേഷൻ മാറ്റങ്ങളും സംഭവിക്കുകയും അവലോകനത്തിന് വിധേയമാക്കുകയും ചെയ്യും.

പ്രൊഡക്ഷൻ കോൺഫിഗറേഷൻ സംഭരിക്കുന്നതിന് എനിക്ക് ഒരു പ്രത്യേക ശേഖരം ആവശ്യമുണ്ടോ? ഈ കോൺഫിഗറേഷനിൽ പാസ്‌വേഡുകളും മറ്റ് സെൻസിറ്റീവ് വിവരങ്ങളും അടങ്ങിയിരിക്കാം, അതിലേക്ക് ഞങ്ങൾ ആക്‌സസ്സ് നിയന്ത്രിക്കാൻ ആഗ്രഹിക്കുന്നു. ഇതിന്റെ അടിസ്ഥാനത്തിൽ, അന്തിമ കോൺഫിഗറേഷൻ ഒരു പ്രത്യേക റിപ്പോസിറ്ററിയിൽ സംഭരിക്കുന്നതിൽ അർത്ഥമുണ്ടെന്ന് തോന്നുന്നു. നിങ്ങൾക്ക് കോൺഫിഗറേഷനെ രണ്ട് ഭാഗങ്ങളായി വിഭജിക്കാം-ഒന്ന് പൊതുവായി ആക്‌സസ് ചെയ്യാവുന്ന കോൺഫിഗറേഷൻ ക്രമീകരണങ്ങളും ഒന്ന് നിയന്ത്രിത ക്രമീകരണങ്ങളും ഉൾക്കൊള്ളുന്നു. ഇത് മിക്ക ഡെവലപ്പർമാരെയും പൊതുവായ ക്രമീകരണങ്ങളിലേക്ക് ആക്‌സസ് ചെയ്യാൻ അനുവദിക്കും. ഡിഫോൾട്ട് മൂല്യങ്ങൾ അടങ്ങിയ ഇന്റർമീഡിയറ്റ് സ്വഭാവവിശേഷങ്ങൾ ഉപയോഗിച്ച് ഈ വേർതിരിവ് നേടാൻ എളുപ്പമാണ്.

സാധ്യമായ വ്യതിയാനങ്ങൾ

കംപൈൽ ചെയ്‌ത കോൺഫിഗറേഷനെ ചില പൊതു ബദലുകളുമായി താരതമ്യം ചെയ്യാൻ ശ്രമിക്കാം:

1. ടാർഗെറ്റ് മെഷീനിൽ ടെക്സ്റ്റ് ഫയൽ.
2. കേന്ദ്രീകൃത കീ-മൂല്യം സ്റ്റോർ (etcd/zookeeper).
3. പ്രോസസ്സ് പുനരാരംഭിക്കാതെ തന്നെ വീണ്ടും കോൺഫിഗർ ചെയ്യാനോ/പുനരാരംഭിക്കാനോ കഴിയുന്ന പ്രോസസ് ഘടകങ്ങൾ.
4. ആർട്ടിഫാക്‌റ്റിനും പതിപ്പ് നിയന്ത്രണത്തിനും പുറത്ത് കോൺഫിഗറേഷൻ സംഭരിക്കുന്നു.

ചെറിയ മാറ്റങ്ങളുടെ കാര്യത്തിൽ ടെക്സ്റ്റ് ഫയലുകൾ കാര്യമായ വഴക്കം നൽകുന്നു. സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർക്ക് റിമോട്ട് നോഡിലേക്ക് ലോഗിൻ ചെയ്യാനും ഉചിതമായ ഫയലുകളിൽ മാറ്റങ്ങൾ വരുത്താനും സേവനം പുനരാരംഭിക്കാനും കഴിയും. എന്നിരുന്നാലും, വലിയ സിസ്റ്റങ്ങൾക്ക്, അത്തരം വഴക്കം അഭികാമ്യമായിരിക്കില്ല. വരുത്തിയ മാറ്റങ്ങൾ മറ്റ് സിസ്റ്റങ്ങളിൽ യാതൊരു അടയാളങ്ങളും അവശേഷിപ്പിക്കുന്നില്ല. മാറ്റങ്ങളെ ആരും അവലോകനം ചെയ്യുന്നില്ല. ആരാണ് കൃത്യമായി മാറ്റങ്ങൾ വരുത്തിയതെന്നും എന്ത് കാരണത്താലാണ് എന്ന് നിർണ്ണയിക്കാൻ പ്രയാസമാണ്. മാറ്റങ്ങൾ പരീക്ഷിച്ചിട്ടില്ല. സിസ്റ്റം വിതരണം ചെയ്യുകയാണെങ്കിൽ, മറ്റ് നോഡുകളിൽ അനുബന്ധ മാറ്റം വരുത്താൻ അഡ്മിനിസ്ട്രേറ്റർ മറന്നേക്കാം.

(കംപൈൽ ചെയ്‌ത കോൺഫിഗറേഷൻ ഉപയോഗിക്കുന്നത് ഭാവിയിൽ ടെക്‌സ്‌റ്റ് ഫയലുകൾ ഉപയോഗിക്കാനുള്ള സാധ്യതയെ ഇല്ലാതാക്കില്ല എന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്. ഔട്ട്‌പുട്ടിന്റെ അതേ തരത്തിലുള്ള ഒരു പാഴ്‌സറും വാലിഡേറ്ററും ചേർത്താൽ മതിയാകും. Config, കൂടാതെ നിങ്ങൾക്ക് ടെക്സ്റ്റ് ഫയലുകൾ ഉപയോഗിക്കാം. കംപൈൽ ചെയ്‌ത കോൺഫിഗറേഷനുള്ള ഒരു സിസ്റ്റത്തിന്റെ സങ്കീർണ്ണത ടെക്‌സ്‌റ്റ് ഫയലുകൾ ഉപയോഗിക്കുന്ന ഒരു സിസ്റ്റത്തിന്റെ സങ്കീർണ്ണതയേക്കാൾ അൽപ്പം കുറവാണെന്ന് ഇത് ഉടനടി പിന്തുടരുന്നു, കാരണം ടെക്സ്റ്റ് ഫയലുകൾക്ക് അധിക കോഡ് ആവശ്യമാണ്.)

ഒരു ഡിസ്ട്രിബ്യൂഡ് ആപ്ലിക്കേഷന്റെ മെറ്റാ പാരാമീറ്ററുകൾ വിതരണം ചെയ്യുന്നതിനുള്ള നല്ലൊരു സംവിധാനമാണ് കേന്ദ്രീകൃത കീ-വാല്യൂ സ്റ്റോർ. കോൺഫിഗറേഷൻ പാരാമീറ്ററുകൾ എന്താണെന്നും വെറും ഡാറ്റ എന്താണെന്നും നമ്മൾ തീരുമാനിക്കേണ്ടതുണ്ട്. നമുക്ക് ഒരു ഫംഗ്ഷൻ നടത്താം C => A => B, കൂടാതെ പാരാമീറ്ററുകൾ C അപൂർവ്വമായി മാറ്റങ്ങളും ഡാറ്റയും A - പലപ്പോഴും. ഈ സാഹചര്യത്തിൽ നമുക്ക് പറയാം C - കോൺഫിഗറേഷൻ പാരാമീറ്ററുകൾ, കൂടാതെ A - ഡാറ്റ. കോൺഫിഗറേഷൻ പാരാമീറ്ററുകൾ ഡാറ്റയിൽ നിന്ന് വ്യത്യസ്തമാണെന്ന് തോന്നുന്നു, അവ സാധാരണയായി ഡാറ്റയേക്കാൾ കുറച്ച് തവണ മാത്രമേ മാറുന്നുള്ളൂ. കൂടാതെ, ഡാറ്റ സാധാരണയായി ഒരു ഉറവിടത്തിൽ നിന്നും (ഉപയോക്താവിൽ നിന്നും), കോൺഫിഗറേഷൻ പാരാമീറ്ററുകൾ മറ്റൊന്നിൽ നിന്നും (സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്ററിൽ നിന്നും) വരുന്നു.

പ്രോഗ്രാം പുനരാരംഭിക്കാതെ തന്നെ അപൂർവ്വമായി മാറുന്ന പാരാമീറ്ററുകൾ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടതുണ്ടെങ്കിൽ, ഇത് പലപ്പോഴും പ്രോഗ്രാമിന്റെ സങ്കീർണ്ണതയിലേക്ക് നയിച്ചേക്കാം, കാരണം നമുക്ക് എങ്ങനെയെങ്കിലും പാരാമീറ്ററുകൾ നൽകുകയും സംഭരിക്കുകയും പാഴ്‌സ് ചെയ്യുകയും പരിശോധിക്കുകയും തെറ്റായ മൂല്യങ്ങൾ പ്രോസസ്സ് ചെയ്യുകയും വേണം. അതിനാൽ, പ്രോഗ്രാമിന്റെ സങ്കീർണ്ണത കുറയ്ക്കുന്നതിനുള്ള വീക്ഷണകോണിൽ നിന്ന്, പ്രോഗ്രാം ഓപ്പറേഷൻ സമയത്ത് മാറ്റാൻ കഴിയുന്ന പാരാമീറ്ററുകളുടെ എണ്ണം കുറയ്ക്കുന്നതിന് അർത്ഥമുണ്ട് (അല്ലെങ്കിൽ അത്തരം പാരാമീറ്ററുകളെ പിന്തുണയ്ക്കുന്നില്ല).

ഈ പോസ്റ്റിന്റെ ഉദ്ദേശ്യങ്ങൾക്കായി, ഞങ്ങൾ സ്റ്റാറ്റിക്, ഡൈനാമിക് പാരാമീറ്ററുകൾ തമ്മിൽ വേർതിരിക്കും. പ്രോഗ്രാമിന്റെ പ്രവർത്തന സമയത്ത് സേവനത്തിന്റെ യുക്തിക്ക് പരാമീറ്ററുകൾ മാറ്റണമെങ്കിൽ, അത്തരം പാരാമീറ്ററുകളെ ഞങ്ങൾ ഡൈനാമിക് എന്ന് വിളിക്കും. അല്ലെങ്കിൽ ഓപ്‌ഷനുകൾ സ്റ്റാറ്റിക് ആയതിനാൽ കംപൈൽ ചെയ്‌ത കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്യാവുന്നതാണ്. ഡൈനാമിക് റീകോൺഫിഗറേഷനായി, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം പ്രോസസ്സുകൾ എങ്ങനെ പുനരാരംഭിക്കുന്നു എന്നതിന് സമാനമായി, പുതിയ പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് പ്രോഗ്രാമിന്റെ ഭാഗങ്ങൾ പുനരാരംഭിക്കുന്നതിന് ഞങ്ങൾക്ക് ഒരു സംവിധാനം ആവശ്യമായി വന്നേക്കാം. (ഞങ്ങളുടെ അഭിപ്രായത്തിൽ, തത്സമയ പുനർക്രമീകരണം ഒഴിവാക്കുന്നതാണ് ഉചിതം, കാരണം ഇത് സിസ്റ്റത്തിന്റെ സങ്കീർണ്ണത വർദ്ധിപ്പിക്കുന്നു. സാധ്യമെങ്കിൽ, പ്രോസസ്സുകൾ പുനരാരംഭിക്കുന്നതിന് സ്റ്റാൻഡേർഡ് ഒഎസ് കഴിവുകൾ ഉപയോഗിക്കുന്നതാണ് നല്ലത്.)

സ്റ്റാറ്റിക് കോൺഫിഗറേഷൻ ഉപയോഗിക്കുന്നതിന്റെ ഒരു പ്രധാന വശം, ഒരു കോൺഫിഗറേഷൻ അപ്‌ഡേറ്റിന് ശേഷം സിസ്റ്റം റീബൂട്ട് ചെയ്യാൻ എടുക്കുന്ന സമയമാണ് (ഡൗൺടൈം). വാസ്തവത്തിൽ, സ്റ്റാറ്റിക് കോൺഫിഗറേഷനിൽ മാറ്റങ്ങൾ വരുത്തണമെങ്കിൽ, പുതിയ മൂല്യങ്ങൾ പ്രാബല്യത്തിൽ വരുന്നതിന് ഞങ്ങൾ സിസ്റ്റം പുനരാരംഭിക്കേണ്ടതുണ്ട്. പ്രവർത്തനരഹിതമായ പ്രശ്‌നം വ്യത്യസ്ത സിസ്റ്റങ്ങളുടെ തീവ്രതയിൽ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു. ചില സാഹചര്യങ്ങളിൽ, ലോഡ് കുറവുള്ള സമയത്ത് നിങ്ങൾക്ക് ഒരു റീബൂട്ട് ഷെഡ്യൂൾ ചെയ്യാം. നിങ്ങൾക്ക് തുടർച്ചയായ സേവനം നൽകണമെങ്കിൽ, നിങ്ങൾക്ക് നടപ്പിലാക്കാം AWS ELB കണക്ഷൻ വറ്റിപ്പോകുന്നു. അതേ സമയം, നമുക്ക് സിസ്റ്റം റീബൂട്ട് ചെയ്യേണ്ടിവരുമ്പോൾ, ഞങ്ങൾ ഈ സിസ്റ്റത്തിന്റെ ഒരു സമാന്തര ഉദാഹരണം സമാരംഭിക്കുകയും ബാലൻസറിനെ അതിലേക്ക് മാറ്റുകയും പഴയ കണക്ഷനുകൾ പൂർത്തിയാകുന്നതുവരെ കാത്തിരിക്കുകയും ചെയ്യുന്നു. എല്ലാ പഴയ കണക്ഷനുകളും അവസാനിപ്പിച്ചതിന് ശേഷം, ഞങ്ങൾ സിസ്റ്റത്തിന്റെ പഴയ ഉദാഹരണം അടച്ചുപൂട്ടുന്നു.

ആർട്ടിഫാക്റ്റിനുള്ളിലോ പുറത്തോ കോൺഫിഗറേഷൻ സംഭരിക്കുന്നതിനുള്ള പ്രശ്നം നമുക്ക് ഇപ്പോൾ പരിഗണിക്കാം. ഒരു ആർട്ടിഫാക്‌റ്റിനുള്ളിൽ ഞങ്ങൾ കോൺഫിഗറേഷൻ സൂക്ഷിക്കുകയാണെങ്കിൽ, ആർട്ടിഫാക്‌റ്റിന്റെ അസംബ്ലി സമയത്ത് കോൺഫിഗറേഷന്റെ കൃത്യത പരിശോധിക്കാനുള്ള അവസരമെങ്കിലും ഞങ്ങൾക്ക് ലഭിച്ചു. കോൺഫിഗറേഷൻ നിയന്ത്രിത ആർട്ടിഫാക്‌റ്റിന് പുറത്താണെങ്കിൽ, ആരാണ് ഈ ഫയലിൽ മാറ്റങ്ങൾ വരുത്തിയതെന്നും എന്തുകൊണ്ടാണെന്നും ട്രാക്ക് ചെയ്യുന്നത് ബുദ്ധിമുട്ടാണ്. അത് എത്ര പ്രധാനമാണ്? ഞങ്ങളുടെ അഭിപ്രായത്തിൽ, പല പ്രൊഡക്ഷൻ സിസ്റ്റങ്ങൾക്കും സുസ്ഥിരവും ഉയർന്ന നിലവാരമുള്ളതുമായ കോൺഫിഗറേഷൻ ഉണ്ടായിരിക്കേണ്ടത് പ്രധാനമാണ്.

ഒരു ആർട്ടിഫാക്‌റ്റിന്റെ പതിപ്പ് അത് എപ്പോൾ സൃഷ്‌ടിച്ചു, അതിൽ എന്ത് മൂല്യങ്ങൾ അടങ്ങിയിരിക്കുന്നു, ഏതൊക്കെ ഫംഗ്‌ഷനുകൾ പ്രവർത്തനക്ഷമമാക്കി/അപ്രാപ്‌തമാക്കി, കോൺഫിഗറേഷനിലെ എന്തെങ്കിലും മാറ്റത്തിന് ആരാണ് ഉത്തരവാദികൾ എന്നിവ നിർണ്ണയിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. തീർച്ചയായും, ഒരു ആർട്ടിഫാക്‌റ്റിനുള്ളിൽ കോൺഫിഗറേഷൻ സംഭരിക്കുന്നതിന് കുറച്ച് പരിശ്രമം ആവശ്യമാണ്, അതിനാൽ നിങ്ങൾ അറിവുള്ള ഒരു തീരുമാനം എടുക്കേണ്ടതുണ്ട്.

പ്രോസ് ആൻഡ് കോൻസ്

നിർദ്ദിഷ്ട സാങ്കേതികവിദ്യയുടെ ഗുണദോഷങ്ങളിൽ ഞാൻ താമസിക്കാൻ ആഗ്രഹിക്കുന്നു.

ഗുണങ്ങളുമുണ്ട്

കംപൈൽ ചെയ്ത വിതരണ സിസ്റ്റം കോൺഫിഗറേഷന്റെ പ്രധാന സവിശേഷതകളുടെ ഒരു ലിസ്റ്റ് ചുവടെയുണ്ട്:

1. സ്റ്റാറ്റിക് കോൺഫിഗറേഷൻ പരിശോധന. അത് ഉറപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു
   കോൺഫിഗറേഷൻ ശരിയാണ്.
2. സമ്പന്നമായ കോൺഫിഗറേഷൻ ഭാഷ. സാധാരണഗതിയിൽ, മറ്റ് കോൺഫിഗറേഷൻ രീതികൾ പരമാവധി സ്ട്രിംഗ് വേരിയബിൾ സബ്സ്റ്റിറ്റ്യൂഷനിലേക്ക് പരിമിതപ്പെടുത്തിയിരിക്കുന്നു. Scala ഉപയോഗിക്കുമ്പോൾ, നിങ്ങളുടെ കോൺഫിഗറേഷൻ മെച്ചപ്പെടുത്തുന്നതിന് വിപുലമായ ഭാഷാ സവിശേഷതകൾ ലഭ്യമാണ്. ഉദാഹരണത്തിന് നമുക്ക് ഉപയോഗിക്കാം
   ഡിഫോൾട്ട് മൂല്യങ്ങൾക്കുള്ള സ്വഭാവവിശേഷതകൾ, ഗ്രൂപ്പ് പാരാമീറ്ററുകളിലേക്ക് ഒബ്‌ജക്‌റ്റുകൾ ഉപയോഗിച്ച്, എൻക്ലോസിംഗ് സ്കോപ്പിൽ ഒരിക്കൽ മാത്രം (DRY) പ്രഖ്യാപിച്ച വാലുകളെ നമുക്ക് പരാമർശിക്കാം. നിങ്ങൾക്ക് കോൺഫിഗറേഷനിൽ നേരിട്ട് ഏത് ക്ലാസുകളും തൽക്ഷണം ചെയ്യാം (Seq, Map, ഇഷ്‌ടാനുസൃത ക്ലാസുകൾ).
3. ഡിഎസ്എൽ. ഒരു 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 അല്ലെങ്കിൽ ടെക്സ്റ്റ് ഫയലുകൾ അടിസ്ഥാനമാക്കിയുള്ള പരമ്പരാഗത കോൺഫിഗറേഷൻ രീതികൾക്ക് പകരമായി ഈ സമീപനം വിവിധ ആപ്ലിക്കേഷനുകളിൽ ഉപയോഗിക്കാം. ഞങ്ങളുടെ ഉദാഹരണം സ്കാലയിൽ നടപ്പിലാക്കിയെങ്കിലും, അതേ ആശയങ്ങൾ സമാഹരിച്ച മറ്റ് ഭാഷകളിലേക്ക് (കോട്ലിൻ, സി#, സ്വിഫ്റ്റ്, ...) കൈമാറാൻ കഴിയും. ഇനിപ്പറയുന്ന പ്രോജക്റ്റുകളിൽ ഒന്നിൽ നിങ്ങൾക്ക് ഈ സമീപനം പരീക്ഷിക്കാവുന്നതാണ്, അത് പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, നഷ്ടപ്പെട്ട ഭാഗങ്ങൾ ചേർത്ത് ടെക്സ്റ്റ് ഫയലിലേക്ക് പോകുക.

സ്വാഭാവികമായും, ഒരു കംപൈൽ ചെയ്ത കോൺഫിഗറേഷന് ഉയർന്ന നിലവാരമുള്ള വികസന പ്രക്രിയ ആവശ്യമാണ്. പകരമായി, കോൺഫിഗറേഷനുകളുടെ ഉയർന്ന നിലവാരവും വിശ്വാസ്യതയും ഉറപ്പാക്കുന്നു.

പരിഗണിക്കുന്ന സമീപനം വിപുലീകരിക്കാൻ കഴിയും:

1. കംപൈൽ-ടൈം ചെക്കുകൾ നടത്താൻ നിങ്ങൾക്ക് മാക്രോകൾ ഉപയോഗിക്കാം.
2. അന്തിമ ഉപയോക്താക്കൾക്ക് ആക്സസ് ചെയ്യാവുന്ന രീതിയിൽ കോൺഫിഗറേഷൻ അവതരിപ്പിക്കാൻ നിങ്ങൾക്ക് ഒരു DSL നടപ്പിലാക്കാൻ കഴിയും.
3. ഓട്ടോമാറ്റിക് കോൺഫിഗറേഷൻ ക്രമീകരണം ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഡൈനാമിക് റിസോഴ്സ് മാനേജ്മെന്റ് നടപ്പിലാക്കാൻ കഴിയും. ഉദാഹരണത്തിന്, ഒരു ക്ലസ്റ്ററിലെ നോഡുകളുടെ എണ്ണം മാറ്റുന്നതിന് (1) ഓരോ നോഡിനും അല്പം വ്യത്യസ്തമായ കോൺഫിഗറേഷൻ ലഭിക്കേണ്ടതുണ്ട്; (2) പുതിയ നോഡുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ ക്ലസ്റ്റർ മാനേജർക്ക് ലഭിച്ചു.

അംഗീകാരങ്ങൾ

ഡ്രാഫ്റ്റ് ലേഖനത്തെ ക്രിയാത്മകമായി വിമർശിച്ചതിന് ആൻഡ്രി സാക്‌സോനോവ്, പവൽ പോപോവ്, ആന്റൺ നെഖേവ് എന്നിവരോട് നന്ദി പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

അവലംബം: www.habr.com