விநியோகிக்கப்பட்ட அமைப்பின் தொகுக்கக்கூடிய கட்டமைப்பு

இந்த இடுகையில் விநியோகிக்கப்பட்ட அமைப்பின் உள்ளமைவைக் கையாள்வதற்கான ஒரு சுவாரஸ்யமான வழியைப் பகிர்ந்து கொள்ள விரும்புகிறோம்.
உள்ளமைவு நேரடியாக ஸ்கலா மொழியில் ஒரு வகை பாதுகாப்பான முறையில் குறிப்பிடப்படுகிறது. ஒரு எடுத்துக்காட்டு செயல்படுத்தல் விரிவாக விவரிக்கப்பட்டுள்ளது. ஒட்டுமொத்த வளர்ச்சி செயல்முறையில் தாக்கம் உட்பட, முன்மொழிவின் பல்வேறு அம்சங்கள் விவாதிக்கப்படுகின்றன.

(ரஷ்ய மொழியில்)

அறிமுகம்

வலுவான விநியோகிக்கப்பட்ட அமைப்புகளை உருவாக்க, அனைத்து முனைகளிலும் சரியான மற்றும் ஒத்திசைவான உள்ளமைவைப் பயன்படுத்த வேண்டும். ஒரு பொதுவான தீர்வாக ஒரு உரை வரிசைப்படுத்தல் விளக்கம் (டெர்ராஃபார்ம், அன்சிபிள் அல்லது வேறு ஏதாவது) மற்றும் தானாக உருவாக்கப்படும் உள்ளமைவு கோப்புகள் (பெரும்பாலும் - ஒவ்வொரு முனை/பாத்திரத்திற்கும் அர்ப்பணிக்கப்பட்டவை) பயன்படுத்துவதாகும். ஒவ்வொரு தகவல்தொடர்பு முனைகளிலும் ஒரே மாதிரியான பதிப்புகளின் அதே நெறிமுறைகளைப் பயன்படுத்த விரும்புகிறோம் (இல்லையெனில் நாங்கள் பொருந்தாத சிக்கல்களை சந்திக்க நேரிடும்). JVM உலகில், அனைத்து தகவல்தொடர்பு முனைகளிலும் குறைந்தபட்சம் செய்தி அனுப்பும் நூலகம் ஒரே பதிப்பாக இருக்க வேண்டும் என்பதாகும்.

கணினியை சோதிப்பது பற்றி என்ன? நிச்சயமாக, ஒருங்கிணைப்பு சோதனைகளுக்கு வருவதற்கு முன், அனைத்து கூறுகளுக்கும் யூனிட் சோதனைகள் இருக்க வேண்டும். இயக்க நேரத்தில் சோதனை முடிவுகளை விரிவுபடுத்துவதற்கு, அனைத்து நூலகங்களின் பதிப்புகளும் இயக்க நேரம் மற்றும் சோதனை சூழல்கள் இரண்டிலும் ஒரே மாதிரியாக இருப்பதை உறுதிசெய்ய வேண்டும்.

ஒருங்கிணைப்புச் சோதனைகளை இயக்கும்போது, ​​எல்லா முனைகளிலும் ஒரே வகுப்புப் பாதையை வைத்திருப்பது மிகவும் எளிதானது. வரிசைப்படுத்தலில் அதே கிளாஸ்பாத் பயன்படுத்தப்படுவதை உறுதி செய்ய வேண்டும். (வெவ்வேறு நோட்களில் வெவ்வேறு கிளாஸ்பாத்களைப் பயன்படுத்துவது சாத்தியம், ஆனால் இந்த உள்ளமைவைக் குறிப்பிடுவது மற்றும் அதைச் சரியாகப் பயன்படுத்துவது மிகவும் கடினம்.) எனவே விஷயங்களை எளிமையாக வைத்திருக்க, எல்லா முனைகளிலும் ஒரே மாதிரியான கிளாஸ்பாத்களை மட்டுமே கருத்தில் கொள்வோம்.

கட்டமைப்பு மென்பொருளுடன் இணைந்து உருவாகிறது. பல்வேறு வகைகளை அடையாளம் காண நாம் பொதுவாக பதிப்புகளைப் பயன்படுத்துகிறோம்
மென்பொருள் வளர்ச்சியின் நிலைகள். பதிப்பு நிர்வாகத்தின் கீழ் உள்ளமைவை உள்ளடக்கியது மற்றும் சில லேபிள்களுடன் வெவ்வேறு உள்ளமைவுகளை அடையாளம் காண்பது நியாயமானது. உற்பத்தியில் ஒரே ஒரு உள்ளமைவு இருந்தால், ஒற்றைப் பதிப்பை அடையாளங்காட்டியாகப் பயன்படுத்தலாம். சில நேரங்களில் நாம் பல உற்பத்தி சூழல்களைக் கொண்டிருக்கலாம். ஒவ்வொரு சூழலுக்கும் நமக்கு தனித்தனியான கட்டமைப்பு தேவைப்படலாம். எனவே வெவ்வேறு உள்ளமைவுகளை தனித்துவமாக அடையாளம் காண கட்டமைப்புகள் கிளை மற்றும் பதிப்புடன் லேபிளிடப்படலாம். ஒவ்வொரு கிளை லேபிள் மற்றும் பதிப்பு ஒவ்வொரு முனையிலும் விநியோகிக்கப்பட்ட முனைகள், போர்ட்கள், வெளிப்புற ஆதாரங்கள், கிளாஸ்பாத் லைப்ரரி பதிப்புகள் ஆகியவற்றின் ஒற்றை கலவையை ஒத்துள்ளது. இங்கே நாம் ஒற்றைக் கிளையை மட்டுமே மறைப்போம் மற்றும் மற்ற கலைப்பொருட்களைப் போலவே மூன்று கூறு தசம பதிப்பின் (1.2.3) உள்ளமைவுகளை அடையாளம் காண்போம்.

