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

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

(на български)

Introduction

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

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

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

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

where Порт е просто един Int в допускания диапазон:

type PortNumber = Refined[Int, Closed[_0, W.`65535`.T]]

Refined типове

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

Един от най-широко използваните протоколи е REST API с Json сериализация:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

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

За целите на тази публикация ще използваме по-прост вариант на протокола:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

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

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

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

  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]
  }

where

• Конфигурация — тип конфигурация, необходима за стартирането на тази услуга
• 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  Resource.pure[F, Unit]( ()))
  }

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

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

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

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

Разрешаване на адреса на възела

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

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 and echo-backend) и просто да свържем това име с ip адрес по време на внедряване.

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

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

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

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

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

обект SingleNodeConfig разширява EchoConfig[String] 
  с EchoClientConfig[String] с FiniteDurationLifecycleConfig
{
  случайен обект Singleton \/\/ идентификатор на единствения възел 
  \/\/ конфигурация на сървъра
  тип NodeId = Singleton.type
  деф nodeId = Singleton

  \/** Спецификация на безопасен тип за порт на услугата. *\/ 
  преоверете деф portNumber: PortNumber = 8088

  \/\/ конфигурация на клиента

  \/** Ще използваме услугата, предоставяна от същия хост. *\/ 
  деф echoServiceDependency = echoService

  преоверете деф testMessage: UrlPathElement = "hello"

  деф pollInterval: FiniteDuration = 1.second

  \/\/ конфигурация на контролера на жизнения цикъл
  деф lifetime: FiniteDuration = 10500.milliseconds \/\/ допълнителни 0.5 секунди, за да се постигнат 10 заявки, а не 9.
}

Тук създаваме единствена конфигурация, която разширява както конфигурацията на сървъра, така и конфигурацията на клиента. Също така конфигурираме контролер на жизнения цикъл, който нормално ще прекрати клиента и сървъра след жизнен цикъл изминаването на интервала.

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

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

  обект NodeServerConfig разширява EchoConfig[String] с SigTermLifecycleConfig
  {
    тип NodeId = NodeIdImpl

    деф nodeId = NodeServer

    преоверете деф portNumber: PortNumber = 8080
  }

  обект NodeClientConfig разширява EchoClientConfig[String] с FiniteDurationLifecycleConfig
  {
    \/\/ NB! спецификация на зависимост
    деф echoServiceDependency = NodeServerConfig.echoService

    деф pollInterval: FiniteDuration = 1.second

    деф lifetime: FiniteDuration = 10500.milliseconds \/\/ допълнителни 0.5 секунди, за да се постигнат 10 заявки, а не 9.

    деф testMessage: String = "dolly"
  }

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

Имплементация на два възела

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

  обект TwoJvmNodeServerImpl разширява ZeroServiceImpl[IO] с EchoServiceService и SigIntLifecycleServiceImpl {
    тип Config = EchoConfig[String] с SigTermLifecycleConfig
  }

  обект TwoJvmNodeClientImpl разширява ZeroServiceImpl[IO] с EchoClientService и FiniteDurationLifecycleServiceImpl {
    тип Config = EchoClientConfig[String] с FiniteDurationLifecycleConfig
  }

Първият възел имплементира сървър и му е необходима само конфигурацията на сървъра. Вторият възел имплементира клиент и нуждае се от другата част на конфигурацията. И двата възела имат нужда от специфікация на жизнения цикъл. За целите на тази публикация, обслужващият възел ще има безкраен жизнен цикъл, който може да бъде прекратен с SIGTERM, докато клиентът echo ще бъде прекратен след конфигурирания ограничен период. Вижте стартовото приложение за подробности.

Общ процес на разработка

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

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

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

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

Съществуват следните последици от подхода:

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

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

Вариации

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

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

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

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

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

Централизираното хранилище на ключ-стойност е добър механизъм за разпределение на мета параметрите на приложението. Тук трябва да помислим какво считаме за конфигурационни стойности и какво е просто данни. Имайки предвид функция C => A => B обикновено наричаме рядко променящите се стойности C «конфигурация», докато често променяните данни A — просто входни данни. Конфигурацията трябва да бъде предоставена на функцията по-рано от данните A. Имайки предвид тази идея, можем да кажем, че очакваната честота на промените може да се използва за разграничаване на конфигурационни данни от просто данни. Освен това данните обикновено идват от един източник (потребител), а конфигурацията идва от различен източник (администратор). Работата с параметри, които могат да бъдат променяни след инициализацията на процеса води до увеличаване на сложността на приложението. За такива параметри ще трябва да се справим с механизма им за доставка, анализ и валидиране, обработка на неправилни стойности. Затова, за да намалим сложността на програмата, е добре да намалим броя на параметрите, които могат да променят времето на работа (или дори да ги елиминираме напълно).

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

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

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

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

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

Тук бихме искали да подчертаем някои предимства и да обсъдим някои недостатъци на предложените подходи.

Предимства

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

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

Недостатъци

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

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

Има някои ограничения на реализирания пример:

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

Заключение

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

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

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

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

Благодаря

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

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