ចងក្រងការកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធចែកចាយ

ខ្ញុំចង់ប្រាប់អ្នកនូវយន្តការគួរឱ្យចាប់អារម្មណ៍មួយសម្រាប់ធ្វើការជាមួយការកំណត់រចនាសម្ព័ន្ធនៃប្រព័ន្ធចែកចាយ។ ការកំណត់រចនាសម្ព័ន្ធត្រូវបានតំណាងដោយផ្ទាល់ជាភាសាចងក្រង (Scala) ដោយប្រើប្រភេទសុវត្ថិភាព។ ប្រកាសនេះផ្តល់នូវឧទាហរណ៍នៃការកំណត់រចនាសម្ព័ន្ធបែបនេះ ហើយពិភាក្សាអំពីទិដ្ឋភាពផ្សេងៗនៃការអនុវត្តការកំណត់រចនាសម្ព័ន្ធដែលបានចងក្រងទៅក្នុងដំណើរការអភិវឌ្ឍន៍ទាំងមូល។

(ភាសាអង់គ្លេស)

សេចក្តីណែនាំ

ការកសាងប្រព័ន្ធចែកចាយដែលអាចទុកចិត្តបានមានន័យថាថ្នាំងទាំងអស់ប្រើការកំណត់ត្រឹមត្រូវ ធ្វើសមកាលកម្មជាមួយថ្នាំងផ្សេងទៀត។ បច្ចេកវិទ្យា DevOps (terraform, ansible ឬអ្វីមួយដូចនោះ) ជាធម្មតាត្រូវបានប្រើដើម្បីបង្កើតឯកសារកំណត់រចនាសម្ព័ន្ធដោយស្វ័យប្រវត្តិ (ជាញឹកញាប់ជាក់លាក់សម្រាប់ថ្នាំងនីមួយៗ)។ យើងក៏ចង់ប្រាកដថាថ្នាំងទំនាក់ទំនងទាំងអស់កំពុងប្រើពិធីការដូចគ្នា (រួមទាំងកំណែដូចគ្នា)។ បើមិនដូច្នោះទេ ភាពមិនឆបគ្នានឹងត្រូវបានបង្កើតឡើងនៅក្នុងប្រព័ន្ធចែកចាយរបស់យើង។ នៅក្នុងពិភព JVM ផលវិបាកមួយនៃតម្រូវការនេះគឺថាកំណែដូចគ្នានៃបណ្ណាល័យដែលមានសារពិធីការត្រូវតែប្រើនៅគ្រប់ទីកន្លែង។

ចុះការសាកល្បងប្រព័ន្ធចែកចាយវិញ? ជាការពិតណាស់ យើងសន្មត់ថាសមាសធាតុទាំងអស់មានការធ្វើតេស្តឯកតា មុនពេលយើងបន្តទៅការធ្វើតេស្តសមាហរណកម្ម។ (ដើម្បីឱ្យយើងបូកសរុបលទ្ធផលតេស្តទៅម៉ោងដំណើរការ យើងក៏ត្រូវផ្តល់សំណុំបណ្ណាល័យដូចគ្នានៅដំណាក់កាលសាកល្បង និងពេលដំណើរការផងដែរ។)

នៅពេលធ្វើការជាមួយការធ្វើតេស្តរួមបញ្ចូល វាច្រើនតែងាយស្រួលប្រើ classpath ដូចគ្នានៅគ្រប់ទីកន្លែងលើថ្នាំងទាំងអស់។ អ្វីដែលយើងត្រូវធ្វើគឺត្រូវប្រាកដថា classpath ដូចគ្នាត្រូវបានប្រើនៅពេលដំណើរការ។ (ខណៈពេលដែលវាអាចធ្វើទៅបានទាំងស្រុងក្នុងការដំណើរការ nodes ផ្សេងគ្នាជាមួយនឹង classpaths ផ្សេងគ្នា វាបន្ថែមភាពស្មុគស្មាញដល់ការកំណត់រចនាសម្ព័ន្ធរួម និងការលំបាកជាមួយនឹងការធ្វើតេស្តដាក់ពង្រាយ និងការរួមបញ្ចូលគ្នា។) សម្រាប់គោលបំណងនៃការបង្ហោះនេះ យើងសន្មត់ថា nodes ទាំងអស់នឹងប្រើ classpath ដូចគ្នា។

