შედგენილი განაწილებული სისტემის კონფიგურაცია

მინდა გითხრათ ერთი საინტერესო მექანიზმი განაწილებული სისტემის კონფიგურაციასთან მუშაობისთვის. კონფიგურაცია წარმოდგენილია პირდაპირ შედგენილ ენაზე (Scala) უსაფრთხო ტიპების გამოყენებით. ამ პოსტში მოცემულია ასეთი კონფიგურაციის მაგალითი და განიხილავს შედგენილი კონფიგურაციის განხორციელების სხვადასხვა ასპექტს განვითარების საერთო პროცესში.

(ინგლისური)

შესავალი

საიმედო განაწილებული სისტემის აშენება ნიშნავს, რომ ყველა კვანძი იყენებს სწორ კონფიგურაციას, სინქრონიზებულია სხვა კვანძებთან. DevOps ტექნოლოგიები (terraform, ansible ან მსგავსი) ჩვეულებრივ გამოიყენება კონფიგურაციის ფაილების ავტომატურად გენერირებისთვის (ხშირად სპეციფიკური თითოეული კვანძისთვის). ჩვენ ასევე გვინდა ვიყოთ დარწმუნებული, რომ ყველა საკომუნიკაციო კვანძი იყენებს იდენტურ პროტოკოლებს (მათ შორის იგივე ვერსია). წინააღმდეგ შემთხვევაში, შეუთავსებლობა ჩაშენდება ჩვენს განაწილებულ სისტემაში. 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)

ფანტომის ტიპები

შედგენის დროს პროტოკოლის იდენტიფიცირებისთვის ვიყენებთ ტიპის პარამეტრს, რომელიც არ გამოიყენება კლასში. ეს გადაწყვეტილება გამოწვეულია იმით, რომ ჩვენ არ ვიყენებთ პროტოკოლის ინსტანციას გაშვების დროს, მაგრამ გვსურს შემდგენელმა შეამოწმოს პროტოკოლის თავსებადობა. პროტოკოლის მითითებით, ჩვენ ვერ შევძლებთ შეუსაბამო სერვისის გადაცემას დამოკიდებულების სახით.

ერთ-ერთი გავრცელებული პროტოკოლი არის REST API Json სერიალიზაციით:

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. კერძოდ, echo კლიენტში ჩვენ ვითხოვთ იგივე პროტოკოლს. ამიტომ, ორი სერვისის შეერთებისას, შეგვიძლია დარწმუნებული ვიყოთ, რომ ყველაფერი სწორად იმუშავებს.

სერვისების განხორციელება

სერვისის დასაწყებად და შესაჩერებლად საჭიროა ფუნქცია. (სერვისის შეჩერების შესაძლებლობა გადამწყვეტია ტესტირებისთვის.) კვლავ არსებობს რამდენიმე ვარიანტი ასეთი ფუნქციის განსახორციელებლად (მაგალითად, ჩვენ შეგვიძლია გამოვიყენოთ ტიპის კლასები კონფიგურაციის ტიპზე დაყრდნობით). ამ პოსტის მიზნებისთვის ჩვენ გამოვიყენებთ ტორტის შაბლონს. ჩვენ წარმოვადგენთ სერვისს კლასის გამოყენებით 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
}

გთხოვთ გაითვალისწინოთ, რომ ჩვენ ვაზუსტებთ კონფიგურაციის ზუსტ ტიპს, რომელიც საჭიროა ამ კვანძისთვის. თუ დაგვავიწყდება კონკრეტული სერვისის მიერ მოთხოვნილი კონფიგურაციის ერთ-ერთი ტიპის მითითება, იქნება კომპილაციის შეცდომა. ასევე, ჩვენ ვერ შევძლებთ კვანძის დაწყებას, თუ არ მივაწოდებთ შესაბამისი ტიპის რომელიმე ობიექტს ყველა საჭირო მონაცემით.

ჰოსტის სახელის რეზოლუცია

