የተከፋፈለ ስርዓት ሊጣመር የሚችል ውቅር

በዚህ ልጥፍ ውስጥ የተከፋፈለ ስርዓት ውቅርን የሚያስተናግድበትን አስደሳች መንገድ ማጋራት እንፈልጋለን።
ውቅሩ በአስተማማኝ ሁኔታ በቀጥታ በ Scala ቋንቋ ነው የሚወከለው። አንድ ምሳሌ ትግበራ በዝርዝር ተገልጿል. በአጠቃላይ የእድገት ሂደት ላይ ተጽእኖን ጨምሮ የተለያዩ የውሳኔ ሃሳቦች ተብራርተዋል.

(በሩሲያኛ)

መግቢያ

ጠንካራ የተከፋፈሉ ስርዓቶችን መገንባት በሁሉም አንጓዎች ላይ ትክክለኛ እና ወጥነት ያለው ውቅር መጠቀምን ይጠይቃል። የተለመደው መፍትሔ የጽሑፍ ማሰማራት መግለጫን (ቴራፎርም፣ ሊቻል የሚችል ወይም ተመሳሳይ የሆነ ነገር) እና በራስ-ሰር የሚመነጩ የውቅር ፋይሎችን (ብዙውን ጊዜ - ለእያንዳንዱ መስቀለኛ መንገድ/ሚና) መጠቀም ነው። በእያንዳንዱ የግንኙነት አንጓዎች ላይ ተመሳሳይ ስሪቶች ተመሳሳይ ፕሮቶኮሎችን መጠቀም እንፈልጋለን (አለበለዚያ ተኳኋኝነት ችግሮች ያጋጥሙናል)። በJVM ዓለም ይህ ማለት ቢያንስ የመልእክት መላላኪያ ቤተ-መጽሐፍት በሁሉም የመገናኛ ኖዶች ላይ አንድ አይነት ስሪት መሆን አለበት ማለት ነው።

ስርዓቱን ስለመሞከርስ? እርግጥ ነው፣ ወደ ውህደት ፈተናዎች ከመምጣታችን በፊት ለሁሉም አካላት የዩኒት ፈተናዎች ሊኖረን ይገባል። የፈተና ውጤቶችን በ runtime ላይ ለማውጣት እንድንችል የሁሉም ቤተ-መጻሕፍት ስሪቶች በሁለቱም የሩጫ ጊዜ እና የሙከራ አካባቢዎች ተመሳሳይ መያዛቸውን ማረጋገጥ አለብን።