நவீன சூழல்களில் உள்ளமைவு கோப்புகள் கைமுறையாக மாற்றப்படாது. பொதுவாக நாம் உருவாக்குகிறோம்
வரிசைப்படுத்தல் நேரத்தில் config கோப்புகள் மற்றும் அவர்களை தொடாதே பிறகு. எனவே உள்ளமைவு கோப்புகளுக்கு நாம் ஏன் இன்னும் உரை வடிவமைப்பைப் பயன்படுத்துகிறோம் என்று ஒருவர் கேட்கலாம்? ஒரு சாத்தியமான விருப்பமானது, ஒரு தொகுப்பு அலகுக்குள் உள்ளமைவை வைப்பது மற்றும் தொகுக்கும் நேர உள்ளமைவு சரிபார்ப்பிலிருந்து பயனடைவது.

இந்த இடுகையில் தொகுக்கப்பட்ட கலைப்பொருளில் உள்ளமைவை வைத்திருப்பதற்கான யோசனையை ஆராய்வோம்.

தொகுக்கக்கூடிய கட்டமைப்பு

இந்த பிரிவில் நிலையான உள்ளமைவின் உதாரணத்தைப் பற்றி விவாதிப்போம். இரண்டு எளிய சேவைகள் - எதிரொலி சேவை மற்றும் எதிரொலி சேவையின் கிளையன்ட் ஆகியவை கட்டமைக்கப்பட்டு செயல்படுத்தப்படுகின்றன. இரண்டு சேவைகளுடன் இரண்டு வெவ்வேறு விநியோகிக்கப்பட்ட அமைப்புகள் உடனடியாகத் தொடங்கப்படுகின்றன. ஒன்று ஒற்றை முனை உள்ளமைவுக்கானது மற்றும் மற்றொன்று இரண்டு முனைகளின் உள்ளமைவுக்கானது.

ஒரு பொதுவான விநியோக அமைப்பு ஒரு சில முனைகளைக் கொண்டுள்ளது. சில வகைகளைப் பயன்படுத்தி முனைகளை அடையாளம் காணலாம்:

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

அல்லது தான்

case class NodeId(hostName: String)

அல்லது

object Singleton
type NodeId = Singleton.type

இந்த முனைகள் பல்வேறு பாத்திரங்களைச் செய்கின்றன, சில சேவைகளை இயக்குகின்றன மற்றும் TCP/HTTP இணைப்புகள் மூலம் மற்ற முனைகளுடன் தொடர்பு கொள்ள முடியும்.

TCP இணைப்புக்கு குறைந்தபட்சம் ஒரு போர்ட் எண் தேவை. கிளையன்ட் மற்றும் சர்வர் ஒரே நெறிமுறையைப் பேசுவதையும் நாங்கள் உறுதிப்படுத்த விரும்புகிறோம். கணுகளுக்கிடையேயான தொடர்பை மாதிரியாக்க, பின்வரும் வகுப்பை அறிவிப்போம்:

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

எங்கே Port ஒரு தான் Int அனுமதிக்கப்பட்ட வரம்பிற்குள்:

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

சுத்திகரிக்கப்பட்ட வகைகள்

பார்க்க சுத்திகரிக்கப்பட்ட நூலகம். சுருக்கமாக, மற்ற வகைகளுக்கு தொகுக்க நேரக் கட்டுப்பாடுகளைச் சேர்க்க இது அனுமதிக்கிறது. இந்த வழக்கில் Int போர்ட் எண்ணைக் குறிக்கும் 16-பிட் மதிப்புகள் மட்டுமே அனுமதிக்கப்படுகிறது. இந்த உள்ளமைவு அணுகுமுறைக்கு இந்த நூலகத்தைப் பயன்படுத்த வேண்டிய அவசியம் இல்லை. இது மிகவும் நன்றாக பொருந்துகிறது.

HTTP (REST) ​​க்கு எங்களுக்கு சேவையின் பாதையும் தேவைப்படலாம்:

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

பாண்டம் வகை

தொகுப்பின் போது நெறிமுறையை அடையாளம் காண, வகை வாதத்தை அறிவிக்கும் ஸ்கலா அம்சத்தைப் பயன்படுத்துகிறோம் Protocol இது வகுப்பில் பயன்படுத்தப்படவில்லை. இது ஒரு அழைக்கப்பட்டது பாண்டம் வகை. இயக்க நேரத்தில், நெறிமுறை அடையாளங்காட்டியின் நிகழ்வு நமக்கு அரிதாகவே தேவைப்படுகிறது, அதனால்தான் நாங்கள் அதைச் சேமிப்பதில்லை. தொகுப்பின் போது இந்த பாண்டம் வகை கூடுதல் வகை பாதுகாப்பை அளிக்கிறது. தவறான நெறிமுறையுடன் துறைமுகத்தை எங்களால் அனுப்ப முடியாது.

மிகவும் பரவலாகப் பயன்படுத்தப்படும் நெறிமுறைகளில் ஒன்று REST API உடன் Json வரிசைமுறை:

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. சேவை மற்றும் கிளையன்ட் வெவ்வேறு முனைகளில் இருக்கும் இரண்டு முனை தளவமைப்பு.

a க்கான உள்ளமைவு ஒற்றை முனை தளவமைப்பு பின்வருமாறு:

ஒற்றை முனை கட்டமைப்பு