დისტანციურ ჰოსტთან დასაკავშირებლად, ჩვენ გვჭირდება რეალური IP მისამართი. შესაძლებელია, რომ მისამართი გახდება ცნობილი მოგვიანებით, ვიდრე დანარჩენი კონფიგურაცია. ასე რომ, ჩვენ გვჭირდება ფუნქცია, რომელიც ასახავს კვანძის ID მისამართს:

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

ამ ფუნქციის განხორციელების რამდენიმე გზა არსებობს:

1. თუ მისამართები გავრცელებამდე გახდება ცნობილი ჩვენთვის, მაშინ შეგვიძლია Scala კოდის გენერირება
   მისამართები და შემდეგ გაუშვით build. ეს შეაგროვებს და აწარმოებს ტესტებს.
   ამ შემთხვევაში, ფუნქცია ცნობილი იქნება სტატიკურად და შეიძლება წარმოდგენილი იყოს კოდში, როგორც რუკების სახით 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"
  }

Მნიშვნელოვანი! ყურადღება მიაქციეთ როგორ არის დაკავშირებული სერვისები. ჩვენ ვაზუსტებთ სერვისს, რომელიც განხორციელებულია ერთი კვანძის მიერ, როგორც სხვა კვანძის დამოკიდებულების მეთოდის განხორციელება. დამოკიდებულების ტიპს ამოწმებს შემდგენელი, რადგან შეიცავს პროტოკოლის ტიპს. გაშვებისას, დამოკიდებულება შეიცავს სწორ სამიზნე კვანძის ID-ს. ამ სქემის წყალობით, ჩვენ ზუსტად ერთხელ ვაზუსტებთ პორტის ნომერს და ყოველთვის გარანტირებული გვაქვს სწორი პორტის მითითება.

ორი სისტემის კვანძის დანერგვა

ამ კონფიგურაციისთვის, ჩვენ ვიყენებთ იმავე სერვისის იმპლემენტაციას ცვლილებების გარეშე. ერთადერთი განსხვავება ისაა, რომ ახლა გვაქვს ორი ობიექტი, რომლებიც ახორციელებენ სხვადასხვა სერვისების კომპლექტს:

  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. მთლიანობა და სინქრონულობა კვანძებს შორის. მთლიანი განაწილებული სისტემის კონფიგურაციის ერთ წერტილში შენახვის ერთ-ერთი უპირატესობა არის ის, რომ ყველა მნიშვნელობა გამოცხადებულია ზუსტად ერთხელ და შემდეგ ხელახლა გამოიყენება იქ, სადაც საჭიროა. პორტების გამოცხადებისთვის ფანტომური ტიპების გამოყენება უზრუნველყოფს, რომ კვანძები იყენებენ თავსებადი პროტოკოლებს ყველა სწორი სისტემის კონფიგურაციაში. კვანძებს შორის აშკარა სავალდებულო დამოკიდებულების არსებობა უზრუნველყოფს ყველა სერვისის დაკავშირებას.
