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

В тази публикация бихме искали да споделим един интересен начин за справяне с конфигурацията на разпределена система.
Конфигурацията е представена директно на езика Scala по безопасен тип начин. Примерно изпълнение е описано подробно. Обсъждат се различни аспекти на предложението, включително влияние върху цялостния процес на развитие.

(на руски език)

Въведение

Изграждането на стабилни разпределени системи изисква използването на правилна и съгласувана конфигурация на всички възли. Типично решение е да се използва текстово описание на внедряване (тераформа, анзибъл или нещо подобно) и автоматично генерирани конфигурационни файлове (често — предназначени за всеки възел/роля). Също така бихме искали да използваме едни и същи протоколи от едни и същи версии на всеки комуникационен възел (в противен случай ще изпитаме проблеми с несъвместимостта). В света на JVM това означава, че поне библиотеката за съобщения трябва да бъде с една и съща версия на всички комуникиращи възли.

Какво ще кажете за тестването на системата? Разбира се, трябва да имаме модулни тестове за всички компоненти, преди да преминем към интеграционни тестове. За да можем да екстраполираме резултатите от тестовете по време на изпълнение, трябва да сме сигурни, че версиите на всички библиотеки се поддържат идентични както в средата на изпълнение, така и в средата за тестване.

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

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

В съвременните среди конфигурационните файлове вече не се променят ръчно. Обикновено генерираме
конфигурационни файлове по време на внедряване и никога не ги докосвай след това. Така че някой може да попита защо все още използваме текстов формат за конфигурационни файлове? Жизнеспособна опция е да поставите конфигурацията в компилиращ модул и да се възползвате от валидирането на конфигурацията по време на компилация.

В тази публикация ще разгледаме идеята за запазване на конфигурацията в компилирания артефакт.

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

В този раздел ще обсъдим пример за статична конфигурация. Две прости услуги - услугата ехо и клиентът на услугата ехо се конфигурират и внедряват. След това се създават две различни разпределени системи с двете услуги. Единият е за конфигурация с един възел, а другият за конфигурация с два възела.

Типичната разпределена система се състои от няколко възела. Възлите могат да бъдат идентифицирани с помощта на някакъв тип:

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-битови стойности, които могат да представляват номер на порт. Няма изискване тази библиотека да се използва за този конфигурационен подход. Просто изглежда, че стои много добре.

За HTTP (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]

В този протокол съобщението за заявка се добавя към url и съобщението за отговор се връща като обикновен низ.

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

Зависимостите могат да бъдат представени с помощта на Cake Pattern като крайни точки на други възли:

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

Можем да декларираме зависимост в конфигурацията на клиента на ехо услугата:

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

Зависимостта има същия тип като echoService. По-специално, той изисква същия протокол. Следователно можем да сме сигурни, че ако свържем тези две зависимости, те ще работят правилно.

Изпълнение на услугите

Една услуга се нуждае от функция за стартиране и елегантно изключване. (Възможността за изключване на услуга е от решаващо значение за тестване.) Отново има няколко опции за указване на такава функция за дадена конфигурация (например можем да използваме типови класове). За тази публикация ще използваме отново Cake Pattern. Можем да представим услуга, използвайки 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](()))
  }

(Виж Изходния код за внедряване на други услуги — ехо услуга,
ехо клиент намлява доживотни контролери.)

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

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

Имайте предвид, че във възела ние указваме точния тип конфигурация, която е необходима на този възел. Компилаторът няма да ни позволи да изградим обекта (Cake) с недостатъчен тип, защото всяка характеристика на услугата декларира ограничение на Config Тип. Също така няма да можем да стартираме възел, без да предоставим пълна конфигурация.

Резолюция на адрес на възел

За да установим връзка, се нуждаем от реален хост адрес за всеки възел. Може да стане известно по-късно от други части на конфигурацията. Следователно, имаме нужда от начин да осигурим съпоставяне между идентификатора на възел и неговия действителен адрес. Това картографиране е функция:

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

Има няколко възможни начина за реализиране на такава функция.