object SingleNodeConfig extends EchoConfig[String] 
  with EchoClientConfig[String] with FiniteDurationLifecycleConfig
{
  case object Singleton // identifier of the single node 
  // configuration of server
  type NodeId = Singleton.type
  def nodeId = Singleton

  /** Type safe service port specification. */
  override def portNumber: PortNumber = 8088

  // configuration of client

  /** We'll use the service provided by the same host. */
  def echoServiceDependency = echoService

  override def testMessage: UrlPathElement = "hello"

  def pollInterval: FiniteDuration = 1.second

  // lifecycle controller configuration
  def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 requests, not 9.
}

சேவையகம் மற்றும் கிளையன்ட் உள்ளமைவு இரண்டையும் நீட்டிக்கும் ஒற்றை உள்ளமைவை இங்கே உருவாக்குகிறோம். லைஃப்சைக்கிள் கன்ட்ரோலரை நாங்கள் உள்ளமைக்கிறோம், அது வழக்கமாக கிளையன்ட் மற்றும் சர்வரை நிறுத்தும் lifetime இடைவெளி கடந்து செல்கிறது.

ஒரே மாதிரியான சேவை செயலாக்கங்கள் மற்றும் உள்ளமைவுகள் இரண்டு தனித்தனி முனைகளுடன் ஒரு கணினியின் அமைப்பை உருவாக்க பயன்படுத்தப்படலாம். நாம் தான் உருவாக்க வேண்டும் இரண்டு தனித்தனி முனை கட்டமைப்புகள் பொருத்தமான சேவைகளுடன்:

இரண்டு முனைகளின் கட்டமைப்பு

  object NodeServerConfig extends EchoConfig[String] with SigTermLifecycleConfig
  {
    type NodeId = NodeIdImpl

    def nodeId = NodeServer

    override def portNumber: PortNumber = 8080
  }

  object NodeClientConfig extends EchoClientConfig[String] with FiniteDurationLifecycleConfig
  {
    // NB! dependency specification
    def echoServiceDependency = NodeServerConfig.echoService

    def pollInterval: FiniteDuration = 1.second

    def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 request, not 9.

    def testMessage: String = "dolly"
  }

சார்புநிலையை எவ்வாறு குறிப்பிடுகிறோம் என்பதைப் பார்க்கவும். தற்போதைய முனையின் சார்புநிலையாக மற்ற முனை வழங்கிய சேவையை நாங்கள் குறிப்பிடுகிறோம். சார்பு வகை சரிபார்க்கப்பட்டது, ஏனெனில் அதில் நெறிமுறையை விவரிக்கும் பாண்டம் வகை உள்ளது. மற்றும் இயக்க நேரத்தில் நாம் சரியான முனை ஐடி வேண்டும். முன்மொழியப்பட்ட உள்ளமைவு அணுகுமுறையின் முக்கியமான அம்சங்களில் இதுவும் ஒன்றாகும். ஒருமுறை மட்டுமே போர்ட்டை அமைக்கும் திறனை இது வழங்குகிறது மற்றும் நாங்கள் சரியான போர்ட்டைக் குறிப்பிடுகிறோம் என்பதை உறுதிப்படுத்துகிறது.

இரண்டு முனைகள் செயல்படுத்தல்

இந்த உள்ளமைவுக்கு நாங்கள் அதே சேவை செயலாக்கங்களைப் பயன்படுத்துகிறோம். எந்த மாற்றமும் இல்லை. இருப்பினும், வெவ்வேறு சேவைகளைக் கொண்ட இரண்டு வெவ்வேறு முனை செயலாக்கங்களை நாங்கள் உருவாக்குகிறோம்:

  object TwoJvmNodeServerImpl extends ZeroServiceImpl[IO] with EchoServiceService with SigIntLifecycleServiceImpl {
    type Config = EchoConfig[String] with SigTermLifecycleConfig
  }

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

The first node implements server and it only needs server side config. The second node implements client and needs another part of config. Both nodes require some lifetime specification. For the purposes of this post service node will have infinite lifetime that could be terminated using SIGTERM, எக்கோ கிளையன்ட் கட்டமைக்கப்பட்ட வரையறுக்கப்பட்ட காலத்திற்குப் பிறகு நிறுத்தப்படும். பார்க்கவும் தொடக்க பயன்பாடு விவரங்களுக்கு.

ஒட்டுமொத்த வளர்ச்சி செயல்முறை

இந்த அணுகுமுறை நாம் உள்ளமைவுடன் வேலை செய்யும் முறையை எவ்வாறு மாற்றுகிறது என்பதைப் பார்ப்போம்.

குறியீடாக உள்ளமைவு தொகுக்கப்பட்டு ஒரு கலைப்பொருளை உருவாக்கும். உள்ளமைவு கலைப்பொருளை மற்ற குறியீடு கலைப்பொருட்களிலிருந்து பிரிப்பது நியாயமானது. பெரும்பாலும் ஒரே குறியீட்டு அடிப்படையில் பல கட்டமைப்புகளை நாம் கொண்டிருக்கலாம். நிச்சயமாக, பல்வேறு கட்டமைப்பு கிளைகளின் பல பதிப்புகளை நாம் கொண்டிருக்கலாம். ஒரு உள்ளமைவில் நூலகங்களின் குறிப்பிட்ட பதிப்புகளைத் தேர்ந்தெடுக்கலாம், இந்த கட்டமைப்பை நாம் பயன்படுத்தும் போதெல்லாம் இது மாறாமல் இருக்கும்.

ஒரு கட்டமைப்பு மாற்றம் குறியீடு மாற்றமாக மாறும். எனவே இது அதே தர உத்தரவாத செயல்முறையால் மூடப்பட்டிருக்க வேண்டும்:

டிக்கெட் -> PR -> மதிப்பாய்வு -> ஒன்றிணைத்தல் -> தொடர்ச்சியான ஒருங்கிணைப்பு -> தொடர்ச்சியான வரிசைப்படுத்தல்

அணுகுமுறையின் பின்வரும் விளைவுகள் உள்ளன:

1. ஒரு குறிப்பிட்ட அமைப்பின் உதாரணத்திற்கு உள்ளமைவு ஒத்திசைவானது. கணுக்களுக்கு இடையே தவறான இணைப்பு இருக்க வழி இல்லை என்று தெரிகிறது.
2. ஒரே ஒரு முனையில் உள்ளமைவை மாற்றுவது எளிதல்ல. உள்நுழைந்து சில உரை கோப்புகளை மாற்றுவது நியாயமற்றதாகத் தெரிகிறது. எனவே கட்டமைப்பு சறுக்கல் குறைவாக சாத்தியமாகும்.
3. சிறிய கட்டமைப்பு மாற்றங்களைச் செய்வது எளிதல்ல.
4. பெரும்பாலான உள்ளமைவு மாற்றங்கள் அதே மேம்பாட்டு செயல்முறையைப் பின்பற்றும், மேலும் இது சில மதிப்பாய்வை அனுப்பும்.

உற்பத்தி கட்டமைப்புக்கு தனி களஞ்சியம் தேவையா? தயாரிப்பு உள்ளமைவில் முக்கியமான தகவல்கள் இருக்கலாம், அதை நாங்கள் பலருக்கு எட்டாதவாறு வைத்திருக்க விரும்புகிறோம். எனவே உற்பத்தி உள்ளமைவைக் கொண்டிருக்கும் கட்டுப்படுத்தப்பட்ட அணுகலுடன் ஒரு தனி களஞ்சியத்தை வைத்திருப்பது மதிப்புக்குரியதாக இருக்கலாம். உள்ளமைவை இரண்டு பகுதிகளாகப் பிரிக்கலாம் - ஒன்று உற்பத்தியின் மிகவும் திறந்த அளவுருக்கள் மற்றும் உள்ளமைவின் இரகசிய பகுதியைக் கொண்டிருக்கும் ஒன்று. இது பெரும்பாலான டெவலப்பர்களுக்கு பெரும்பாலான அளவுருக்களுக்கான அணுகலைச் செயல்படுத்தும் அதே வேளையில் மிகவும் முக்கியமான விஷயங்களுக்கான அணுகலைக் கட்டுப்படுத்தும். இயல்புநிலை அளவுரு மதிப்புகளுடன் இடைநிலை பண்புகளைப் பயன்படுத்தி இதைச் செய்வது எளிது.

வேறுபாடுகள்

மற்ற கட்டமைப்பு மேலாண்மை நுட்பங்களுடன் ஒப்பிடும்போது முன்மொழியப்பட்ட அணுகுமுறையின் நன்மை தீமைகளைப் பார்ப்போம்.

முதலில், உள்ளமைவைக் கையாள்வதற்கான முன்மொழியப்பட்ட வழியின் வெவ்வேறு அம்சங்களுக்கு சில மாற்றுகளை பட்டியலிடுவோம்:

1. இலக்கு கணினியில் உரை கோப்பு.
2. மையப்படுத்தப்பட்ட விசை மதிப்பு சேமிப்பு (போன்ற etcd/zookeeper).
3. செயல்முறையை மறுதொடக்கம் செய்யாமல் மறுகட்டமைக்க/மறுதொடக்கம் செய்யக்கூடிய துணை செயலாக்க கூறுகள்.
4. கலைப்பொருள் மற்றும் பதிப்புக் கட்டுப்பாட்டிற்கு வெளியே உள்ளமைவு.

தற்காலிக திருத்தங்களின் அடிப்படையில் உரை கோப்பு சில நெகிழ்வுத்தன்மையை வழங்குகிறது. ஒரு கணினியின் நிர்வாகி இலக்கு முனையில் உள்நுழைந்து, மாற்றம் செய்து, சேவையை மறுதொடக்கம் செய்யலாம். இது பெரிய அமைப்புகளுக்கு நல்லதாக இருக்காது. மாற்றத்தின் பின்னால் எந்த தடயங்களும் விடப்படவில்லை. மாற்றம் மற்றொரு ஜோடி கண்களால் மதிப்பாய்வு செய்யப்படவில்லை. மாற்றத்திற்கு என்ன காரணம் என்பதைக் கண்டறிவது கடினமாக இருக்கலாம். இது சோதனை செய்யப்படவில்லை. விநியோகிக்கப்பட்ட கணினியின் கண்ணோட்டத்தில் ஒரு நிர்வாகி மற்ற முனைகளில் ஒன்றில் உள்ளமைவைப் புதுப்பிக்க மறந்துவிடலாம்.

(Btw, இறுதியில் உரை கட்டமைப்பு கோப்புகளைப் பயன்படுத்தத் தொடங்க வேண்டிய அவசியம் ஏற்பட்டால், அதை உருவாக்கக்கூடிய பாகுபடுத்தி + வேலிடேட்டரை மட்டுமே சேர்க்க வேண்டும். Config தட்டச்சு செய்து, உரை கட்டமைப்புகளைப் பயன்படுத்தத் தொடங்க போதுமானதாக இருக்கும். தொகுக்கும் நேர உள்ளமைவின் சிக்கலானது உரை அடிப்படையிலான கட்டமைப்புகளின் சிக்கலை விட சற்று சிறியது என்பதையும் இது காட்டுகிறது, ஏனெனில் உரை அடிப்படையிலான பதிப்பில் நமக்கு சில கூடுதல் குறியீடுகள் தேவைப்படுகின்றன.)

