Компилирана конфигурация на разпределена система

Бих искал да ви кажа един интересен механизъм за работа с конфигурацията на разпределена система. Конфигурацията е представена директно на компилиран език (Scala) с помощта на безопасни типове. Тази публикация предоставя пример за такава конфигурация и обсъжда различни аспекти на внедряването на компилираната конфигурация в цялостния процес на разработка.

(Английски)

въведение

Изграждането на надеждна разпределена система означава, че всички възли използват правилната конфигурация, синхронизирана с други възли. DevOps технологиите (teraform, 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)
  }

За да създадете ехо услуга, всичко, от което се нуждаете, е номер на порт и индикация, че портът поддържа ехо протокола. Може да не посочим конкретен порт, защото... характеристиките ви позволяват да декларирате методи без реализация (абстрактни методи). В този случай, когато създаваме конкретна конфигурация, компилаторът ще изисква от нас да предоставим имплементация на абстрактния метод и да предоставим номер на порт. Тъй като сме внедрили метода, когато създаваме конкретна конфигурация, може да не посочим различен порт. Ще се използва стойността по подразбиране.

В конфигурацията на клиента ние декларираме зависимост от услугата 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 — клас тип ефект, който ви позволява да комбинирате отделни ефекти (почти монада). В по-сложни приложения изглежда по-добре да се използва Monad/ConcurrentEffect.

Използвайки този функционален подпис, можем да реализираме няколко услуги. Например услуга, която не прави нищо:

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

(См. източник, в които са внедрени други услуги - ехо услуга, ехо клиент
и доживотни контролери.)

Възелът е обект, който може да стартира няколко услуги (стартирането на верига от ресурси се осигурява от Cake Pattern):

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 код с
   адреси и след това стартирайте компилацията. Това ще компилира и изпълни тестове.
   В този случай функцията ще бъде известна статично и може да бъде представена в код като картографиране 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 - данни. Изглежда, че конфигурационните параметри се различават от данните по това, че обикновено се променят по-рядко от данните. Освен това данните обикновено идват от един източник (от потребителя), а конфигурационните параметри от друг (от системния администратор).

Ако рядко променящите се параметри трябва да бъдат актуализирани без рестартиране на програмата, тогава това често може да доведе до усложняване на програмата, защото ще трябва по някакъв начин да доставим параметри, да съхраним, анализираме и проверяваме и да обработваме неправилни стойности. Следователно, от гледна точка на намаляване на сложността на програмата, има смисъл да се намали броят на параметрите, които могат да се променят по време на работа на програмата (или изобщо да не се поддържат такива параметри).

За целите на тази публикация ще правим разлика между статични и динамични параметри. Ако логиката на услугата изисква промяна на параметрите по време на работата на програмата, тогава ще наречем такива параметри динамични. В противен случай опциите са статични и могат да бъдат конфигурирани с помощта на компилираната конфигурация. За динамично преконфигуриране може да се нуждаем от механизъм за рестартиране на части от програмата с нови параметри, подобно на начина, по който се рестартират процесите на операционната система. (Според нас е препоръчително да се избягва преконфигурирането в реално време, тъй като това увеличава сложността на системата. Ако е възможно, по-добре е да използвате стандартните възможности на ОС за рестартиране на процесите.)

Един важен аспект на използването на статична конфигурация, който кара хората да обмислят динамично преконфигуриране, е времето, необходимо на системата да се рестартира след актуализация на конфигурацията (престой). Всъщност, ако трябва да направим промени в статичната конфигурация, ще трябва да рестартираме системата, за да влязат в сила новите стойности. Проблемът с престоя варира по тежест за различните системи. В някои случаи можете да планирате рестартиране в момент, когато натоварването е минимално. Ако трябва да осигурите непрекъснато обслужване, можете да внедрите Източване на AWS ELB връзка. В същото време, когато трябва да рестартираме системата, стартираме паралелен екземпляр на тази система, превключваме балансира към него и чакаме старите връзки да завършат. След като всички стари връзки са прекратени, изключваме стария екземпляр на системата.