የውህደት ሙከራዎችን በሚያካሂዱበት ጊዜ በሁሉም አንጓዎች ላይ አንድ አይነት የመማሪያ መንገድ እንዲኖርዎት ብዙ ጊዜ ቀላል ነው። ተመሳሳይ የክፍል ዱካ በማሰማራት ላይ መጠቀሙን ማረጋገጥ አለብን። (በተለያዩ አንጓዎች ላይ የተለያዩ የክፍል ዱካዎችን መጠቀም ይቻላል፣ነገር ግን ይህን ውቅር ለመወከል እና በትክክል ለማሰማራት የበለጠ ከባድ ነው።

ውቅረት ከሶፍትዌሩ ጋር አብሮ የመሻሻል አዝማሚያ አለው። የተለያዩ ነገሮችን ለመለየት ብዙ ጊዜ ስሪቶችን እንጠቀማለን።
የሶፍትዌር ዝግመተ ለውጥ ደረጃዎች. በስሪት አስተዳደር ስር ያለውን ውቅረት ለመሸፈን እና የተለያዩ ውቅሮችን ከአንዳንድ መለያዎች ጋር መለየት ምክንያታዊ ይመስላል። በምርት ውስጥ አንድ ውቅረት ብቻ ካለ ነጠላ ሥሪትን እንደ መለያ ልንጠቀም እንችላለን። አንዳንድ ጊዜ በርካታ የምርት አካባቢዎች ሊኖረን ይችላል። እና ለእያንዳንዱ አካባቢ የተለየ የማዋቀሪያ ቅርንጫፍ ሊያስፈልገን ይችላል። ስለዚህ ውቅረቶች ልዩ ልዩ ውቅሮችን ለመለየት በቅርንጫፍ እና ስሪት ሊሰየሙ ይችላሉ። እያንዳንዱ የቅርንጫፍ መለያ እና ሥሪት በእያንዳንዱ መስቀለኛ መንገድ ላይ ካሉ የተከፋፈሉ ኖዶች፣ ወደቦች፣ የውጪ ሀብቶች፣ የክፍል ዱካ ቤተመፃሕፍት ነጠላ ጥምር ጋር ይዛመዳል። እዚህ ነጠላውን ቅርንጫፍ ብቻ እንሸፍናለን እና አወቃቀሮችን በሶስት አካል አስርዮሽ ስሪት (1.2.3) እንለያለን፣ ልክ እንደ ሌሎች ቅርሶች።

በዘመናዊ አካባቢዎች የማዋቀሪያ ፋይሎች ከአሁን በኋላ በእጅ አልተሻሻሉም። በተለምዶ እኛ እንፈጥራለን
በማሰማራት ጊዜ ፋይሎችን ማዋቀር እና በፍጹም አትንካቸው በኋላ. ስለዚህ ለምንድነው አሁንም ለምንድነው ለማዋቀር ፋይሎች የጽሁፍ ቅርጸት የምንጠቀመው? አዋጭ አማራጭ አወቃቀሩን በማጠናቀር ክፍል ውስጥ ማስቀመጥ እና በማጠናቀር-ጊዜ ውቅር ማረጋገጥ ጥቅም ማግኘት ነው።

በዚህ ልኡክ ጽሁፍ ውስጥ አወቃቀሩን በተቀነባበረ ቅርስ ውስጥ የመጠበቅን ሀሳብ እንመረምራለን.

ሊጣመር የሚችል ውቅር

በዚህ ክፍል ውስጥ የስታቲክ ውቅረት ምሳሌን እንነጋገራለን. ሁለት ቀላል አገልግሎቶች - የ echo አገልግሎት እና የ echo አገልግሎት ደንበኛ እየተዋቀሩ እና እየተተገበሩ ናቸው። ከዚያም ከሁለቱም አገልግሎቶች ጋር ሁለት የተለያዩ የተከፋፈሉ ስርዓቶች በቅጽበት ይደረጋሉ. አንደኛው ለአንድ ነጠላ መስቀለኛ መንገድ ውቅር ሲሆን ሌላኛው ደግሞ ለሁለት አንጓዎች ውቅር ነው።

የተለመደው የተከፋፈለ ስርዓት ጥቂት አንጓዎችን ያካትታል. አንጓዎቹ አንዳንድ ዓይነቶችን በመጠቀም ሊታወቁ ይችላሉ-

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-ቢት እሴቶች ብቻ እንዲኖራቸው ተፈቅዶለታል። ለዚህ ውቅረት አቀራረብ ይህንን ቤተ-መጽሐፍት ለመጠቀም ምንም መስፈርት የለም። ልክ በጣም ጥሩ የሚስማማ ይመስላል።

ለኤችቲቲፒ (REST) ​​እኛም የአገልግሎቱን መንገድ ልንፈልግ እንችላለን፡-

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

የፓንተም ዓይነት

በማጠናቀር ጊዜ ፕሮቶኮልን ለመለየት የአይነት ክርክርን የማወጅ Scala ባህሪን እየተጠቀምን ነው። Protocol በክፍል ውስጥ ጥቅም ላይ የማይውል. የሚባል ነገር ነው። የፋንተም ዓይነት. በሂደት ላይ የፕሮቶኮል መለያ ምሳሌ እምብዛም አያስፈልገንም፣ ለዚያም ነው የማናከማችው። በማጠናቀር ጊዜ ይህ ፋንተም ዓይነት ተጨማሪ ዓይነት ደህንነትን ይሰጣል። በተሳሳተ ፕሮቶኮል ወደብ ማለፍ አንችልም።

በብዛት ጥቅም ላይ ከዋሉት ፕሮቶኮሎች አንዱ REST API ከJson ተከታታይነት ጋር ነው፡-

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

የት RequestMessage ደንበኛ ወደ አገልጋይ መላክ የሚችላቸው መሰረታዊ የመልእክት አይነት ነው። ResponseMessage የአገልጋይ ምላሽ መልእክት ነው። በእርግጥ የግንኙነት ፕሮቶኮሉን በሚፈለገው ትክክለኛነት የሚገልጹ ሌሎች የፕሮቶኮል መግለጫዎችን ልንፈጥር እንችላለን።

ለዚህ ልጥፍ ዓላማ ቀለል ያለ የፕሮቶኮሉን ስሪት እንጠቀማለን፡-

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

በዚህ የፕሮቶኮል ጥያቄ መልእክት በዩአርኤል ላይ ተያይዟል እና የምላሽ መልእክት እንደ ግልጽ ሕብረቁምፊ ይመለሳል።

የአገልግሎት ውቅር በአገልግሎት ስም፣ በወደቦች ስብስብ እና በአንዳንድ ጥገኞች ሊገለጽ ይችላል። በ Scala ውስጥ እነዚህን ሁሉ አካላት እንዴት መወከል እንደሚቻል ጥቂት ሊሆኑ የሚችሉ መንገዶች አሉ (ለምሳሌ፣ 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) እና በኮንክሪት ውቅረት ውስጥ ከዘለልን እንደ ነባሪ እሴት ጥቅም ላይ ይውላል.

በ echo አገልግሎት ደንበኛ ውቅር ላይ ጥገኝነትን ማወጅ እንችላለን፡-

  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. ከማሰማራቱ በፊት ትክክለኛ አድራሻዎችን ካወቅን ፣ በመስቀለኛ አስተናጋጅ ቅጽበት ፣ ከዚያ የ Scala ኮድን ከትክክለኛ አድራሻዎች ጋር ማመንጨት እና በኋላ ግንባታውን ማካሄድ እንችላለን (ይህም የሰዓት ቼኮችን ያጠናቅራል እና ከዚያ የውህደት ሙከራ ስብስብን ያካሂዳል)። በዚህ አጋጣሚ የካርታ ስራአችን በስታቲስቲክስ የሚታወቅ እና ለመሳሰሉት ቀላል ሊሆን ይችላል። 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, የ echo ደንበኛ ከተዋቀረ የመጨረሻ ቆይታ በኋላ ያበቃል። ይመልከቱ ማስጀመሪያ መተግበሪያ ዝርዝሮችን ለማግኘት.

አጠቃላይ የእድገት ሂደት

ይህ አካሄድ ከውቅረት ጋር የምንሰራበትን መንገድ እንዴት እንደሚለውጥ እንይ።

እንደ ኮድ ማዋቀሩ ተሰብስቦ አንድ ቅርስ ይሠራል። የውቅረት ቅርሶችን ከሌሎች የኮድ ቅርሶች መለየት ምክንያታዊ ይመስላል። ብዙውን ጊዜ በተመሳሳዩ ኮድ መሠረት ላይ ብዙ ውቅሮች ሊኖረን ይችላል። እና በእርግጥ ፣ የተለያዩ የውቅረት ቅርንጫፎች በርካታ ስሪቶች ሊኖሩን ይችላሉ። በአንድ ውቅር ውስጥ የተወሰኑ የቤተ-መጻህፍት ስሪቶችን መምረጥ እንችላለን እና ይህን ውቅር ባስቀመጥን ቁጥር ይህ ቋሚ ሆኖ ይቆያል።

የውቅረት ለውጥ የኮድ ለውጥ ይሆናል። ስለዚህ በተመሳሳይ የጥራት ማረጋገጫ ሂደት መሸፈን አለበት፡-

ቲኬት -> PR -> ግምገማ -> ውህደት -> ቀጣይነት ያለው ውህደት -> ቀጣይነት ያለው ማሰማራት

የአቀራረብ ዘዴዎች የሚከተሉት ውጤቶች አሉ.

1. ውቅሩ ለአንድ የተወሰነ የስርዓት ምሳሌ ወጥነት ያለው ነው። በአንጓዎች መካከል ትክክል ያልሆነ ግንኙነት ለመፍጠር ምንም መንገድ ያለ አይመስልም።
2. በአንድ መስቀለኛ መንገድ ውስጥ ውቅረትን መቀየር ቀላል አይደለም. አንዳንድ የጽሑፍ ፋይሎችን ወደ ውስጥ ለመግባት እና ለመለወጥ ምክንያታዊ ያልሆነ ይመስላል. ስለዚህ የውቅረት መንሸራተት አነስተኛ ይሆናል።
3. አነስተኛ የውቅረት ለውጦችን ማድረግ ቀላል አይደለም.
4. አብዛኛዎቹ የውቅረት ለውጦች ተመሳሳይ የእድገት ሂደትን ይከተላሉ፣ እና የተወሰነ ግምገማን ያልፋል።

ለምርት ውቅር የተለየ ማከማቻ ያስፈልገናል? የምርት አወቃቀሩ ብዙ ሰዎች እንዳይደርሱበት ልናደርገው የምንፈልገውን ሚስጥራዊነት ያለው መረጃ ሊይዝ ይችላል። ስለዚህ የምርት አወቃቀሩን የሚያካትት የተገደበ መዳረሻ ያለው የተለየ ማከማቻ ማስቀመጥ ጠቃሚ ሊሆን ይችላል። አወቃቀሩን በሁለት ክፍሎች ልንከፍለው እንችላለን-አንደኛው በጣም ክፍት የሆኑ የምርት መለኪያዎችን የያዘ እና የውቅረት ሚስጥራዊ ክፍል የያዘ። ይህ ለአብዛኛዎቹ ገንቢዎች ለአብዛኞቹ መመዘኛዎች መዳረስ ያስችላል፣ ነገር ግን የእውነተኛ ጥንቃቄን የሚገድብ ነው። በነባሪ የመለኪያ እሴቶች አማካኝነት መካከለኛ ባህሪያትን በመጠቀም ይህንን ማከናወን ቀላል ነው።

ልዩነቶች

ከሌሎች የውቅረት አስተዳደር ቴክኒኮች ጋር ሲወዳደር የታቀደው አካሄድ ጥቅሙንና ጉዳቱን እንይ።

በመጀመሪያ ደረጃ፣ ውቅረትን ለማስተናገድ በታቀደው መንገድ ለተለያዩ ገጽታዎች ጥቂት አማራጮችን እንዘረዝራለን።

1. በዒላማው ማሽን ላይ የጽሑፍ ፋይል.
2. የተማከለ ቁልፍ-እሴት ማከማቻ (እንደ etcd/zookeeper).
3. እንደገና ሳይጀመር እንደገና ሊዋቀሩ/ሊጀመሩ የሚችሉ ንዑስ የሂደት ክፍሎች።
4. ከቅርስ እና የስሪት ቁጥጥር ውጭ ማዋቀር።

የጽሑፍ ፋይል ከአድ-ሆክ ጥገናዎች አንፃር አንዳንድ ተለዋዋጭነትን ይሰጣል። የስርዓት አስተዳዳሪ ወደ ኢላማው መስቀለኛ መንገድ መግባት፣ ለውጥ ማድረግ እና በቀላሉ አገልግሎቱን እንደገና ማስጀመር ይችላል። ይህ ለትላልቅ ስርዓቶች ጥሩ ላይሆን ይችላል. ከለውጡ በስተጀርባ ምንም ዱካ አልቀረም። ለውጡ በሌላ ጥንድ ዓይኖች አይገመግምም. የለውጡን መንስኤ ምን እንደሆነ ለማወቅ አስቸጋሪ ሊሆን ይችላል። አልተፈተነም። ከተከፋፈለው የስርዓት እይታ አንድ አስተዳዳሪ በሌሎቹ አንጓዎች ውስጥ ያለውን ውቅረት ማዘመን በቀላሉ ሊረሳ ይችላል።

(Btw፣ ውሎ አድሮ የጽሑፍ ማዋቀር ፋይሎችን መጠቀም መጀመር የሚያስፈልግ ከሆነ፣ ያንኑ ሊፈጥር የሚችል ተንታኝ + አረጋጋጭ ማከል ብቻ አለብን። Config ይተይቡ እና ያ የጽሑፍ ውቅሮችን መጠቀም ለመጀመር በቂ ነው። ይህ ደግሞ የማጠናቀር-ጊዜ ውቅር ውስብስብነት ከጽሑፍ-ተኮር ውቅሮች ውስብስብነት ትንሽ ያነሰ መሆኑን ያሳያል፣ ምክንያቱም በጽሑፍ ላይ የተመሠረተ ሥሪት አንዳንድ ተጨማሪ ኮድ እንፈልጋለን።)

የተማከለ ቁልፍ-እሴት ማከማቻ የመተግበሪያ ሜታ መለኪያዎችን ለማሰራጨት ጥሩ ዘዴ ነው። እዚህ እንደ የውቅር እሴቶች የምንቆጥራቸውን እና ውሂብ ብቻ ምን እንደሆነ ማሰብ አለብን። ተግባር ተሰጥቷል። C => A => B ብዙ ጊዜ የማይለዋወጡ እሴቶች ብለን እንጠራቸዋለን C "ማዋቀር"፣ በተደጋጋሚ ውሂብ ሲቀየር A - ውሂብ ብቻ ያስገቡ። ውቅር ከመረጃው ቀደም ብሎ ለተግባሩ መቅረብ አለበት። A. ይህን ሃሳብ ስንመለከት የውቅር ውሂብን ከውሂብ ለመለየት ምን ጥቅም ላይ እንደሚውል የሚጠበቀው ድግግሞሽ ነው ማለት እንችላለን። እንዲሁም ውሂብ በተለምዶ ከአንድ ምንጭ (ተጠቃሚ) እና ውቅረት የሚመጣው ከሌላ ምንጭ (አስተዳዳሪ) ነው። ከመነሻው ሂደት በኋላ ሊለወጡ የሚችሉ መለኪያዎችን ማስተናገድ የመተግበሪያውን ውስብስብነት መጨመር ያመጣል. ለእንደዚህ አይነት መመዘኛዎች የመላኪያ ስልታቸውን፣ መተንተን እና ማረጋገጥ፣ የተሳሳቱ እሴቶችን ማስተናገድ አለብን። ስለዚህ የፕሮግራሙን ውስብስብነት ለመቀነስ በሂደት ላይ ሊለወጡ የሚችሉትን መለኪያዎች (ወይም ሙሉ በሙሉ ማስቀረት) ብንቀንስ ይሻላል።

ከዚህ ልጥፍ አንፃር በቋሚ እና ተለዋዋጭ መለኪያዎች መካከል ልዩነት መፍጠር አለብን። የአገልግሎት አመክንዮ በሂደት ጊዜ የአንዳንድ ግቤቶችን ብርቅ ለውጥ የሚፈልግ ከሆነ ተለዋዋጭ መለኪያዎች ልንላቸው እንችላለን። አለበለዚያ እነሱ የማይንቀሳቀሱ ናቸው እና የታቀደውን አካሄድ በመጠቀም ሊዋቀሩ ይችላሉ. ለተለዋዋጭ መልሶ ማዋቀር ሌሎች አካሄዶች ሊያስፈልግ ይችላል። ለምሳሌ፣ የስርአቱ ክፍሎች የተከፋፈለ ስርዓትን የተለያዩ ሂደቶችን እንደገና ለማስጀመር በተመሳሳይ መልኩ በአዲሱ የውቅር መለኪያዎች እንደገና ሊጀመሩ ይችላሉ።
(የእኔ ትሁት አስተያየት የስርዓቱን ውስብስብነት ስለሚጨምር የሩጫ ጊዜ ዳግም ማዋቀርን ማስወገድ ነው።
እንደገና የማስጀመር ሂደቶችን በስርዓተ ክወና ድጋፍ ላይ ብቻ መተማመን የበለጠ ቀላል ሊሆን ይችላል። ምንም እንኳን ሁልጊዜ ላይሆን ይችላል.)

አንዳንድ ጊዜ ሰዎች ተለዋዋጭ ውቅር (ያለ ሌሎች ምክንያቶች) ተለዋዋጭ ውቅር እንዲያስቡ የሚያደርግ የማይንቀሳቀስ ውቅረትን የመጠቀም አንዱ አስፈላጊ ገጽታ በውቅረት ማሻሻያ ወቅት የአገልግሎት መቋረጥ ነው። በእርግጥ በስታቲክ ውቅረት ላይ ለውጦችን ማድረግ ካለብን አዳዲስ እሴቶች ውጤታማ እንዲሆኑ ስርዓቱን እንደገና ማስጀመር አለብን። ለተለያዩ ስርዓቶች የእረፍት ጊዜ መስፈርቶች ይለያያሉ, ስለዚህ ያን ያህል ወሳኝ ላይሆን ይችላል. አስፈላጊ ከሆነ, ለማንኛውም ስርዓት እንደገና እንዲጀመር አስቀድመን ማቀድ አለብን. ለምሳሌ፣ መተግበር እንችላለን AWS ELB ግንኙነት መፍሰስ. በዚህ ሁኔታ ስርዓቱን እንደገና ማስጀመር በሚያስፈልገን ጊዜ፣ የስርዓቱን አዲስ ምሳሌ በትይዩ እንጀምራለን፣ ከዚያም ELB ወደ እሱ እንቀይራለን፣ አሮጌው ስርዓት ያሉትን ግንኙነቶች እንዲያጠናቅቅ እናደርጋለን።

በቅሪተ አካል ውስጥ ወይም በውጭ ውቅር ስለማቆየትስ? ውቅርን በቅርስ ውስጥ ማቆየት ማለት በአብዛኛዎቹ ሁኔታዎች ይህ ውቅር ከሌሎች ቅርሶች ጋር ተመሳሳይ የጥራት ማረጋገጫ ሂደት አለፈ ማለት ነው። ስለዚህ አንድ ሰው አወቃቀሩ ጥሩ ጥራት ያለው እና እምነት የሚጣልበት መሆኑን እርግጠኛ ሊሆን ይችላል. በተቃራኒው ውቅር በተለየ ፋይል ውስጥ ማን እና ለምን በዚያ ፋይል ላይ ለውጦች እንዳደረጉ ምንም ዱካዎች የሉም ማለት ነው። ይህ አስፈላጊ ነው? ለአብዛኛዎቹ የምርት ስርዓቶች የተረጋጋ እና ከፍተኛ ጥራት ያለው ውቅር ቢኖረው ይሻላል ብለን እናምናለን።

የቅሪተ አካል ሥሪት መቼ እንደተፈጠረ፣ ምን ዓይነት እሴቶችን እንደያዘ፣ ምን አይነት ባህሪያት እንደነቁ/ተሰናከሉ፣ በማዋቀሩ ላይ እያንዳንዱን ለውጥ የማድረግ ኃላፊነት የነበረው ማን እንደሆነ ለማወቅ ያስችላል። በቅርስ ውስጥ ውቅር ለማቆየት የተወሰነ ጥረት ሊጠይቅ ይችላል እና የንድፍ ምርጫ ነው።

ጥቅሞች እና ጉዳቶች

እዚህ አንዳንድ ጥቅሞችን ማጉላት እና የታቀደው አካሄድ አንዳንድ ጉዳቶችን መወያየት እንፈልጋለን።

ጥቅሞች

የተጠናቀቀ የተከፋፈለ ስርዓት የተዋሃደ ውቅር ባህሪዎች

1. የማይንቀሳቀስ የማዋቀሪያ ፍተሻ። ይህ ከፍተኛ በራስ የመተማመን ስሜትን ይሰጣል ፣ ይህም አወቃቀሩ ትክክል ነው ከዓይነት ገደቦች።
2. የበለጸገ የማዋቀር ቋንቋ። በተለምዶ ሌሎች የማዋቀር አቀራረቦች በአብዛኛዎቹ ተለዋዋጭ ምትክ ብቻ የተገደቡ ናቸው።
   Scala ን በመጠቀም ውቅረትን የተሻለ ለማድረግ ሰፊ የቋንቋ ባህሪያትን መጠቀም ይችላል። ለምሳሌ፣ ነባሪ እሴቶችን ለማቅረብ ባህሪያትን መጠቀም እንችላለን፣ የተለያዩ ወሰን ለማዘጋጀት እቃዎችን፣ ልንጠቅስ እንችላለን valበውጫዊ ወሰን (DRY) አንድ ጊዜ ብቻ ይገለጻል። ቀጥተኛ ቅደም ተከተሎችን ወይም የተወሰኑ ክፍሎችን (አብነቶችን) መጠቀም ይቻላል (Seq, Map, ወዘተ.).
3. DSL Scala ለ DSL ጸሃፊዎች ጥሩ ድጋፍ አለው። የመጨረሻው ውቅረት ቢያንስ በጎራ ተጠቃሚዎች ሊነበብ የሚችል እንዲሆን እነዚህን ባህሪያት የበለጠ ምቹ እና ለዋና ተጠቃሚ ተስማሚ የሆነ የውቅር ቋንቋ ለመመስረት እነዚህን ባህሪያት መጠቀም ይችላል።
4. በአንጓዎች ላይ ታማኝነት እና ወጥነት። ለጠቅላላው የተከፋፈለው ስርዓት በአንድ ቦታ ላይ ማዋቀር ከሚያስገኛቸው ጥቅሞች አንዱ ሁሉም እሴቶች አንድ ጊዜ በጥብቅ የተገለጹ እና እኛ በምንፈልጋቸው ቦታዎች ሁሉ እንደገና ጥቅም ላይ መዋል አለባቸው። እንዲሁም ደህንነቱ የተጠበቀ ወደብ መግለጫዎችን ይተይቡ በሁሉም ትክክለኛ አወቃቀሮች የስርዓቱ አንጓዎች አንድ አይነት ቋንቋ እንደሚናገሩ ያረጋግጡ። አንዳንድ አገልግሎቶችን መስጠትን ለመርሳት አስቸጋሪ የሚያደርገው በመስቀለኛ መንገድ መካከል ግልጽ ጥገኞች አሉ።
5. ከፍተኛ ጥራት ያላቸው ለውጦች. ውቅረትን የማለፍ አጠቃላይ አቀራረብ በተለመደው የ PR ሂደት ውስጥ ይለወጣል ከፍተኛ የጥራት ደረጃዎች በማዋቀርም ውስጥ።
6. በተመሳሳይ ጊዜ ውቅር ለውጦች. በማዋቀር ላይ ማንኛቸውም ለውጦችን ስናደርግ አውቶማቲክ ማሰማራት ሁሉም አንጓዎች እየተዘመኑ መሆናቸውን ያረጋግጣል።
7. የመተግበሪያ ማቅለል. አፕሊኬሽኑ ውቅርን መተንተን እና ማረጋገጥ እና የተሳሳቱ የውቅር እሴቶችን ማስተናገድ አያስፈልገውም። ይህ አጠቃላይ አፕሊኬሽኑን ቀላል ያደርገዋል። (አንዳንድ ውስብስብነት መጨመር በራሱ አወቃቀሩ ውስጥ ነው፣ ነገር ግን ለደህንነት ነቅቶ የሚደረግ የንግድ ልውውጥ ነው።) ወደ ተራ ውቅር መመለስ በጣም ቀላል ነው - የጎደሉትን ቁርጥራጮች ይጨምሩ። በተጠናቀረ ውቅር መጀመር እና የተጨማሪ ክፍሎችን መተግበር ለሌላ ጊዜ ማስተላለፍ ቀላል ነው።
8. የተሻሻለ ውቅር። የውቅረት ለውጦች ተመሳሳይ የዕድገት ሂደት ስለሚከተሉ፣ በውጤቱም ልዩ የሆነ ሥሪት ያለው ቅርስ እናገኛለን። አስፈላጊ ከሆነ ውቅረትን ወደ ኋላ ለመቀየር ያስችለናል. ከአንድ አመት በፊት ጥቅም ላይ የዋለውን ውቅረት እንኳን ማሰማራት እንችላለን እና በትክክል በተመሳሳይ መንገድ ይሰራል። የተረጋጋ ውቅር የተከፋፈለው ስርዓት ትንበያ እና አስተማማኝነት ያሻሽላል። አወቃቀሩ በተጠናቀረበት ጊዜ ተስተካክሏል እና በቀላሉ በምርት ስርዓት ላይ ሊጣስ አይችልም.
9. ሞዱላሪቲ. የታቀደው ማዕቀፍ ሞጁል ነው እና ሞጁሎች በተለያዩ መንገዶች ሊጣመሩ ይችላሉ።
   የተለያዩ አወቃቀሮችን ይደግፉ (አቀማመጦች / አቀማመጦች). በተለይም አነስተኛ መጠን ያለው ነጠላ የመስቀለኛ መንገድ አቀማመጥ እና ትልቅ መጠን ያለው ባለብዙ መስቀለኛ መንገድ አቀማመጥ ሊኖር ይችላል። ብዙ የምርት አቀማመጦች መኖራቸው ምክንያታዊ ነው.
10. በመሞከር ላይ። ለሙከራ ዓላማዎች አንድ ሰው የማስመሰል አገልግሎትን ሊተገበር እና ደህንነቱ በተጠበቀ መንገድ እንደ ጥገኛ ሊጠቀምበት ይችላል። የተለያዩ ክፍሎች ያላቸው የተለያዩ ክፍሎች በፌዝ የተተኩ ጥቂት የተለያዩ የሙከራ አቀማመጦች በአንድ ጊዜ ሊቆዩ ይችላሉ።
11. የውህደት ሙከራ. አንዳንድ ጊዜ በተከፋፈሉ ስርዓቶች ውስጥ የውህደት ሙከራዎችን ለማካሄድ አስቸጋሪ ነው። የተሟላውን የተከፋፈለውን ስርዓት ደህንነቱ የተጠበቀ ውቅረት ለመተየብ የተገለፀውን አቀራረብ በመጠቀም ሁሉንም የተከፋፈሉ ክፍሎችን በአንድ አገልጋይ ላይ መቆጣጠር በሚቻል መንገድ ማሄድ እንችላለን። ሁኔታውን መኮረጅ ቀላል ነው።
    ከአገልግሎቶቹ አንዱ የማይገኝ ከሆነ።

ጥቅምና

የተጠናቀረው የውቅረት አቀራረብ ከ"መደበኛ" ውቅር የተለየ ነው እና ሁሉንም ፍላጎቶች ላይያሟላ ይችላል። የተቀናበረው መዋቅር አንዳንድ ጉዳቶች እነኚሁና፡

1. የማይንቀሳቀስ ውቅር። ለሁሉም መተግበሪያዎች ተስማሚ ላይሆን ይችላል። በአንዳንድ ሁኔታዎች ሁሉንም የደህንነት እርምጃዎች በማለፍ በምርት ውስጥ ያለውን ውቅረት በፍጥነት ማስተካከል ያስፈልጋል። ይህ አቀራረብ የበለጠ አስቸጋሪ ያደርገዋል. በማዋቀር ላይ ማንኛውንም ለውጥ ካደረጉ በኋላ ማጠናቀር እና እንደገና ማሰማራት ያስፈልጋል። ይህ ሁለቱም ባህሪው እና ሸክሙ ነው.
2. የማዋቀር ትውልድ. ውቅረት በአንዳንድ አውቶማቲክ መሳሪያዎች ሲፈጠር ይህ አካሄድ ተከታይ ማጠናቀርን ይፈልጋል (ይህም በተራው ሊሳካ ይችላል)። ይህንን ተጨማሪ እርምጃ በግንባታ ስርዓቱ ውስጥ ለማዋሃድ ተጨማሪ ጥረት ሊጠይቅ ይችላል።
3. መሳሪያዎች. ዛሬ በጽሁፍ ላይ በተመሰረቱ አወቃቀሮች ላይ የሚመሰረቱ ብዙ መሳሪያዎች ጥቅም ላይ ይውላሉ። ከነሱ ጥቂቶቹ
   ውቅረት ሲጠናቀር ተግባራዊ አይሆንም።
4. የአስተሳሰብ ለውጥ ያስፈልጋል። ገንቢዎች እና DevOps የጽሑፍ ውቅር ፋይሎችን ያውቃሉ። ውቅረትን የማጠናቀር ሀሳብ ለእነሱ እንግዳ ሊመስል ይችላል።
5. የተጠናቀረ ውቅረትን ከማስተዋወቅዎ በፊት ከፍተኛ ጥራት ያለው የሶፍትዌር ልማት ሂደት ያስፈልጋል።

የተተገበረው ምሳሌ አንዳንድ ገደቦች አሉ፡-

1. በመስቀለኛ ትግበራ ያልተፈለገ ተጨማሪ ውቅረት ካቀረብን፣ አቀናባሪ የጠፋውን ትግበራ ለማወቅ አይረዳንም። ይህንን በመጠቀም ሊፈታ ይችላል HList ወይም ADTs (የጉዳይ ክፍሎች) ከባህሪያት እና የኬክ ጥለት ይልቅ የመስቀለኛ መንገድ ውቅር።
2. በማዋቀር ፋይል ውስጥ አንዳንድ ቦይለር ማቅረብ አለብን፡(package, import, object መግለጫዎች;
   override defነባሪ እሴቶች ላላቸው ግቤቶች)። ይህ በከፊል DSL በመጠቀም ሊፈታ ይችላል።
3. በዚህ ልጥፍ ውስጥ ተመሳሳይ የአንጓዎች ስብስቦችን ተለዋዋጭ ዳግም ማዋቀርን አንሸፍንም።

መደምደሚያ

በዚህ ልጥፍ ውስጥ ውቅረትን በቀጥታ በምንጭ ኮድ ውስጥ በአስተማማኝ መንገድ የመወከል ሀሳብ ተወያይተናል። አቀራረቡ በብዙ አፕሊኬሽኖች ውስጥ በ xml እና በሌሎች ጽሑፍ ላይ የተመሰረቱ ውቅሮችን ለመተካት ጥቅም ላይ ሊውል ይችላል። ምንም እንኳን የእኛ ምሳሌ በ Scala ውስጥ ቢተገበርም ወደ ሌሎች ሊዘጋጁ የሚችሉ ቋንቋዎች (እንደ ኮትሊን ፣ ሲ # ፣ ስዊፍት ፣ ወዘተ) ሊተረጎም ይችላል። አንድ ሰው ይህንን አካሄድ በአዲስ ፕሮጀክት ሊሞክር ይችላል እና በጥሩ ሁኔታ የማይስማማ ከሆነ ወደ አሮጌው ፋሽን መንገድ ይቀይሩ።

እርግጥ ነው, የተጠናቀረ ውቅር ከፍተኛ ጥራት ያለው የእድገት ሂደት ይጠይቃል. በምላሹም በተመሳሳይ ከፍተኛ ጥራት ያለው ጠንካራ ውቅር ለማቅረብ ቃል ገብቷል።

ይህ ዘዴ በተለያዩ መንገዶች ሊራዘም ይችላል-

1. የውቅረት ማረጋገጫን ለማካሄድ ማክሮዎችን መጠቀም እና በማንኛውም የንግድ-ሎጂክ ገደቦች ውድቀቶች ጊዜ በማጠናቀር ጊዜ ሊሳካ ይችላል።
2. DSL ውቅርን በጎራ ለተጠቃሚ ምቹ በሆነ መንገድ ለመወከል ሊተገበር ይችላል።
3. ተለዋዋጭ የንብረት አስተዳደር ከራስ-ሰር ውቅር ማስተካከያዎች ጋር። ለምሳሌ፣ የክላስተር ኖዶችን ቁጥር ስናስተካክል ልንፈልጋቸው እንችላለን (1) ኖዶቹ በትንሹ የተሻሻለ ውቅር ለማግኘት፤ (2) የክላስተር አስተዳዳሪ አዲስ የአንጓዎችን መረጃ ለመቀበል።

አመሰግናለሁ

በዚህ ልኡክ ጽሁፍ ረቂቅ ላይ አነሳሽ አስተያየት ስለሰጡኝ አንድሬ ሳክሶኖቭ፣ ፓቬል ፖፖቭ፣ አንቶን ኔሃዬቭ የበለጠ ግልፅ እንዳደርግ የረዱኝን አመሰግናለሁ ማለት እፈልጋለሁ።

ምንጭ: hab.com