மையப்படுத்தப்பட்ட விசை மதிப்பு சேமிப்பு என்பது பயன்பாட்டு மெட்டா அளவுருக்களை விநியோகிப்பதற்கான ஒரு நல்ல வழிமுறையாகும். இங்கே நாம் உள்ளமைவு மதிப்புகள் மற்றும் தரவு என்றால் என்ன என்பதைப் பற்றி சிந்திக்க வேண்டும். ஒரு செயல்பாடு வழங்கப்பட்டது C => A => B நாம் பொதுவாக அரிதாக மாறும் மதிப்புகளை அழைக்கிறோம் C "கட்டமைப்பு", அடிக்கடி தரவு மாற்றப்படும் போது A - வெறும் உள்ளீடு தரவு. தரவை விட முந்தைய செயல்பாட்டிற்கு கட்டமைப்பு வழங்கப்பட வேண்டும் A. இந்த யோசனையின் அடிப்படையில், உள்ளமைவுத் தரவை வெறும் தரவிலிருந்து வேறுபடுத்துவதற்குப் பயன்படுத்தப்படும் மாற்றங்களின் எதிர்பார்க்கப்படும் அதிர்வெண் என்று நாம் கூறலாம். தரவு பொதுவாக ஒரு மூலத்திலிருந்து (பயனர்) வருகிறது மற்றும் கட்டமைப்பு வேறு மூலத்திலிருந்து (நிர்வாகம்) வருகிறது. துவக்க செயல்முறைக்குப் பிறகு மாற்றக்கூடிய அளவுருக்களைக் கையாள்வது பயன்பாட்டின் சிக்கலை அதிகரிக்க வழிவகுக்கிறது. அத்தகைய அளவுருக்களுக்கு, அவற்றின் விநியோக வழிமுறை, பாகுபடுத்துதல் மற்றும் சரிபார்த்தல், தவறான மதிப்புகளைக் கையாளுதல் ஆகியவற்றை நாம் கையாள வேண்டும். எனவே, நிரல் சிக்கலைக் குறைக்க, இயக்க நேரத்தில் மாற்றக்கூடிய அளவுருக்களின் எண்ணிக்கையைக் குறைப்பது நல்லது (அல்லது அவற்றை முழுவதுமாக அகற்றவும்).

இந்த இடுகையின் கண்ணோட்டத்தில் நாம் நிலையான மற்றும் மாறும் அளவுருக்களுக்கு இடையே ஒரு வேறுபாட்டை உருவாக்க வேண்டும். சேவை தர்க்கத்திற்கு இயக்க நேரத்தில் சில அளவுருக்களின் அரிதான மாற்றம் தேவைப்பட்டால், அவற்றை டைனமிக் அளவுருக்கள் என்று அழைக்கலாம். இல்லையெனில் அவை நிலையானவை மற்றும் முன்மொழியப்பட்ட அணுகுமுறையைப் பயன்படுத்தி கட்டமைக்கப்படலாம். டைனமிக் மறுகட்டமைப்பிற்கு மற்ற அணுகுமுறைகள் தேவைப்படலாம். எடுத்துக்காட்டாக, விநியோகிக்கப்பட்ட கணினியின் தனி செயல்முறைகளை மறுதொடக்கம் செய்வது போலவே கணினியின் பகுதிகள் புதிய உள்ளமைவு அளவுருக்களுடன் மறுதொடக்கம் செய்யப்படலாம்.
(இயக்க நேர மறுகட்டமைப்பைத் தவிர்க்க வேண்டும் என்பது எனது தாழ்மையான கருத்து, ஏனெனில் இது கணினியின் சிக்கலை அதிகரிக்கிறது.
செயல்முறைகளை மறுதொடக்கம் செய்வதற்கான OS ஆதரவை நம்புவது மிகவும் நேரடியானதாக இருக்கலாம். இருப்பினும், அது எப்போதும் சாத்தியமில்லை.)

நிலையான உள்ளமைவைப் பயன்படுத்துவதில் ஒரு முக்கிய அம்சம், சில நேரங்களில் டைனமிக் உள்ளமைவை (வேறு காரணங்கள் இல்லாமல்) மக்கள் கருத்தில் கொள்ள வைக்கிறது, உள்ளமைவு புதுப்பிப்பின் போது சேவை வேலையில்லா நேரம். உண்மையில், நிலையான உள்ளமைவில் மாற்றங்களைச் செய்ய வேண்டும் என்றால், புதிய மதிப்புகள் பயனுள்ளதாக இருக்கும் வகையில் கணினியை மறுதொடக்கம் செய்ய வேண்டும். வேலையில்லா நேரத்திற்கான தேவைகள் வெவ்வேறு அமைப்புகளுக்கு மாறுபடும், எனவே அது முக்கியமானதாக இருக்காது. இது முக்கியமானதாக இருந்தால், எந்த கணினியை மறுதொடக்கம் செய்வதற்கும் நாம் முன்கூட்டியே திட்டமிட வேண்டும். உதாரணமாக, நாம் செயல்படுத்த முடியும் AWS ELB இணைப்பு வடிகிறது. இந்த சூழ்நிலையில், கணினியை மறுதொடக்கம் செய்ய வேண்டியிருக்கும் போதெல்லாம், கணினியின் புதிய நிகழ்வை இணையாகத் தொடங்குகிறோம், பின்னர் ELB ஐ அதற்கு மாற்றுவோம், அதே நேரத்தில் பழைய கணினியை ஏற்கனவே உள்ள இணைப்புகளுக்கு சேவை செய்வதை முடிக்க அனுமதிக்கிறோம்.

