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

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

(ஆங்கிலம்)

அறிமுகம்

நம்பகமான விநியோகிக்கப்பட்ட அமைப்பை உருவாக்குவது என்பது அனைத்து முனைகளும் மற்ற முனைகளுடன் ஒத்திசைக்கப்பட்ட சரியான உள்ளமைவைப் பயன்படுத்துவதாகும். 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-கள், இயற்கணித தரவு வகைகள்). இந்த இடுகையின் நோக்கங்களுக்காக, நாங்கள் கேக் பேட்டர்னைப் பயன்படுத்துவோம் மற்றும் தொகுதிகளைப் பயன்படுத்துவோம் trait'ov. (கேக் பேட்டர்ன் இந்த அணுகுமுறையின் தேவையான உறுப்பு அல்ல. இது ஒரு சாத்தியமான செயல்படுத்தல்.)

சேவைகளுக்கிடையேயான சார்புகளை துறைமுகங்களைத் திரும்பப் பெறும் முறைகளாகக் குறிப்பிடலாம் EndPointமற்ற முனைகளின்:

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

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

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

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

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

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

சேவைகளை செயல்படுத்துதல்

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

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

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

எங்கே

• Config - இந்த சேவைக்கான கட்டமைப்பு வகை
• AddressResolver - மற்ற முனைகளின் முகவரிகளைக் கண்டறிய உங்களை அனுமதிக்கும் இயக்க நேர பொருள் (கீழே காண்க)

மற்றும் நூலகத்திலிருந்து பிற வகைகள் cats:

• F[_] - விளைவு வகை (எளிமையான வழக்கில் F[A] ஒரு செயல்பாடாக இருக்கலாம் () => A. இந்த இடுகையில் நாம் பயன்படுத்துவோம் cats.IO.)
• Reader[A,B] - செயல்பாட்டிற்கு அதிகமாகவோ அல்லது குறைவாகவோ ஒத்ததாக உள்ளது A => B
• cats.Resource - பெறப்பட்ட மற்றும் வெளியிடக்கூடிய ஒரு வளம்
• Timer - டைமர் (சிறிது நேரம் தூங்கவும் நேர இடைவெளியை அளவிடவும் உங்களை அனுமதிக்கிறது)
• ContextShift - அனலாக் ExecutionContext
• Applicative - தனிப்பட்ட விளைவுகளை (கிட்டத்தட்ட ஒரு மோனாட்) இணைக்க உங்களை அனுமதிக்கும் விளைவு வகை வகுப்பு. மிகவும் சிக்கலான பயன்பாடுகளில் இதைப் பயன்படுத்துவது நல்லது Monad/ConcurrentEffect.

இந்த செயல்பாட்டு கையொப்பத்தைப் பயன்படுத்தி நாம் பல சேவைகளை செயல்படுத்தலாம். எடுத்துக்காட்டாக, எதுவும் செய்யாத சேவை:

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

(செ.மீ. மூல, இதில் பிற சேவைகள் செயல்படுத்தப்படுகின்றன - எதிரொலி சேவை, எதிரொலி கிளையன்ட்
и வாழ்நாள் கட்டுப்பாட்டாளர்கள்.)

ஒரு முனை என்பது பல சேவைகளைத் தொடங்கக்கூடிய ஒரு பொருளாகும் (வளங்களின் சங்கிலியின் வெளியீடு கேக் வடிவத்தால் உறுதி செய்யப்படுகிறது):

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

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

ஹோஸ்ட் பெயர் தீர்மானம்

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

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) உருவாக்கப்படும். கட்டமைப்பை ஒரு தனி கலைப்பொருளில் வைப்பது அர்த்தமுள்ளதாகத் தெரிகிறது. ஏனென்றால் ஒரே குறியீட்டின் அடிப்படையில் நாம் பல கட்டமைப்புகளை வைத்திருக்க முடியும். மீண்டும், வெவ்வேறு கட்டமைப்பு கிளைகளுடன் தொடர்புடைய கலைப்பொருட்களை உருவாக்க முடியும். நூலகங்களின் குறிப்பிட்ட பதிப்புகளின் சார்புகள் உள்ளமைவுடன் சேமிக்கப்படும், மேலும் இந்த பதிப்புகள் எப்போதும் சேமிக்கப்படும்.

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

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