1. Ако знаем действителните адреси преди разгръщането, по време на инстанциране на хостове на възли, тогава можем да генерираме Scala код с действителните адреси и да изпълним компилацията след това (която извършва проверки по време на компилиране и след това изпълнява тестов пакет за интеграция). В този случай нашата функция за картографиране е известна статично и може да бъде опростена до нещо като a Map[NodeId, NodeAddress].
2. Понякога получаваме действителни адреси само на по-късен етап, когато възелът действително е стартиран, или нямаме адреси на възли, които все още не са стартирани. В този случай може да имаме услуга за откриване, която се стартира преди всички други възли и всеки възел може да рекламира своя адрес в тази услуга и да се абонира за зависимости.
3. Ако можем да променим /etc/hosts, можем да използваме предварително дефинирани имена на хостове (като my-project-main-node намлява echo-backend) и просто свържете това име с ip адреса по време на внедряване.

В тази публикация не разглеждаме тези случаи в повече подробности. Всъщност в нашия пример за играчка всички възли ще имат един и същ IP адрес - 127.0.0.1.

В тази публикация ще разгледаме две оформления на разпределени системи:

1. Оформление на един възел, където всички услуги са разположени на един възел.
2. Оформление с два възела, където услугата и клиентът са на различни възли.

Конфигурацията за a единичен възел оформлението е както следва:

Конфигурация с един възел

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, докато ехо клиентът ще приключи след конфигурираната крайна продължителност. Вижте стартово приложение за повече.

Цялостен процес на развитие

Нека видим как този подход променя начина, по който работим с конфигурацията.

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

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

Билет -> PR -> преглед -> сливане -> непрекъсната интеграция -> непрекъснато внедряване

Има следните последствия от подхода:

1. Конфигурацията е съгласувана за конкретен екземпляр на системата. Изглежда, че няма начин да има неправилна връзка между възлите.
2. Не е лесно да промените конфигурацията само в един възел. Изглежда неразумно да влизате и да променяте някои текстови файлове. Така отклонението в конфигурацията става по-малко възможно.
3. Малките промени в конфигурацията не се правят лесно.
4. Повечето от промените в конфигурацията ще следват същия процес на разработка и ще преминат известен преглед.

Имаме ли нужда от отделно хранилище за производствена конфигурация? Производствената конфигурация може да съдържа чувствителна информация, която бихме искали да запазим далеч от обсега на много хора. Така че може да си струва да запазите отделно хранилище с ограничен достъп, което ще съдържа производствената конфигурация. Можем да разделим конфигурацията на две части - една, която съдържа най-отворените параметри на производството, и една, която съдържа тайната част на конфигурацията. Това би позволило достъп на повечето разработчици до по-голямата част от параметрите, като същевременно ограничава достъпа до наистина чувствителни неща. Лесно е да постигнете това, като използвате междинни характеристики със стойности на параметрите по подразбиране.

Вариации

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

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

1. Текстов файл на целевата машина.
2. Централизирано съхранение на ключ-стойност (като etcd/zookeeper).
3. Компоненти на подпроцес, които могат да бъдат преконфигурирани/рестартирани без рестартиране на процеса.
4. Конфигурация извън артефакт и контрол на версиите.

Текстовият файл дава известна гъвкавост по отношение на ad-hoc корекции. Администраторът на системата може да влезе в целевия възел, да направи промяна и просто да рестартира услугата. Това може да не е толкова добро за по-големи системи. След промяната не остават никакви следи. Промяната не се преглежда от друг чифт очи. Може да е трудно да разберете какво е причинило промяната. Не е тестван. От гледна точка на разпределената система администраторът може просто да забрави да актуализира конфигурацията в някой от другите възли.

(Между другото, ако в крайна сметка се наложи да започнем да използваме текстови конфигурационни файлове, ще трябва само да добавим парсер + валидатор, който може да произведе същото 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 (класове на случай) за конфигурация на възел вместо характеристики и Cake Pattern.
2. Трябва да предоставим някакъв шаблон в конфигурационния файл: (package, import, object декларации;
   override defза параметри, които имат стойности по подразбиране). Това може да бъде частично адресирано с помощта на DSL.
3. В тази публикация не разглеждаме динамичното преконфигуриране на клъстери от подобни възли.

Заключение

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

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

Този подход може да бъде разширен по различни начини:

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

Благодаря

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

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