ការកំណត់រចនាសម្ព័ន្ធវិវឌ្ឍន៍ជាមួយកម្មវិធី។ យើងប្រើកំណែដើម្បីកំណត់អត្តសញ្ញាណដំណាក់កាលផ្សេងគ្នានៃការវិវត្តកម្មវិធី។ វាហាក់បីដូចជាឡូជីខលក្នុងការកំណត់អត្តសញ្ញាណកំណែផ្សេងគ្នានៃការកំណត់។ ហើយដាក់ការកំណត់រចនាសម្ព័ន្ធដោយខ្លួនឯងនៅក្នុងប្រព័ន្ធត្រួតពិនិត្យកំណែ។ ប្រសិន​បើ​មាន​ការ​កំណត់​រចនាសម្ព័ន្ធ​តែ​មួយ​ក្នុង​ការ​ផលិត​នោះ យើង​អាច​ប្រើ​លេខ​កំណែ​បាន​យ៉ាង​សាមញ្ញ។ ប្រសិនបើយើងប្រើឧទាហរណ៍ផលិតកម្មច្រើន នោះយើងនឹងត្រូវការច្រើនដង
សាខាកំណត់រចនាសម្ព័ន្ធ និងស្លាកបន្ថែមបន្ថែមលើកំណែ (ឧទាហរណ៍ ឈ្មោះសាខា)។ វិធីនេះយើងអាចកំណត់យ៉ាងច្បាស់នូវការកំណត់រចនាសម្ព័ន្ធពិតប្រាកដ។ គ្រឿងសម្គាល់ការកំណត់រចនាសម្ព័ន្ធនីមួយៗមានតែមួយគត់ដែលត្រូវគ្នាទៅនឹងការរួមបញ្ចូលគ្នាជាក់លាក់នៃថ្នាំងដែលបានចែកចាយ ច្រក ធនធានខាងក្រៅ និងកំណែបណ្ណាល័យ។ សម្រាប់គោលបំណងនៃការប្រកាសនេះ យើងនឹងសន្មត់ថាមានសាខាតែមួយ ហើយយើងអាចកំណត់ការកំណត់រចនាសម្ព័ន្ធតាមរបៀបធម្មតាដោយប្រើលេខបីដែលបំបែកដោយចំនុច (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)

ប្រភេទ Phantom

ដើម្បីកំណត់អត្តសញ្ញាណពិធីការនៅពេលចងក្រង យើងប្រើប៉ារ៉ាម៉ែត្រប្រភេទដែលមិនត្រូវបានប្រើក្នុងថ្នាក់។ ការសម្រេចចិត្តនេះគឺដោយសារតែយើងមិនប្រើ protocol instance នៅពេលដំណើរការ ប៉ុន្តែយើងចង់ឱ្យ compiler ពិនិត្យមើលភាពឆបគ្នានៃ protocols។ តាមរយៈការបញ្ជាក់ពិធីការ យើងនឹងមិនអាចឆ្លងផុតសេវាមិនសមរម្យជាការពឹងផ្អែកបានទេ។

ពិធីការទូទៅមួយគឺ REST API ជាមួយនឹង Json serialization៖

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

ដែលជាកន្លែងដែល RequestMessage - ប្រភេទនៃសំណើ, ResponseMessage - ប្រភេទនៃការឆ្លើយតប។
ជាការពិតណាស់ យើងអាចប្រើការពិពណ៌នាពិធីការផ្សេងទៀតដែលផ្តល់នូវភាពត្រឹមត្រូវនៃការពិពណ៌នាដែលយើងត្រូវការ។

សម្រាប់គោលបំណងនៃការបង្ហោះនេះ យើងនឹងប្រើកំណែសាមញ្ញនៃពិធីការ៖

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

នៅទីនេះសំណើគឺជាខ្សែអក្សរដែលបន្ថែមទៅ url ហើយការឆ្លើយតបគឺជាខ្សែអក្សរដែលបានត្រឡប់មកវិញនៅក្នុងតួនៃការឆ្លើយតប HTTP ។

ការកំណត់រចនាសម្ព័ន្ធសេវាកម្មត្រូវបានពិពណ៌នាដោយឈ្មោះសេវាកម្ម ច្រក និងភាពអាស្រ័យ។ ធាតុទាំងនេះអាចត្រូវបានតំណាងនៅក្នុង Scala តាមវិធីជាច្រើន (ឧទាហរណ៍ HList-s, ប្រភេទទិន្នន័យពិជគណិត)។ សម្រាប់គោលបំណងនៃការបង្ហោះនេះ យើងនឹងប្រើគំរូនំ និងតំណាងឱ្យម៉ូឌុលដោយប្រើ traitស។ (លំនាំនំខេកមិនមែនជាធាតុចាំបាច់នៃវិធីសាស្រ្តនេះទេ។ វាគ្រាន់តែជាការអនុវត្តមួយដែលអាចធ្វើទៅបាន។ )