Нека сега разгледаме въпроса за съхраняването на конфигурацията вътре или извън артефакта. Ако съхраняваме конфигурацията вътре в артефакт, тогава поне имахме възможност да проверим правилността на конфигурацията по време на сглобяването на артефакта. Ако конфигурацията е извън контролирания артефакт, е трудно да се проследи кой е направил промени в този файл и защо. Колко важно е? Според нас за много производствени системи е важно да имат стабилна и висококачествена конфигурация.

Версията на даден артефакт ви позволява да определите кога е създаден, какви стойности съдържа, какви функции са активирани/деактивирани и кой е отговорен за всяка промяна в конфигурацията. Разбира се, съхраняването на конфигурацията в артефакт изисква известни усилия, така че трябва да вземете информирано решение.

Плюсове и минуси

Бих искал да се спра на плюсовете и минусите на предложената технология.

предимства

По-долу е даден списък на основните характеристики на компилирана конфигурация на разпределена система:

1. Статична проверка на конфигурацията. Позволява ви да сте сигурни, че
   конфигурацията е правилна.
2. Богат език за конфигурация. Обикновено другите методи за конфигуриране са ограничени най-много до заместване на променлива в низ. Когато използвате Scala, широк набор от езикови функции са достъпни за подобряване на вашата конфигурация. Например можем да използваме
   черти за стойности по подразбиране, използвайки обекти за групиране на параметри, можем да се позоваваме на стойности, декларирани само веднъж (DRY) в обхващащия обхват. Можете да създадете всеки клас директно в конфигурацията (Seq, Map, персонализирани класове).
3. DSL. Scala има редица езикови функции, които улесняват създаването на DSL. Възможно е да се възползвате от тези функции и да приложите език за конфигурация, който е по-удобен за целевата група потребители, така че конфигурацията да бъде поне четлива от експертите в областта. Специалистите могат например да участват в процеса на преглед на конфигурацията.
4. Цялостност и синхрон между възлите. Едно от предимствата на конфигурацията на цялата разпределена система, съхранявана в една точка, е, че всички стойности се декларират точно веднъж и след това се използват повторно, където са необходими. Използването на фантомни типове за деклариране на портове гарантира, че възлите използват съвместими протоколи във всички правилни системни конфигурации. Наличието на изрични задължителни зависимости между възлите гарантира, че всички услуги са свързани.
5. Висококачествени промени. Извършването на промени в конфигурацията чрез общ процес на разработка прави възможно постигането на високи стандарти за качество и за конфигурацията.
6. Едновременна актуализация на конфигурацията. Автоматичното внедряване на системата след промени в конфигурацията гарантира, че всички възли са актуализирани.
7. Опростяване на приложението. Приложението не се нуждае от анализиране, проверка на конфигурацията или обработка на неправилни стойности. Това намалява сложността на приложението. (Част от сложността на конфигурацията, наблюдавана в нашия пример, не е атрибут на компилираната конфигурация, а само съзнателно решение, водено от желанието да се осигури по-голяма безопасност на типа.) Доста лесно е да се върнете към обичайната конфигурация - просто приложете липсващата части. Следователно можете например да започнете с компилирана конфигурация, като отложите внедряването на ненужни части до момента, в който наистина е необходимо.
8. Верифицирана конфигурация. Тъй като промените в конфигурацията следват обичайната съдба на всички други промени, резултатът, който получаваме, е артефакт с уникална версия. Това ни позволява например да се върнем към предишна версия на конфигурацията, ако е необходимо. Можем дори да използваме конфигурацията отпреди година и системата ще работи абсолютно по същия начин. Стабилната конфигурация подобрява предвидимостта и надеждността на разпределената система. Тъй като конфигурацията е фиксирана на етапа на компилация, е доста трудно да се фалшифицира в производството.
9. Модулност. Предложената рамка е модулна и модулите могат да се комбинират по различни начини за създаване на различни системи. По-специално, можете да конфигурирате системата да работи на единичен възел в едно изпълнение и на множество възли в друго. Можете да създадете няколко конфигурации за производствени екземпляри на системата.
10. Тестване. Като замените отделни услуги с фалшиви обекти, можете да получите няколко версии на системата, които са удобни за тестване.
11. Интеграционно тестване. Наличието на единна конфигурация за цялата разпределена система прави възможно изпълнението на всички компоненти в контролирана среда като част от интеграционното тестване. Лесно е да се емулира, например, ситуация, при която някои възли стават достъпни.

