ഒരു വിതരണം ചെയ്ത സിസ്റ്റത്തിന്റെ കംപൈൽ ചെയ്യാവുന്ന കോൺഫിഗറേഷൻ

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

(റഷ്യൻ ഭാഷയിൽ)

അവതാരിക

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

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

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

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

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

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

കംപൈൽ ചെയ്യാവുന്ന കോൺഫിഗറേഷൻ

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

ഒരു സാധാരണ വിതരണ സംവിധാനം ഏതാനും നോഡുകൾ ഉൾക്കൊള്ളുന്നു. ചില തരം ഉപയോഗിച്ച് നോഡുകൾ തിരിച്ചറിയാൻ കഴിയും:

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

അല്ലെങ്കിൽ വെറുതെ

case class NodeId(hostName: String)

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

object Singleton
type NodeId = Singleton.type

ഈ നോഡുകൾ വിവിധ റോളുകൾ ചെയ്യുന്നു, ചില സേവനങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നു, കൂടാതെ TCP/HTTP കണക്ഷനുകൾ വഴി മറ്റ് നോഡുകളുമായി ആശയവിനിമയം നടത്താൻ കഴിയണം.

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

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

എവിടെ Port വെറും ഒരു ആണ് Int അനുവദനീയമായ പരിധിക്കുള്ളിൽ:

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

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

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

HTTP (REST) ​​നായി ഞങ്ങൾക്ക് സേവനത്തിന്റെ ഒരു പാതയും ആവശ്യമായി വന്നേക്കാം:

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

ഫാന്റം തരം

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

ഏറ്റവും വ്യാപകമായി ഉപയോഗിക്കുന്ന പ്രോട്ടോക്കോളുകളിൽ ഒന്നാണ് Json സീരിയലൈസേഷനോടുകൂടിയ REST API:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

എവിടെ RequestMessage സെർവറിലേക്കും ക്ലയന്റിലേക്കും അയയ്‌ക്കാനാകുന്ന സന്ദേശങ്ങളുടെ അടിസ്ഥാന തരമാണ് ResponseMessage സെർവറിൽ നിന്നുള്ള പ്രതികരണ സന്ദേശമാണ്. തീർച്ചയായും, ആശയവിനിമയ പ്രോട്ടോക്കോൾ ആവശ്യമുള്ള കൃത്യതയോടെ വ്യക്തമാക്കുന്ന മറ്റ് പ്രോട്ടോക്കോൾ വിവരണങ്ങൾ ഞങ്ങൾ സൃഷ്ടിച്ചേക്കാം.

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

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

ഈ പ്രോട്ടോക്കോളിൽ അഭ്യർത്ഥന സന്ദേശം url-ലേക്ക് കൂട്ടിച്ചേർക്കുകയും പ്രതികരണ സന്ദേശം പ്ലെയിൻ സ്ട്രിംഗായി നൽകുകയും ചെയ്യുന്നു.

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

മറ്റ് നോഡുകളുടെ അവസാന പോയിന്റുകളായി കേക്ക് പാറ്റേൺ ഉപയോഗിച്ച് ആശ്രിതത്വങ്ങളെ പ്രതിനിധീകരിക്കാം:

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

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

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

എക്കോ സർവീസ് ക്ലയന്റ് കോൺഫിഗറേഷനിൽ ഞങ്ങൾക്ക് ഒരു ഡിപൻഡൻസി പ്രഖ്യാപിക്കാം:

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

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

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

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

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

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

എവിടെ

• Config — ഈ സർവീസ് സ്റ്റാർട്ടറിന് ആവശ്യമായ കോൺഫിഗറേഷൻ തരം
• AddressResolver - മറ്റ് നോഡുകളുടെ യഥാർത്ഥ വിലാസങ്ങൾ നേടാനുള്ള കഴിവുള്ള ഒരു റൺടൈം ഒബ്‌ജക്റ്റ് (വിശദാംശങ്ങൾക്ക് വായന തുടരുക).

മറ്റ് തരങ്ങൾ വരുന്നത് cats:

• F[_] - ഇഫക്റ്റ് തരം (ഏറ്റവും ലളിതമായ സാഹചര്യത്തിൽ F[A] ന്യായമായേക്കാം () => A. ഈ പോസ്റ്റിൽ ഞങ്ങൾ ഉപയോഗിക്കും cats.IO.)
• Reader[A,B] — ഒരു ഫംഗ്ഷന്റെ കൂടുതലോ കുറവോ പര്യായപദമാണ് A => B
• cats.Resource — ഏറ്റെടുക്കാനും റിലീസ് ചെയ്യാനും വഴികളുണ്ട്
• Timer - ഉറങ്ങാൻ / സമയം അളക്കാൻ അനുവദിക്കുന്നു
• ContextShift - അനലോഗ് 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) വിന്യാസ സമയത്ത് ഈ പേര് ഐപി വിലാസവുമായി ബന്ധപ്പെടുത്തുക.

ഈ പോസ്റ്റിൽ ഞങ്ങൾ ഈ കേസുകൾ കൂടുതൽ വിശദമായി ഉൾക്കൊള്ളുന്നില്ല. വാസ്തവത്തിൽ ഞങ്ങളുടെ കളിപ്പാട്ട ഉദാഹരണത്തിൽ എല്ലാ നോഡുകൾക്കും ഒരേ ഐപി വിലാസം ഉണ്ടായിരിക്കും - 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 ഇടവേള കടന്നുപോകുന്നു.

രണ്ട് വ്യത്യസ്ത നോഡുകളുള്ള ഒരു സിസ്റ്റത്തിന്റെ ലേഔട്ട് സൃഷ്ടിക്കാൻ ഒരേ സെറ്റ് സേവന നിർവ്വഹണങ്ങളും കോൺഫിഗറേഷനുകളും ഉപയോഗിക്കാം. നമ്മൾ ഉണ്ടാക്കിയാൽ മതി രണ്ട് വ്യത്യസ്ത നോഡ് കോൺഫിഗറേഷനുകൾ ഉചിതമായ സേവനങ്ങൾക്കൊപ്പം:

രണ്ട് നോഡുകൾ കോൺഫിഗറേഷൻ

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

സഹടപിക്കാനും

സമാഹരിച്ച കോൺഫിഗറേഷൻ സമീപനം "സാധാരണ" കോൺഫിഗറേഷനിൽ നിന്ന് വ്യത്യസ്തമാണ്, അത് എല്ലാ ആവശ്യങ്ങൾക്കും അനുയോജ്യമല്ലായിരിക്കാം. സമാഹരിച്ച കോൺഫിഗറേഷന്റെ ചില പോരായ്മകൾ ഇതാ:

1. സ്റ്റാറ്റിക് കോൺഫിഗറേഷൻ. ഇത് എല്ലാ ആപ്ലിക്കേഷനുകൾക്കും അനുയോജ്യമല്ലായിരിക്കാം. ചില സാഹചര്യങ്ങളിൽ, എല്ലാ സുരക്ഷാ നടപടികളും മറികടന്ന് ഉൽപ്പാദനത്തിലെ കോൺഫിഗറേഷൻ വേഗത്തിൽ പരിഹരിക്കേണ്ടത് ആവശ്യമാണ്. ഈ സമീപനം കൂടുതൽ ബുദ്ധിമുട്ടാക്കുന്നു. കോൺഫിഗറേഷനിൽ എന്തെങ്കിലും മാറ്റം വരുത്തിയതിന് ശേഷം സമാഹരണവും പുനർവിന്യാസവും ആവശ്യമാണ്. ഇതാണ് സവിശേഷതയും ഭാരവും.
2. കോൺഫിഗറേഷൻ ജനറേഷൻ. ചില ഓട്ടോമേഷൻ ടൂൾ ഉപയോഗിച്ച് കോൺഫിഗേഷൻ സൃഷ്ടിക്കുമ്പോൾ, ഈ സമീപനത്തിന് തുടർന്നുള്ള സമാഹാരം ആവശ്യമാണ് (അത് പരാജയപ്പെടാം). ബിൽഡ് സിസ്റ്റത്തിലേക്ക് ഈ അധിക ഘട്ടം സമന്വയിപ്പിക്കുന്നതിന് അധിക പരിശ്രമം ആവശ്യമായി വന്നേക്കാം.
3. ഉപകരണങ്ങൾ. ടെക്സ്റ്റ് അധിഷ്ഠിത കോൺഫിഗറുകളെ ആശ്രയിക്കുന്ന ധാരാളം ടൂളുകൾ ഇന്ന് ഉപയോഗത്തിലുണ്ട്. അവയിൽ ചിലത്
   കോൺഫിഗറേഷൻ കംപൈൽ ചെയ്യുമ്പോൾ ബാധകമാകില്ല.