ភាពអាស្រ័យរវាងសេវាកម្មអាចត្រូវបានតំណាងថាជាវិធីសាស្រ្តដែលត្រឡប់ច្រក EndPointថ្នាំងផ្សេងទៀត៖

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

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

ដើម្បីបង្កើតសេវាអេកូ អ្វីទាំងអស់ដែលអ្នកត្រូវការគឺលេខច្រក និងការចង្អុលបង្ហាញថាច្រកនេះគាំទ្រពិធីការអេកូ។ យើង​ប្រហែល​ជា​មិន​បញ្ជាក់​ច្រក​ជាក់លាក់​ទេ ព្រោះ​... លក្ខណៈអនុញ្ញាតឱ្យអ្នកប្រកាសវិធីសាស្រ្តដោយគ្មានការអនុវត្ត (វិធីសាស្រ្តអរូបី) ។ ក្នុងករណីនេះ នៅពេលបង្កើតការកំណត់រចនាសម្ព័ន្ធជាក់ស្តែង អ្នកចងក្រងនឹងតម្រូវឱ្យយើងផ្តល់នូវការអនុវត្តវិធីសាស្ត្រអរូបី និងផ្តល់លេខច្រក។ ដោយសារ​យើង​បាន​អនុវត្ត​វិធីសាស្ត្រ នៅពេល​បង្កើត​ការ​កំណត់​រចនាសម្ព័ន្ធ​ជាក់លាក់ យើង​ប្រហែល​ជា​មិន​បញ្ជាក់​ច្រក​ផ្សេង​ទេ។ តម្លៃលំនាំដើមនឹងត្រូវបានប្រើ។

ក្នុង​ការ​កំណត់​រចនាសម្ព័ន្ធ​អតិថិជន យើង​ប្រកាស​ពី​ភាព​អាស្រ័យ​លើ​សេវា​អេកូ៖

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

ភាពអាស្រ័យគឺមានប្រភេទដូចគ្នាទៅនឹងសេវាកម្មនាំចេញ echoService. ជាពិសេសនៅក្នុងម៉ាស៊ីនភ្ញៀវអេកូ យើងទាមទារពិធីការដូចគ្នា។ ដូច្នេះនៅពេលភ្ជាប់សេវាពីរ យើងអាចប្រាកដថាអ្វីៗនឹងដំណើរការបានត្រឹមត្រូវ។

ការអនុវត្តសេវាកម្ម

មុខងារមួយត្រូវបានទាមទារដើម្បីចាប់ផ្តើម និងបញ្ឈប់សេវាកម្ម។ (សមត្ថភាពក្នុងការបញ្ឈប់សេវាកម្មគឺសំខាន់សម្រាប់ការធ្វើតេស្ត។) ជាថ្មីម្តងទៀត មានជម្រើសជាច្រើនសម្រាប់ការអនុវត្តមុខងារបែបនេះ (ឧទាហរណ៍ យើងអាចប្រើប្រភេទថ្នាក់ដោយផ្អែកលើប្រភេទការកំណត់)។ សម្រាប់គោលបំណងនៃការបង្ហោះនេះ យើងនឹងប្រើគំរូនំខេក។ យើងនឹងតំណាងឱ្យសេវាកម្មដោយប្រើថ្នាក់ cats.Resource, ដោយសារតែ ថ្នាក់នេះផ្តល់នូវមធ្យោបាយដើម្បីធានាការចេញផ្សាយធនធានដោយសុវត្ថិភាពក្នុងករណីមានបញ្ហា។ ដើម្បីទទួលបានធនធាន យើងត្រូវផ្តល់នូវការកំណត់រចនាសម្ព័ន្ធ និងបរិបទពេលដំណើរការដែលត្រៀមរួចជាស្រេច។ មុខងារចាប់ផ្តើមសេវាកម្មអាចមើលទៅដូចនេះ៖

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

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

ដែលជាកន្លែងដែល

• Config - ប្រភេទការកំណត់សម្រាប់សេវាកម្មនេះ។
• AddressResolver - វត្ថុពេលដំណើរការដែលអនុញ្ញាតឱ្យអ្នកស្វែងរកអាសយដ្ឋាននៃថ្នាំងផ្សេងទៀត (សូមមើលខាងក្រោម)

និងប្រភេទផ្សេងទៀតពីបណ្ណាល័យ cats:

• F[_] - ប្រភេទនៃឥទ្ធិពល (ក្នុងករណីសាមញ្ញបំផុត។ F[A] អាចគ្រាន់តែជាមុខងារមួយ។ () => A. នៅក្នុងការប្រកាសនេះយើងនឹងប្រើ cats.IO.)
• Reader[A,B] - ច្រើនឬតិចមានន័យដូចនឹងមុខងារ A => B
• cats.Resource - ធនធានដែលអាចទទួលបាននិងបញ្ចេញ
• Timer - កម្មវិធីកំណត់ម៉ោង (អនុញ្ញាតឱ្យអ្នកដេកលក់មួយរយៈ និងវាស់ចន្លោះពេល)
• ContextShift - អាណាឡូក ExecutionContext
• Applicative - ថ្នាក់ប្រភេទបែបផែនដែលអនុញ្ញាតឱ្យអ្នកបញ្ចូលគ្នានូវផលប៉ះពាល់បុគ្គល (ស្ទើរតែ monad) ។ នៅក្នុងកម្មវិធីស្មុគ្រស្មាញកាន់តែច្រើនវាហាក់ដូចជាល្អជាងក្នុងការប្រើប្រាស់ Monad/ConcurrentEffect.

ដោយប្រើហត្ថលេខាមុខងារនេះ យើងអាចអនុវត្តសេវាកម្មជាច្រើន។ ឧទាហរណ៍ សេវាកម្មដែលមិនធ្វើអ្វីសោះ៖

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

(សង់​ទី​ម៉ែ​ត។ ប្រភពដែលក្នុងនោះសេវាកម្មផ្សេងទៀតត្រូវបានអនុវត្ត - សេវាអេកូ, អតិថិជនអេកូ
и ឧបករណ៍បញ្ជាពេញមួយជីវិត.)

ថ្នាំងគឺជាវត្ថុដែលអាចបើកដំណើរការសេវាកម្មជាច្រើន (ការចាប់ផ្តើមនៃខ្សែសង្វាក់ធនធានត្រូវបានធានាដោយគំរូនំ)៖

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

សូមចំណាំថាយើងកំពុងបញ្ជាក់ប្រភេទជាក់លាក់នៃការកំណត់រចនាសម្ព័ន្ធដែលត្រូវការសម្រាប់ថ្នាំងនេះ។ ប្រសិនបើ​យើង​ភ្លេច​បញ្ជាក់​ប្រភេទ​ការ​កំណត់​មួយ​ដែល​តម្រូវ​ដោយ​សេវាកម្ម​ជាក់លាក់​នោះ​នឹង​មាន​កំហុស​ក្នុង​ការ​ចងក្រង។ ដូចគ្នានេះផងដែរ យើងនឹងមិនអាចចាប់ផ្តើមថ្នាំងបានទេ លុះត្រាតែយើងផ្តល់វត្ថុមួយចំនួននៃប្រភេទសមស្របជាមួយនឹងទិន្នន័យចាំបាច់ទាំងអស់។

ដំណោះស្រាយឈ្មោះម៉ាស៊ីន

ដើម្បីភ្ជាប់ទៅម៉ាស៊ីនពីចម្ងាយ យើងត្រូវការអាសយដ្ឋាន IP ពិតប្រាកដ។ វាអាចទៅរួចដែលអាសយដ្ឋាននឹងត្រូវបានដឹងនៅពេលក្រោយជាងការកំណត់រចនាសម្ព័ន្ធដែលនៅសល់។ ដូច្នេះ​យើង​ត្រូវ​ការ​មុខងារ​ដែល​គូស​លេខ​សម្គាល់​ថ្នាំង​ទៅ​អាសយដ្ឋាន៖

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

មានវិធីជាច្រើនដើម្បីអនុវត្តមុខងារនេះ៖

1. ប្រសិនបើអាសយដ្ឋានត្រូវបានគេស្គាល់ចំពោះយើងមុនពេលដាក់ឱ្យប្រើប្រាស់ នោះយើងអាចបង្កើតកូដ Scala ជាមួយ
   អាសយដ្ឋាន ហើយបន្ទាប់មកដំណើរការការស្ថាបនា។ វានឹងចងក្រង និងដំណើរការការធ្វើតេស្ត។
   ក្នុង​ករណី​នេះ មុខងារ​នឹង​ត្រូវ​បាន​គេ​ស្គាល់​ជា​ឋិតិវន្ត ហើយ​អាច​ត្រូវ​បាន​តំណាង​ក្នុង​កូដ​ជា​ការ​គូសវាស Map[NodeId, NodeAddress].
2. ក្នុងករណីខ្លះ អាសយដ្ឋានពិតប្រាកដត្រូវបានដឹងតែបន្ទាប់ពីថ្នាំងបានចាប់ផ្តើម។
   ក្នុងករណីនេះ យើងអាចអនុវត្ត "សេវារកឃើញ" ដែលដំណើរការមុនថ្នាំងផ្សេងទៀត ហើយថ្នាំងទាំងអស់នឹងចុះឈ្មោះជាមួយសេវាកម្មនេះ និងស្នើសុំអាសយដ្ឋាននៃថ្នាំងផ្សេងទៀត។