பதிப்பு செய்யப்பட்ட கலைப்பொருளின் உள்ளே அல்லது வெளியே உள்ளமைவை வைத்திருப்பது பற்றி என்ன? ஒரு கலைப்பொருளுக்குள் உள்ளமைவை வைத்திருப்பது என்பது பெரும்பாலான சந்தர்ப்பங்களில் இந்த உள்ளமைவு மற்ற கலைப்பொருட்களின் அதே தர உத்தரவாத செயல்முறையை நிறைவேற்றியுள்ளது. எனவே உள்ளமைவு நல்ல தரம் மற்றும் நம்பகமானது என்பதை ஒருவர் உறுதியாக நம்பலாம். மாறாக ஒரு தனி கோப்பில் உள்ளமைவு என்றால் அந்த கோப்பில் யார், ஏன் மாற்றங்கள் செய்தார்கள் என்பதற்கான தடயங்கள் எதுவும் இல்லை. இது முக்கியமா? பெரும்பாலான உற்பத்தி அமைப்புகளுக்கு நிலையான மற்றும் உயர்தர உள்ளமைவைக் கொண்டிருப்பது நல்லது என்று நாங்கள் நம்புகிறோம்.

கலைப்பொருளின் பதிப்பு அது எப்போது உருவாக்கப்பட்டது, அதில் என்ன மதிப்புகள் உள்ளன, என்ன அம்சங்கள் இயக்கப்பட்டுள்ளன/முடக்கப்பட்டுள்ளன, உள்ளமைவில் ஒவ்வொரு மாற்றத்தையும் செய்வதற்கு யார் பொறுப்பு என்பதைக் கண்டறிய அனுமதிக்கிறது. ஒரு கலைப்பொருளுக்குள் உள்ளமைவை வைத்திருக்க சில முயற்சிகள் தேவைப்படலாம், மேலும் இது ஒரு வடிவமைப்புத் தேர்வாகும்.

நன்மை தீமைகள்

இங்கே நாம் சில நன்மைகளை முன்னிலைப்படுத்த விரும்புகிறோம் மற்றும் முன்மொழியப்பட்ட அணுகுமுறையின் சில தீமைகள் பற்றி விவாதிக்க விரும்புகிறோம்.

நன்மைகள்

முழுமையான விநியோகிக்கப்பட்ட அமைப்பின் தொகுக்கக்கூடிய கட்டமைப்பின் அம்சங்கள்:

1. உள்ளமைவின் நிலையான சரிபார்ப்பு. இது ஒரு உயர் மட்ட நம்பிக்கையை அளிக்கிறது, கொடுக்கப்பட்ட வகை கட்டுப்பாடுகள் உள்ளமைவு சரியானது.
2. வளமான உள்ளமைவு மொழி. பொதுவாக மற்ற உள்ளமைவு அணுகுமுறைகள் மாறக்கூடிய மாற்றீடுகளுக்கு மட்டுமே.
   Scala ஐப் பயன்படுத்தி, உள்ளமைவைச் சிறப்பாகச் செய்ய, பரந்த அளவிலான மொழி அம்சங்களைப் பயன்படுத்தலாம். எடுத்துக்காட்டாக, இயல்புநிலை மதிப்புகளை வழங்க பண்புகளைப் பயன்படுத்தலாம், வெவ்வேறு நோக்கங்களை அமைக்க பொருள்கள், நாம் குறிப்பிடலாம் valவெளிப்புற நோக்கத்தில் (DRY) ஒருமுறை மட்டுமே வரையறுக்கப்படுகிறது. சில வகுப்புகளின் நேரடி வரிசைகள் அல்லது நிகழ்வுகளைப் பயன்படுத்துவது சாத்தியம் (Seq, Map, முதலியன).