4. ചിന്താഗതിയിൽ ഒരു മാറ്റം ആവശ്യമാണ്. ഡെവലപ്പർമാർക്കും DevOps-നും ടെക്സ്റ്റ് കോൺഫിഗറേഷൻ ഫയലുകൾ പരിചിതമാണ്. കോൺഫിഗറേഷൻ കംപൈൽ ചെയ്യുക എന്ന ആശയം അവർക്ക് വിചിത്രമായി തോന്നിയേക്കാം.
5. കംപൈൽ ചെയ്യാവുന്ന കോൺഫിഗറേഷൻ അവതരിപ്പിക്കുന്നതിന് മുമ്പ് ഉയർന്ന നിലവാരമുള്ള സോഫ്റ്റ്‌വെയർ വികസന പ്രക്രിയ ആവശ്യമാണ്.

നടപ്പിലാക്കിയ ഉദാഹരണത്തിന് ചില പരിമിതികളുണ്ട്:

1. നോഡ് ഇംപ്ലിമെന്റേഷൻ ആവശ്യപ്പെടാത്ത അധിക കോൺഫിഗറേഷൻ ഞങ്ങൾ നൽകിയാൽ, ഹാജർ ഇംപ്ലിമെന്റേഷൻ കണ്ടെത്താൻ കംപൈലർ ഞങ്ങളെ സഹായിക്കില്ല. ഉപയോഗിച്ച് ഇത് പരിഹരിക്കാവുന്നതാണ് HList അല്ലെങ്കിൽ സ്വഭാവസവിശേഷതകൾക്കും കേക്ക് പാറ്റേണിനും പകരം നോഡ് കോൺഫിഗറേഷനായി ADT-കൾ (കേസ് ക്ലാസുകൾ).
2. കോൺഫിഗറേഷൻ ഫയലിൽ ഞങ്ങൾ കുറച്ച് ബോയിലർ പ്ലേറ്റ് നൽകണം: (package, import, object പ്രഖ്യാപനങ്ങൾ;
   override defസ്ഥിര മൂല്യങ്ങളുള്ള പരാമീറ്ററുകൾക്കുള്ളതാണ്). ഇത് ഒരു DSL ഉപയോഗിച്ച് ഭാഗികമായി പരിഹരിക്കപ്പെടാം.
3. ഈ പോസ്റ്റിൽ സമാന നോഡുകളുടെ ക്ലസ്റ്ററുകളുടെ ഡൈനാമിക് റീകോൺഫിഗറേഷൻ ഞങ്ങൾ കവർ ചെയ്യുന്നില്ല.

തീരുമാനം

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

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

ഈ സമീപനം പല തരത്തിൽ വിപുലീകരിക്കാം:

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

നന്ദി

ഈ പോസ്റ്റിന്റെ ഡ്രാഫ്റ്റിനെക്കുറിച്ച് പ്രചോദനാത്മകമായ ഫീഡ്‌ബാക്ക് നൽകിയതിന്, അത് കൂടുതൽ വ്യക്തമാക്കാൻ എന്നെ സഹായിച്ച ആൻഡ്രി സാക്‌സോനോവ്, പവൽ പോപോവ്, ആന്റൺ നെഹേവ് എന്നിവരോട് നന്ദി പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

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