3. ប្រសិនបើយើងអាចកែប្រែបាន។ /etc/hostsបន្ទាប់មកអ្នកអាចប្រើឈ្មោះម៉ាស៊ីនដែលបានកំណត់ជាមុន (ដូចជា my-project-main-node и echo-backend) ហើយគ្រាន់តែភ្ជាប់ឈ្មោះទាំងនេះ
   ជាមួយអាសយដ្ឋាន IP កំឡុងពេលដាក់ពង្រាយ។

នៅក្នុងការប្រកាសនេះយើងនឹងមិនពិចារណាករណីទាំងនេះនៅក្នុងលម្អិតបន្ថែមទៀត។ សម្រាប់របស់យើង។
នៅក្នុងឧទាហរណ៍របស់ក្មេងលេង ថ្នាំងទាំងអស់នឹងមានអាសយដ្ឋាន 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'om ហើយ​ថ្នាំង​ម៉ាស៊ីនភ្ញៀវ​នឹង​បិទ​បន្ទាប់ពី​ពេលខ្លះ។ សង់​ទី​ម៉ែ​ត។ កម្មវិធីបើកដំណើរការ.

ដំណើរការអភិវឌ្ឍន៍ទូទៅ

សូមមើលពីរបៀបដែលវិធីសាស្រ្តកំណត់រចនាសម្ព័ន្ធនេះប៉ះពាល់ដល់ដំណើរការអភិវឌ្ឍន៍ទាំងមូល។