3. DSL. DSL எழுத்தாளர்களுக்கு Scala நல்ல ஆதரவைக் கொண்டுள்ளது. மிகவும் வசதியான மற்றும் இறுதி பயனர் நட்புடன் இருக்கும் உள்ளமைவு மொழியை நிறுவ இந்த அம்சங்களை ஒருவர் பயன்படுத்தலாம், இதனால் இறுதி உள்ளமைவை டொமைன் பயனர்களால் குறைந்தபட்சம் படிக்க முடியும்.
4. முனைகள் முழுவதும் ஒருமைப்பாடு மற்றும் ஒத்திசைவு. முழு விநியோகிக்கப்பட்ட அமைப்புக்கான உள்ளமைவை ஒரே இடத்தில் வைத்திருப்பதன் நன்மைகளில் ஒன்று, அனைத்து மதிப்புகளும் கண்டிப்பாக ஒருமுறை வரையறுக்கப்பட்டு, நமக்குத் தேவைப்படும் எல்லா இடங்களிலும் மீண்டும் பயன்படுத்தப்படும். பாதுகாப்பான போர்ட் அறிவிப்புகளைத் தட்டச்சு செய்யவும், சாத்தியமான அனைத்து சரியான உள்ளமைவுகளிலும் கணினியின் முனைகள் ஒரே மொழியைப் பேசும். முனைகளுக்கு இடையே வெளிப்படையான சார்புகள் உள்ளன, இது சில சேவைகளை வழங்குவதை மறப்பதை கடினமாக்குகிறது.
5. மாற்றங்களின் உயர் தரம். சாதாரண PR செயல்முறையின் மூலம் உள்ளமைவு மாற்றங்களை கடந்து செல்லும் ஒட்டுமொத்த அணுகுமுறை, உள்ளமைவில் தரத்தின் உயர் தரத்தை நிறுவுகிறது.
6. ஒரே நேரத்தில் உள்ளமைவு மாற்றங்கள். உள்ளமைவில் ஏதேனும் மாற்றங்களைச் செய்யும்போதெல்லாம், அனைத்து முனைகளும் புதுப்பிக்கப்படுவதை தானியங்கு வரிசைப்படுத்தல் உறுதி செய்கிறது.
7. விண்ணப்பத்தை எளிமைப்படுத்துதல். பயன்பாடு உள்ளமைவை அலசவும் சரிபார்க்கவும் மற்றும் தவறான உள்ளமைவு மதிப்புகளைக் கையாளவும் தேவையில்லை. இது ஒட்டுமொத்த பயன்பாட்டை எளிதாக்குகிறது. (சில சிக்கலான அதிகரிப்பு உள்ளமைவில் உள்ளது, ஆனால் இது பாதுகாப்பை நோக்கிய ஒரு நனவான வர்த்தகம்.) சாதாரண உள்ளமைவுக்குத் திரும்புவது மிகவும் எளிமையானது - விடுபட்ட துண்டுகளைச் சேர்க்கவும். தொகுக்கப்பட்ட உள்ளமைவுடன் தொடங்குவது எளிதானது மற்றும் கூடுதல் துண்டுகளை செயல்படுத்துவதை சில பிந்தைய காலத்திற்கு ஒத்திவைக்கவும்.
8. பதிப்பு கட்டமைப்பு. உள்ளமைவு மாற்றங்கள் அதே வளர்ச்சி செயல்முறையைப் பின்பற்றுவதால், இதன் விளைவாக தனித்துவமான பதிப்பைக் கொண்ட ஒரு கலைப்பொருளைப் பெறுகிறோம். தேவைப்பட்டால் மீண்டும் உள்ளமைவை மாற்ற இது அனுமதிக்கிறது. ஒரு வருடத்திற்கு முன்பு பயன்படுத்தப்பட்ட ஒரு உள்ளமைவை நாம் வரிசைப்படுத்தலாம், அது அதே வழியில் வேலை செய்யும். நிலையான கட்டமைப்பு, விநியோகிக்கப்பட்ட அமைப்பின் முன்கணிப்பு மற்றும் நம்பகத்தன்மையை மேம்படுத்துகிறது. தொகுக்கும் நேரத்தில் உள்ளமைவு சரி செய்யப்பட்டது மற்றும் ஒரு உற்பத்தி அமைப்பில் எளிதில் சிதைக்க முடியாது.
9. மாடுலாரிட்டி. முன்மொழியப்பட்ட கட்டமைப்பானது மட்டு மற்றும் தொகுதிகள் பல்வேறு வழிகளில் இணைக்கப்படலாம்
   வெவ்வேறு கட்டமைப்புகளை ஆதரிக்கவும் (அமைப்புகள்/தளவமைப்புகள்). குறிப்பாக, சிறிய அளவிலான ஒற்றை முனை அமைப்பு மற்றும் பெரிய அளவிலான பல முனை அமைப்பைக் கொண்டிருப்பது சாத்தியமாகும். பல உற்பத்தி தளவமைப்புகளைக் கொண்டிருப்பது நியாயமானது.
10. சோதனை. சோதனை நோக்கங்களுக்காக ஒருவர் ஒரு போலி சேவையை செயல்படுத்தலாம் மற்றும் அதை ஒரு வகை பாதுகாப்பான வழியில் சார்புநிலையாக பயன்படுத்தலாம். சில வேறுபட்ட சோதனை தளவமைப்புகள், பல்வேறு பகுதிகள் மாக்களால் மாற்றப்பட்டு ஒரே நேரத்தில் பராமரிக்கப்படலாம்.
11. ஒருங்கிணைப்பு சோதனை. சில நேரங்களில் விநியோகிக்கப்பட்ட அமைப்புகளில் ஒருங்கிணைப்பு சோதனைகளை இயக்குவது கடினம். முழுமையான விநியோகிக்கப்பட்ட அமைப்பின் பாதுகாப்பான உள்ளமைவைத் தட்டச்சு செய்வதற்கான விவரிக்கப்பட்ட அணுகுமுறையைப் பயன்படுத்தி, அனைத்து விநியோகிக்கப்பட்ட பகுதிகளையும் ஒரே சர்வரில் கட்டுப்படுத்தக்கூடிய வகையில் இயக்கலாம். சூழ்நிலையைப் பின்பற்றுவது எளிது
    சேவைகளில் ஒன்று கிடைக்காதபோது.

குறைபாடுகள்

தொகுக்கப்பட்ட உள்ளமைவு அணுகுமுறை "சாதாரண" உள்ளமைவிலிருந்து வேறுபட்டது மற்றும் இது எல்லா தேவைகளுக்கும் பொருந்தாது. தொகுக்கப்பட்ட கட்டமைப்பின் சில தீமைகள் இங்கே:

1. நிலையான கட்டமைப்பு. இது எல்லா பயன்பாடுகளுக்கும் பொருந்தாமல் இருக்கலாம். சில சந்தர்ப்பங்களில், அனைத்து பாதுகாப்பு நடவடிக்கைகளையும் தவிர்த்து உற்பத்தியில் உள்ளமைவை விரைவாக சரிசெய்ய வேண்டிய அவசியம் உள்ளது. இந்த அணுகுமுறை அதை மேலும் கடினமாக்குகிறது. உள்ளமைவில் ஏதேனும் மாற்றம் செய்த பிறகு தொகுத்தல் மற்றும் மறுபகிர்வு தேவை. இது அம்சம் மற்றும் சுமை இரண்டும் ஆகும்.
2. கட்டமைப்பு உருவாக்கம். சில ஆட்டோமேஷன் கருவி மூலம் config உருவாக்கப்படும் போது இந்த அணுகுமுறைக்கு அடுத்தடுத்த தொகுப்பு தேவைப்படுகிறது (இது தோல்வியடையும்). இந்த கூடுதல் படியை உருவாக்க அமைப்பில் ஒருங்கிணைக்க கூடுதல் முயற்சி தேவைப்படலாம்.
3. கருவிகள். உரை அடிப்படையிலான கட்டமைப்புகளை நம்பியிருக்கும் ஏராளமான கருவிகள் இன்று பயன்பாட்டில் உள்ளன. அவற்றுள் சில
   கட்டமைப்பு தொகுக்கப்படும் போது பொருந்தாது.
4. மனநிலையில் மாற்றம் தேவை. டெவலப்பர்கள் மற்றும் DevOps உரை உள்ளமைவு கோப்புகளை நன்கு அறிந்தவர்கள். உள்ளமைவைத் தொகுக்கும் யோசனை அவர்களுக்கு விசித்திரமாகத் தோன்றலாம்.
5. தொகுக்கக்கூடிய உள்ளமைவை அறிமுகப்படுத்துவதற்கு முன், உயர்தர மென்பொருள் மேம்பாட்டு செயல்முறை தேவைப்படுகிறது.

செயல்படுத்தப்பட்ட எடுத்துக்காட்டில் சில வரம்புகள் உள்ளன:

1. முனை செயலாக்கத்தால் கோரப்படாத கூடுதல் கட்டமைப்பை நாங்கள் வழங்கினால், இல்லாத செயலாக்கத்தைக் கண்டறிய கம்பைலர் எங்களுக்கு உதவாது. இதைப் பயன்படுத்தி தீர்க்க முடியும் HList அல்லது குணாதிசயங்கள் மற்றும் கேக் பேட்டர்னுக்குப் பதிலாக முனை உள்ளமைவுக்கான ADTகள் (கேஸ் வகுப்புகள்).
2. நாம் சில கொதிகலன்களை config கோப்பில் வழங்க வேண்டும்: (package, import, object பிரகடனங்கள்;
   override defஇயல்புநிலை மதிப்புகளைக் கொண்ட அளவுருக்களுக்கானது). இது ஒரு DSL ஐப் பயன்படுத்தி ஓரளவு தீர்க்கப்படலாம்.
3. இந்த இடுகையில், ஒத்த முனைகளின் கிளஸ்டர்களின் மாறும் மறுகட்டமைப்பை நாங்கள் மறைக்கவில்லை.

தீர்மானம்

இந்த இடுகையில் உள்ளமைவை நேரடியாக மூலக் குறியீட்டில் ஒரு வகை பாதுகாப்பான வழியில் பிரதிநிதித்துவப்படுத்தும் யோசனையைப் பற்றி விவாதித்தோம். இந்த அணுகுமுறை xml- மற்றும் பிற உரை அடிப்படையிலான கட்டமைப்புகளுக்கு மாற்றாக பல பயன்பாடுகளில் பயன்படுத்தப்படலாம். எங்களுடைய உதாரணம் ஸ்கலாவில் செயல்படுத்தப்பட்டிருந்தாலும், இது மற்ற தொகுக்கக்கூடிய மொழிகளுக்கும் மொழிபெயர்க்கப்படலாம் (கோட்லின், சி#, ஸ்விஃப்ட் போன்றவை). ஒரு புதிய திட்டத்தில் இந்த அணுகுமுறையை முயற்சி செய்யலாம், அது சரியாக பொருந்தவில்லை என்றால், பழைய முறைக்கு மாறலாம்.

நிச்சயமாக, தொகுக்கக்கூடிய உள்ளமைவுக்கு உயர்தர மேம்பாட்டு செயல்முறை தேவைப்படுகிறது. பதிலுக்கு சமமான உயர்தர வலுவான உள்ளமைவை வழங்குவதாக உறுதியளிக்கிறது.

இந்த அணுகுமுறை பல்வேறு வழிகளில் நீட்டிக்கப்படலாம்:

1. உள்ளமைவு சரிபார்ப்பைச் செய்ய ஒருவர் மேக்ரோக்களைப் பயன்படுத்தலாம் மற்றும் ஏதேனும் வணிக-தர்க்கக் கட்டுப்பாடுகள் தோல்விகள் ஏற்பட்டால் தொகுக்கும் நேரத்தில் தோல்வியடையும்.
2. ஒரு டொமைன்-பயனர்-நட்பு வழியில் உள்ளமைவை பிரதிநிதித்துவப்படுத்த ஒரு DSL செயல்படுத்தப்படலாம்.
3. தானியங்கு கட்டமைப்பு சரிசெய்தல்களுடன் மாறும் வள மேலாண்மை. உதாரணமாக, கிளஸ்டர் முனைகளின் எண்ணிக்கையை நாம் சரிசெய்யும்போது (1) முனைகள் சற்று மாற்றியமைக்கப்பட்ட கட்டமைப்பைப் பெற வேண்டும்; (2) புதிய முனைகள் தகவலைப் பெற கிளஸ்டர் மேலாளர்.

நன்றி

இந்த இடுகையின் வரைவு பற்றிய உத்வேகமான கருத்துக்களை வழங்கிய ஆண்ட்ரி சக்சோனோவ், பாவெல் போபோவ், அன்டன் நெஹேவ் ஆகியோருக்கு நான் நன்றி சொல்ல விரும்புகிறேன், இது எனக்கு தெளிவுபடுத்த உதவியது.

ஆதாரம்: www.habr.com