Недостатъци и ограничения

Компилираната конфигурация се различава от другите подходи за конфигурация и може да не е подходяща за някои приложения. По-долу са някои недостатъци:

1. Статична конфигурация. Понякога трябва бързо да коригирате конфигурацията в производството, заобикаляйки всички защитни механизми. С този подход може да бъде по-трудно. Най-малкото все още ще са необходими компилация и автоматично внедряване. Това е както полезна характеристика на подхода, така и недостатък в някои случаи.
2. Генериране на конфигурация. В случай, че конфигурационният файл е генериран от автоматичен инструмент, може да са необходими допълнителни усилия за интегриране на скрипта за изграждане.
3. Инструменти. Понастоящем помощните програми и техники, предназначени за работа с конфигурация, се основават на текстови файлове. Не всички подобни помощни програми/техники ще бъдат налични в компилирана конфигурация.
4. Необходима е промяна в нагласите. Разработчиците и DevOps са свикнали с текстови файлове. Самата идея за компилиране на конфигурация може да е малко неочаквана и необичайна и да предизвика отхвърляне.
5. Необходим е висококачествен процес на разработка. За удобно използване на компилираната конфигурация е необходима пълна автоматизация на процеса на изграждане и внедряване на приложението (CI/CD). В противен случай ще бъде доста неудобно.

Нека се спрем и на редица ограничения на разглеждания пример, които не са свързани с идеята за компилирана конфигурация:

1. Ако предоставим ненужна конфигурационна информация, която не се използва от възела, тогава компилаторът няма да ни помогне да открием липсващата реализация. Този проблем може да бъде решен чрез изоставяне на Cake Pattern и използване на по-твърди типове, например, HList или алгебрични типове данни (класове казуси) за представяне на конфигурация.
2. В конфигурационния файл има редове, които не са свързани със самата конфигурация: (package, import,обектни декларации; override defза параметри, които имат стойности по подразбиране). Това може да бъде частично избегнато, ако внедрите свой собствен DSL. В допълнение, други видове конфигурация (например XML) също налагат определени ограничения върху файловата структура.
3. За целите на тази публикация не обмисляме динамично преконфигуриране на клъстер от подобни възли.

Заключение

В тази публикация проучихме идеята за представяне на конфигурация в изходния код, използвайки разширените възможности на системата тип Scala. Този подход може да се използва в различни приложения като заместител на традиционните методи за конфигуриране, базирани на xml или текстови файлове. Въпреки че нашият пример е имплементиран в Scala, същите идеи могат да бъдат прехвърлени на други компилирани езици (като Kotlin, C#, Swift, ...). Можете да опитате този подход в един от следните проекти и, ако не работи, преминете към текстовия файл, като добавите липсващите части.

Естествено, компилираната конфигурация изисква висококачествен процес на разработка. В замяна се гарантира високо качество и надеждност на конфигурациите.

Разгледаният подход може да бъде разширен:

1. Можете да използвате макроси за извършване на проверки по време на компилиране.
2. Можете да внедрите DSL, за да представите конфигурацията по начин, който е достъпен за крайните потребители.
3. Можете да приложите динамично управление на ресурсите с автоматична настройка на конфигурацията. Например, промяната на броя на възлите в клъстер изисква (1) всеки възел да получи малко по-различна конфигурация; (2) мениджърът на клъстера получи информация за нови възли.

Признания

Бих искал да благодаря на Андрей Саксонов, Павел Попов и Антон Нехаев за тяхната градивна критика към проектостатията.

Източник: www.habr.com