ការកំណត់រចនាសម្ព័ន្ធនឹងត្រូវបានចងក្រងជាមួយនឹងកូដដែលនៅសល់ ហើយវត្ថុបុរាណ (.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 Scala មានលក្ខណៈពិសេសភាសាមួយចំនួនដែលធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការបង្កើត DSL ។ វាអាចទៅរួចក្នុងការទាញយកអត្ថប្រយោជន៍ពីលក្ខណៈពិសេសទាំងនេះ និងអនុវត្តភាសាការកំណត់រចនាសម្ព័ន្ធដែលកាន់តែងាយស្រួលសម្រាប់ក្រុមអ្នកប្រើប្រាស់គោលដៅ ដូច្នេះការកំណត់រចនាសម្ព័ន្ធគឺអាចអានបានដោយអ្នកជំនាញដែនយ៉ាងហោចណាស់។ ជាឧទាហរណ៍ អ្នកឯកទេសអាចចូលរួមក្នុងដំណើរការពិនិត្យការកំណត់រចនាសម្ព័ន្ធ។
4. សុចរិតភាព និងសមកាលកម្មរវាងថ្នាំង។ គុណសម្បត្តិមួយនៃការមានការកំណត់រចនាសម្ព័ន្ធនៃប្រព័ន្ធចែកចាយទាំងមូលដែលរក្សាទុកនៅចំណុចតែមួយគឺថាតម្លៃទាំងអស់ត្រូវបានប្រកាសយ៉ាងពិតប្រាកដម្តងហើយបន្ទាប់មកប្រើឡើងវិញនៅគ្រប់ទីកន្លែងដែលពួកគេត្រូវការ។ ការប្រើប្រភេទ phantom ដើម្បីប្រកាសច្រកធានាថាថ្នាំងកំពុងប្រើពិធីការដែលត្រូវគ្នានៅក្នុងការកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធត្រឹមត្រូវ។ ការមានភាពអាស្រ័យជាកាតព្វកិច្ចច្បាស់លាស់រវាងថ្នាំង ធានាថាសេវាកម្មទាំងអស់ត្រូវបានភ្ជាប់។
5. ការផ្លាស់ប្តូរគុណភាពខ្ពស់។ ការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធដោយប្រើដំណើរការអភិវឌ្ឍន៍ទូទៅធ្វើឱ្យវាអាចសម្រេចបាននូវស្តង់ដារគុណភាពខ្ពស់សម្រាប់ការកំណត់រចនាសម្ព័ន្ធផងដែរ។
6. ការធ្វើបច្ចុប្បន្នភាពការកំណត់រចនាសម្ព័ន្ធក្នុងពេលដំណាលគ្នា។ ការដាក់ឱ្យប្រើប្រាស់ប្រព័ន្ធដោយស្វ័យប្រវត្តិបន្ទាប់ពីការផ្លាស់ប្តូរការកំណត់ធានាថាថ្នាំងទាំងអស់ត្រូវបានធ្វើបច្ចុប្បន្នភាព។
7. ការធ្វើឱ្យកម្មវិធីងាយស្រួល។ កម្មវិធីមិនត្រូវការការវិភាគ ការត្រួតពិនិត្យការកំណត់រចនាសម្ព័ន្ធ ឬការគ្រប់គ្រងតម្លៃមិនត្រឹមត្រូវទេ។ នេះកាត់បន្ថយភាពស្មុគស្មាញនៃកម្មវិធី។ (ភាពស្មុគស្មាញនៃការកំណត់រចនាសម្ព័ន្ធមួយចំនួនដែលបានសង្កេតនៅក្នុងឧទាហរណ៍របស់យើងមិនមែនជាគុណលក្ខណៈនៃការកំណត់រចនាសម្ព័ន្ធដែលបានចងក្រងនោះទេ ប៉ុន្តែគ្រាន់តែជាការសម្រេចចិត្តប្រកបដោយស្មារតីដែលជំរុញដោយបំណងប្រាថ្នាក្នុងការផ្តល់នូវសុវត្ថិភាពប្រភេទធំជាងនេះ។) វាងាយស្រួលណាស់ក្នុងការត្រលប់ទៅការកំណត់ធម្មតាវិញ - គ្រាន់តែអនុវត្តការបាត់។ ផ្នែក។ ដូច្នេះ ជាឧទាហរណ៍ អ្នកអាចចាប់ផ្តើមជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធដែលបានចងក្រង ដោយពន្យារការអនុវត្តផ្នែកដែលមិនចាំបាច់រហូតដល់ពេលដែលវាពិតជាត្រូវការ។
8. ការកំណត់រចនាសម្ព័ន្ធដែលបានផ្ទៀងផ្ទាត់។ ដោយសារការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធធ្វើតាមជោគវាសនាធម្មតានៃការផ្លាស់ប្តូរផ្សេងទៀត លទ្ធផលដែលយើងទទួលបានគឺជាវត្ថុបុរាណដែលមានកំណែតែមួយគត់។ នេះអនុញ្ញាតឱ្យយើងត្រឡប់ទៅកំណែមុននៃការកំណត់រចនាសម្ព័ន្ធប្រសិនបើចាំបាច់។ យើងថែមទាំងអាចប្រើការកំណត់ពីមួយឆ្នាំមុន ហើយប្រព័ន្ធនឹងដំណើរការដូចគ្នាបេះបិទ។ ការកំណត់រចនាសម្ព័ន្ធមានស្ថេរភាពធ្វើអោយប្រសើរឡើងនូវការព្យាករណ៍ និងភាពជឿជាក់នៃប្រព័ន្ធចែកចាយ។ ដោយសារការកំណត់រចនាសម្ព័ន្ធត្រូវបានជួសជុលនៅដំណាក់កាលចងក្រង វាពិតជាលំបាកណាស់ក្នុងការក្លែងបន្លំវានៅក្នុងការផលិត។
9. ម៉ូឌុល។ ក្របខ័ណ្ឌដែលបានស្នើឡើងគឺម៉ូឌុល ហើយម៉ូឌុលអាចត្រូវបានរួមបញ្ចូលគ្នាតាមវិធីផ្សេងៗគ្នាដើម្បីបង្កើតប្រព័ន្ធផ្សេងៗ។ ជាពិសេស អ្នកអាចកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធឱ្យដំណើរការលើថ្នាំងតែមួយក្នុងតំណាងមួយ និងនៅលើថ្នាំងច្រើនក្នុងមួយទៀត។ អ្នកអាចបង្កើតការកំណត់រចនាសម្ព័ន្ធជាច្រើនសម្រាប់ឧទាហរណ៍ផលិតកម្មនៃប្រព័ន្ធ។
10. ការធ្វើតេស្ត។ ដោយការជំនួសសេវាកម្មនីមួយៗដោយវត្ថុក្លែងក្លាយ អ្នកអាចទទួលបានកំណែជាច្រើននៃប្រព័ន្ធដែលងាយស្រួលសម្រាប់ការធ្វើតេស្ត។
11. ការធ្វើតេស្តរួមបញ្ចូល។ ការមានការកំណត់រចនាសម្ព័ន្ធតែមួយសម្រាប់ប្រព័ន្ធចែកចាយទាំងមូលធ្វើឱ្យវាអាចដំណើរការសមាសធាតុទាំងអស់នៅក្នុងបរិយាកាសដែលបានគ្រប់គ្រងជាផ្នែកនៃការធ្វើតេស្តរួមបញ្ចូល។ វាងាយស្រួលក្នុងការត្រាប់តាម ឧទាហរណ៍ ស្ថានភាពដែលថ្នាំងមួយចំនួនអាចចូលប្រើបាន។

គុណវិបត្តិ និងដែនកំណត់

ការកំណត់រចនាសម្ព័ន្ធដែលបានចងក្រងខុសពីវិធីសាស្រ្តកំណត់រចនាសម្ព័ន្ធផ្សេងទៀត ហើយប្រហែលជាមិនសមរម្យសម្រាប់កម្មវិធីមួយចំនួន។ ខាងក្រោមនេះជាគុណវិបត្តិមួយចំនួន៖

1. ការកំណត់រចនាសម្ព័ន្ធឋិតិវន្ត។ ពេលខ្លះអ្នកត្រូវកែតម្រូវការកំណត់រចនាសម្ព័ន្ធក្នុងផលិតកម្មយ៉ាងឆាប់រហ័ស ដោយរំលងយន្តការការពារទាំងអស់។ ជាមួយនឹងវិធីសាស្រ្តនេះវាអាចពិបាកជាង។ យ៉ាងហោចណាស់ ការចងក្រង និងការដាក់ឱ្យប្រើប្រាស់ដោយស្វ័យប្រវត្តិនឹងនៅតែត្រូវបានទាមទារ។ នេះគឺជាទាំងលក្ខណៈមានប្រយោជន៍នៃវិធីសាស្រ្ត និងគុណវិបត្តិនៅក្នុងករណីមួយចំនួន។
2. ការបង្កើតការកំណត់រចនាសម្ព័ន្ធ។ ក្នុងករណីដែលឯកសារកំណត់រចនាសម្ព័ន្ធត្រូវបានបង្កើតដោយឧបករណ៍ស្វ័យប្រវត្តិ ការខិតខំប្រឹងប្រែងបន្ថែមអាចត្រូវបានទាមទារដើម្បីបញ្ចូលស្គ្រីបស្ថាបនា។
3. ឧបករណ៍។ បច្ចុប្បន្ន ឧបករណ៍ប្រើប្រាស់ និងបច្ចេកទេសដែលត្រូវបានរចនាឡើងដើម្បីធ្វើការជាមួយការកំណត់រចនាសម្ព័ន្ធគឺផ្អែកលើឯកសារអត្ថបទ។ មិនមែនគ្រប់ឧបករណ៍ប្រើប្រាស់/បច្ចេកទេសបែបនេះនឹងមាននៅក្នុងការកំណត់រចនាសម្ព័ន្ធដែលបានចងក្រងនោះទេ។
4. តម្រូវឲ្យមានការផ្លាស់ប្តូរអាកប្បកិរិយា។ អ្នកអភិវឌ្ឍន៍ និង DevOps ស៊ាំនឹងឯកសារអត្ថបទ។ គំនិត​នៃ​ការ​ចងក្រង​ការ​កំណត់​រចនាសម្ព័ន្ធ​ប្រហែល​ជា​មិន​នឹក​ស្មាន​ដល់​និង​មិន​ប្រក្រតី ហើយ​បណ្តាល​ឱ្យ​មាន​ការ​បដិសេធ។
5. ដំណើរការអភិវឌ្ឍន៍ដែលមានគុណភាពខ្ពស់ត្រូវបានទាមទារ។ ដើម្បីងាយស្រួលប្រើការកំណត់រចនាសម្ព័ន្ធដែលបានចងក្រង ស្វ័យប្រវត្តិកម្មពេញលេញនៃដំណើរការសាងសង់ និងដាក់ពង្រាយកម្មវិធី (CI/CD) គឺចាំបាច់។ បើមិនដូច្នោះទេវានឹងមានការរអាក់រអួលណាស់។

ចូរយើងផងដែរនៅលើដែនកំណត់មួយចំនួននៃឧទាហរណ៍ដែលបានពិចារណាដែលមិនទាក់ទងទៅនឹងគំនិតនៃការកំណត់រចនាសម្ព័ន្ធចងក្រងមួយ:

1. ប្រសិនបើយើងផ្តល់ព័ត៌មានការកំណត់រចនាសម្ព័ន្ធដែលមិនចាំបាច់ដែលមិនត្រូវបានប្រើប្រាស់ដោយថ្នាំង នោះអ្នកចងក្រងនឹងមិនជួយយើងរកឃើញការអនុវត្តដែលបាត់នោះទេ។ បញ្ហានេះអាចដោះស្រាយបានដោយការបោះបង់ចោលគំរូនំខេក ហើយប្រើប្រភេទរឹងជាងនេះ ឧទាហរណ៍៖ HList ឬប្រភេទទិន្នន័យពិជគណិត (ថ្នាក់ករណី) ដើម្បីតំណាងឱ្យការកំណត់រចនាសម្ព័ន្ធ។
2. មានបន្ទាត់នៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធដែលមិនទាក់ទងនឹងការកំណត់រចនាសម្ព័ន្ធខ្លួនវា៖ (package, importសេចក្តីប្រកាសវត្ថុ; override def's សម្រាប់​ប៉ារ៉ាម៉ែត្រ​ដែល​មាន​តម្លៃ​លំនាំដើម)។ នេះអាចត្រូវបានជៀសវាងដោយផ្នែកប្រសិនបើអ្នកអនុវត្ត DSL ផ្ទាល់ខ្លួនរបស់អ្នក។ លើសពីនេះ ប្រភេទផ្សេងទៀតនៃការកំណត់រចនាសម្ព័ន្ធ (ឧទាហរណ៍ XML) ក៏ដាក់កម្រិតជាក់លាក់លើរចនាសម្ព័ន្ធឯកសារផងដែរ។
3. សម្រាប់គោលបំណងនៃការបង្ហោះនេះ យើងមិនពិចារណាលើការកំណត់រចនាសម្ព័ន្ធឡើងវិញថាមវន្តនៃចង្កោមនៃថ្នាំងស្រដៀងគ្នាទេ។

សេចក្តីសន្និដ្ឋាន

នៅក្នុងការប្រកាសនេះ យើងបានស្វែងយល់ពីគំនិតនៃការតំណាងឱ្យការកំណត់រចនាសម្ព័ន្ធនៅក្នុងកូដប្រភពដោយប្រើសមត្ថភាពកម្រិតខ្ពស់នៃប្រព័ន្ធប្រភេទ Scala ។ វិធីសាស្រ្តនេះអាចត្រូវបានប្រើនៅក្នុងកម្មវិធីផ្សេងៗជាការជំនួសវិធីសាស្ត្រកំណត់រចនាសម្ព័ន្ធបែបប្រពៃណីដោយផ្អែកលើឯកសារ xml ឬអត្ថបទ។ ទោះបីជាឧទាហរណ៍របស់យើងត្រូវបានអនុវត្តនៅក្នុង Scala ក៏ដោយ ក៏គំនិតដូចគ្នាអាចត្រូវបានផ្ទេរទៅភាសាដែលបានចងក្រងផ្សេងទៀត (ដូចជា Kotlin, C#, Swift, ... )។ អ្នកអាចសាកល្បងវិធីសាស្រ្តនេះនៅក្នុងគម្រោងមួយក្នុងចំណោមគម្រោងខាងក្រោម ហើយប្រសិនបើវាមិនដំណើរការ សូមបន្តទៅឯកសារអត្ថបទដោយបន្ថែមផ្នែកដែលបាត់។

តាមធម្មជាតិ ការកំណត់រចនាសម្ព័ន្ធដែលបានចងក្រងទាមទារដំណើរការអភិវឌ្ឍន៍ប្រកបដោយគុណភាពខ្ពស់។ នៅក្នុងការត្រឡប់មកវិញ គុណភាពខ្ពស់ និងភាពជឿជាក់នៃការកំណត់រចនាសម្ព័ន្ធត្រូវបានធានា។

វិធីសាស្រ្តដែលបានពិចារណាអាចត្រូវបានពង្រីក:

1. អ្នកអាចប្រើម៉ាក្រូ ដើម្បីត្រួតពិនិត្យពេលវេលាចងក្រង។
2. អ្នកអាចអនុវត្ត DSL ដើម្បីបង្ហាញការកំណត់រចនាសម្ព័ន្ធតាមរបៀបដែលអាចចូលប្រើបានសម្រាប់អ្នកប្រើប្រាស់ចុងក្រោយ។
3. អ្នកអាចអនុវត្តការគ្រប់គ្រងធនធានថាមវន្តជាមួយនឹងការកែតម្រូវការកំណត់រចនាសម្ព័ន្ធដោយស្វ័យប្រវត្តិ។ ឧទាហរណ៍ ការផ្លាស់ប្តូរចំនួនថ្នាំងក្នុងចង្កោមតម្រូវឱ្យ (1) ថ្នាំងនីមួយៗទទួលបានការកំណត់រចនាសម្ព័ន្ធខុសគ្នាបន្តិច។ (2) អ្នកគ្រប់គ្រងចង្កោមបានទទួលព័ត៌មានអំពីថ្នាំងថ្មី។

ការដឹងគុណ

ខ្ញុំសូមថ្លែងអំណរគុណដល់ Andrei Saksonov, Pavel Popov និង Anton Nekhaev សម្រាប់ការរិះគន់ក្នុងន័យស្ថាបនារបស់ពួកគេចំពោះសេចក្តីព្រាង។

ប្រភព: www.habr.com