5. მაღალი ხარისხის ცვლილებები. კონფიგურაციაში ცვლილებების შეტანა განვითარების საერთო პროცესის გამოყენებით შესაძლებელს ხდის კონფიგურაციის მაღალი ხარისხის სტანდარტების მიღწევასაც.
6. კონფიგურაციის ერთდროული განახლება. სისტემის ავტომატური განლაგება კონფიგურაციის ცვლილებების შემდეგ უზრუნველყოფს ყველა კვანძის განახლებას.
7. აპლიკაციის გამარტივება. აპლიკაციას არ სჭირდება ანალიზი, კონფიგურაციის შემოწმება ან არასწორი მნიშვნელობების დამუშავება. ეს ამცირებს აპლიკაციის სირთულეს. (ჩვენს მაგალითში დაფიქსირებული კონფიგურაციის ზოგიერთი სირთულე არ არის შედგენილი კონფიგურაციის ატრიბუტი, არამედ მხოლოდ შეგნებული გადაწყვეტილება, რომელიც გამოწვეულია უფრო დიდი ტიპის უსაფრთხოების უზრუნველყოფის სურვილით.) საკმაოდ მარტივია ჩვეულ კონფიგურაციაზე დაბრუნება - უბრალოდ განახორციელეთ დაკარგული. ნაწილები. მაშასადამე, შეგიძლიათ, მაგალითად, დაიწყოთ შედგენილი კონფიგურაციით, გადადოთ არასაჭირო ნაწილების განხორციელება იმ დრომდე, როდესაც ეს ნამდვილად საჭიროა.
8. დამოწმებული კონფიგურაცია. ვინაიდან კონფიგურაციის ცვლილებები ნებისმიერი სხვა ცვლილების ჩვეულ ბედს მიჰყვება, გამომავალი, რომელსაც ჩვენ ვიღებთ, არის არტეფაქტი უნიკალური ვერსიით. ეს საშუალებას გვაძლევს, მაგალითად, საჭიროების შემთხვევაში დავუბრუნდეთ კონფიგურაციის წინა ვერსიას. ჩვენ შეგვიძლია ერთი წლის წინანდელი კონფიგურაციაც კი გამოვიყენოთ და სისტემა ზუსტად იმუშავებს. სტაბილური კონფიგურაცია აუმჯობესებს განაწილებული სისტემის პროგნოზირებადობას და საიმედოობას. ვინაიდან კონფიგურაცია ფიქსირდება შედგენის ეტაპზე, საკმაოდ რთულია მისი გაყალბება წარმოებაში.
9. მოდულარულობა. შემოთავაზებული ჩარჩო მოდულარულია და მოდულები შეიძლება გაერთიანდეს სხვადასხვა გზით სხვადასხვა სისტემის შესაქმნელად. კერძოდ, შეგიძლიათ დააკონფიგურიროთ სისტემა ისე, რომ იმუშაოს ერთ კვანძზე ერთ განსახიერებაში და მრავალ კვანძზე მეორეში. თქვენ შეგიძლიათ შექმნათ რამდენიმე კონფიგურაცია სისტემის წარმოების ინსტანციებისთვის.
10. ტესტირება. ინდივიდუალური სერვისების იმიტირებული ობიექტებით შეცვლით, შეგიძლიათ მიიღოთ სისტემის რამდენიმე ვერსია, რომლებიც მოსახერხებელია ტესტირებისთვის.
11. ინტეგრაციის ტესტირება. მთლიანი განაწილებული სისტემისთვის ერთიანი კონფიგურაციის არსებობა შესაძლებელს ხდის ყველა კომპონენტის გაშვებას კონტროლირებად გარემოში, როგორც ინტეგრაციის ტესტირების ნაწილი. ადვილია ემულაცია, მაგალითად, სიტუაცია, როდესაც ზოგიერთი კვანძი ხელმისაწვდომი ხდება.

ნაკლოვანებები და შეზღუდვები

შედგენილი კონფიგურაცია განსხვავდება სხვა კონფიგურაციის მიდგომებისგან და შეიძლება არ იყოს შესაფერისი ზოგიერთი აპლიკაციისთვის. ქვემოთ მოცემულია რამდენიმე უარყოფითი მხარე:

1. სტატიკური კონფიგურაცია. ზოგჯერ საჭიროა სწრაფად შეასწოროთ კონფიგურაცია წარმოებაში, ყველა დამცავი მექანიზმის გვერდის ავლით. ამ მიდგომით შეიძლება უფრო რთული იყოს. სულ მცირე, კომპილაცია და ავტომატური განლაგება მაინც იქნება საჭირო. ეს არის მიდგომის როგორც სასარგებლო თვისება, ასევე ზოგ შემთხვევაში მინუსი.
2. კონფიგურაციის გენერაცია. იმ შემთხვევაში, თუ კონფიგურაციის ფაილი გენერირებულია ავტომატური ხელსაწყოთი, შეიძლება საჭირო გახდეს დამატებითი ძალისხმევა build სკრიპტის ინტეგრირებისთვის.
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) კლასტერის მენეჯერმა მიიღო ინფორმაცია ახალი კვანძების შესახებ.

მადლობა

მინდა მადლობა გადავუხადო ანდრეი საქსონოვს, პაველ პოპოვს და ანტონ ნეხაევს სტატიის პროექტის კონსტრუქციული კრიტიკისთვის.

წყარო: www.habr.com