தொகுக்கப்பட்ட கட்டமைப்பை செயல்படுத்துவதன் முக்கிய விளைவுகள்:

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

2. ஒரே ஒரு முனையில் உள்ளமைவை மாற்றுவது சிக்கலானது. எனவே, "கட்டமைப்பு சறுக்கல்" சாத்தியமில்லை.

3. சிறிய கட்டமைப்பு மாற்றங்களைச் செய்வது மிகவும் கடினமாகிறது.

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

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

சாத்தியமான மாறுபாடுகள்

தொகுக்கப்பட்ட உள்ளமைவை சில பொதுவான மாற்றுகளுடன் ஒப்பிட முயற்சிப்போம்:

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

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

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

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

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

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

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

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

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

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

முன்மொழியப்பட்ட தொழில்நுட்பத்தின் நன்மைகள் மற்றும் தீமைகள் குறித்து நான் வாழ விரும்புகிறேன்.

நன்மைகள்

தொகுக்கப்பட்ட விநியோகிக்கப்பட்ட கணினி உள்ளமைவின் முக்கிய அம்சங்களின் பட்டியல் கீழே உள்ளது:

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

தீமைகள் மற்றும் வரம்புகள்

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

1. நிலையான கட்டமைப்பு. சில நேரங்களில் நீங்கள் அனைத்து பாதுகாப்பு வழிமுறைகளையும் கடந்து, உற்பத்தியில் உள்ளமைவை விரைவாக சரிசெய்ய வேண்டும். இந்த அணுகுமுறையால் இது மிகவும் கடினமாக இருக்கும். குறைந்தபட்சம், தொகுத்தல் மற்றும் தானியங்கி வரிசைப்படுத்தல் இன்னும் தேவைப்படும். இது அணுகுமுறையின் பயனுள்ள அம்சம் மற்றும் சில சந்தர்ப்பங்களில் ஒரு தீமை.
2. கட்டமைப்பு உருவாக்கம். ஒரு தானியங்கி கருவி மூலம் கட்டமைப்பு கோப்பு உருவாக்கப்பட்டால், உருவாக்க ஸ்கிரிப்டை ஒருங்கிணைக்க கூடுதல் முயற்சிகள் தேவைப்படலாம்.
3. கருவிகள். தற்போது, ​​உள்ளமைவுடன் வேலை செய்ய வடிவமைக்கப்பட்ட பயன்பாடுகள் மற்றும் நுட்பங்கள் உரை கோப்புகளை அடிப்படையாகக் கொண்டவை. தொகுக்கப்பட்ட கட்டமைப்பில் இது போன்ற அனைத்து பயன்பாடுகள்/தொழில்நுட்பங்கள் கிடைக்காது.
4. அணுகுமுறைகளில் மாற்றம் தேவை. டெவலப்பர்கள் மற்றும் டெவொப்ஸ் டெக்ஸ்ட் பைல்களுக்குப் பழக்கப்பட்டவர்கள். உள்ளமைவைத் தொகுக்கும் யோசனை சற்று எதிர்பாராததாகவும் அசாதாரணமாகவும் இருக்கலாம் மற்றும் நிராகரிப்பை ஏற்படுத்தலாம்.
5. உயர்தர வளர்ச்சி செயல்முறை தேவை. தொகுக்கப்பட்ட உள்ளமைவை வசதியாகப் பயன்படுத்த, பயன்பாட்டை (CI/CD) கட்டமைக்கும் மற்றும் வரிசைப்படுத்தும் செயல்முறையின் முழு தானியங்கும் அவசியம். இல்லையெனில் அது மிகவும் சிரமமாக இருக்கும்.

தொகுக்கப்பட்ட கட்டமைப்பின் யோசனையுடன் தொடர்பில்லாத, கருதப்படும் உதாரணத்தின் பல வரம்புகளிலும் நாம் வாழ்வோம்:

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

முடிவுக்கு

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

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

கருதப்பட்ட அணுகுமுறையை விரிவாக்கலாம்:

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

ஒப்புதல்கள்

வரைவு கட்டுரையை ஆக்கப்பூர்வமாக விமர்சித்த ஆண்ட்ரி சக்சோனோவ், பாவெல் போபோவ் மற்றும் அன்டன் நெகேவ் ஆகியோருக்கு நன்றி தெரிவிக்க விரும்புகிறேன்.

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