🥇Составена конфигурација на дистрибуиран систем

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

(англиски)

Вовед

Изградбата на сигурен дистрибуиран систем значи дека сите јазли ја користат правилната конфигурација, синхронизирана со други јазли. DevOps технологиите (terraform, ansible или нешто слично) обично се користат за автоматско генерирање на конфигурациски датотеки (често специфични за секој јазол). Исто така, би сакале да бидеме сигурни дека сите јазли кои комуницираат користат идентични протоколи (вклучувајќи ја и истата верзија). Во спротивно, некомпатибилноста ќе биде вградена во нашиот дистрибуиран систем. Во светот на JVM, една последица од ова барање е дека истата верзија на библиотеката што ги содржи протоколарните пораки мора да се користи насекаде.

Што е со тестирање на дистрибуиран систем? Се разбира, претпоставуваме дека сите компоненти имаат единечни тестови пред да преминеме на тестирање за интеграција. (За да можеме да ги екстраполираме резултатите од тестот на време на траење, мора да обезбедиме и идентичен сет на библиотеки во фазата на тестирање и при извршување.)

Кога работите со тестови за интеграција, често е полесно да се користи истата класна патека насекаде на сите јазли. Сè што треба да направиме е да се осигураме дека истата класна патека се користи при извршување. (Иако е целосно возможно да се извршуваат различни јазли со различни класични патеки, ова додава сложеност на целокупната конфигурација и тешкотии со тестовите за распоредување и интеграција.) За целите на овој пост, претпоставуваме дека сите јазли ќе користат иста класна патека.

Конфигурацијата се развива со апликацијата. Ние користиме верзии за да идентификуваме различни фази на еволуција на програмата. Се чини логично да се идентификуваат и различни верзии на конфигурации. И поставете ја самата конфигурација во системот за контрола на верзијата. Ако има само една конфигурација во производството, тогаш едноставно можеме да го користиме бројот на верзијата. Ако користиме многу инстанци на производство, тогаш ќе ни требаат неколку
гранки за конфигурација и дополнителна ознака во прилог на верзијата (на пример, името на гранката). На овој начин можеме јасно да ја идентификуваме точната конфигурација. Секој конфигурациски идентификатор уникатно одговара на специфична комбинација на дистрибуирани јазли, порти, надворешни ресурси и верзии на библиотеката. За целите на овој пост, ќе претпоставиме дека има само една гранка и можеме да ја идентификуваме конфигурацијата на вообичаен начин користејќи три броја одделени со точка (1.2.3).

Во современите средини, конфигурациските датотеки ретко се создаваат рачно. Почесто тие се генерираат за време на распоредувањето и повеќе не се допираат (така што не крши ништо). Се поставува природно прашање: зошто сè уште користиме формат на текст за да ја зачуваме конфигурацијата? Изгледа дека остварлива алтернатива е можноста да се користи редовен код за конфигурација и да има корист од проверките во времето на компајлирање.

Во овој пост ќе ја истражиме идејата за претставување на конфигурација во компајлиран артефакт.

Составена конфигурација

Овој дел дава пример на статична компајлирана конфигурација. Имплементирани се две едноставни услуги - услугата ехо и клиентот на услугата ехо. Врз основа на овие две услуги, се составуваат две системски опции. Во една опција, двете услуги се наоѓаат на истиот јазол, во друга опција - на различни јазли.

Обично дистрибуираниот систем содржи неколку јазли. Можете да ги идентификувате јазлите користејќи вредности од некој тип NodeId:

sealed trait NodeId
case object Backend extends NodeId
case object Frontend extends NodeId

или

case class NodeId(hostName: String)

или дури

object Singleton
type NodeId = Singleton.type

Јазлите извршуваат различни улоги, тие извршуваат услуги и меѓу нив може да се воспостават TCP/HTTP врски.

За да опишеме TCP конекција, потребен ни е барем број на порта. Исто така, би сакале да го одразиме протоколот што е поддржан на таа порта за да се осигураме дека и клиентот и серверот го користат истиот протокол. Ќе ја опишеме врската користејќи ја следната класа:

case class TcpEndPoint[Protocol](node: NodeId, port: Port[Protocol])

каде што Port - само цел број Int покажувајќи го опсегот на прифатливи вредности:

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

Рафинирани типови

Види библиотека рафинирано и мојот извештај. Накратко, библиотеката ви овозможува да додавате ограничувања на типовите што се проверуваат во времето на компајлирање. Во овој случај, важечките вредности на бројот на портата се 16-битни цели броеви. За компајлирана конфигурација, користењето на рафинираната библиотека не е задолжително, но ја подобрува способноста на компајлерот да ја провери конфигурацијата.

За протоколите HTTP (REST), покрај бројот на портата, можеби ќе ни треба и патеката до услугата:

type UrlPathPrefix = Refined[String, MatchesRegex[W.`"[a-zA-Z_0-9/]*"`.T]]
case class PortWithPrefix[Protocol](portNumber: PortNumber, pathPrefix: UrlPathPrefix)

Фантомски типови

За да го идентификуваме протоколот во времето на компајлирање, користиме параметар за тип кој не се користи во класата. Оваа одлука се должи на фактот што не користиме примерок од протокол при извршување, но би сакале компајлерот да ја провери компатибилноста на протоколот. Со наведување на протоколот, нема да можеме да пренесеме несоодветна услуга како зависност.

Еден од вообичаените протоколи е REST API со серијализација на Json:

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

каде што RequestMessage - тип на барање, ResponseMessage - тип на одговор.
Се разбира, можеме да користиме други описи на протоколот што ја обезбедуваат точноста на описот што ни е потребен.

За целите на овој пост, ќе користиме поедноставена верзија на протоколот:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

Овде барањето е низа додадена на URL-то и одговорот е вратената низа во телото на одговорот HTTP.

Конфигурацијата на услугата е опишана со името на услугата, портите и зависностите. Овие елементи можат да бидат претставени во Скала на неколку начини (на пример, HList-s, алгебарски типови на податоци). За целите на овој пост, ќе го користиме моделот за торта и ќе ги претставуваме модулите со користење trait'ов. (Моделот за торта не е задолжителен елемент на овој пристап. Тоа е едноставно една можна имплементација.)

Зависностите помеѓу услугите може да се претстават како методи кои враќаат порти EndPointна други јазли:

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

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

За да креирате услуга за ехо, се што ви треба е број на порта и индикација дека пристаништето го поддржува протоколот за ехо. Можеби нема да наведеме одредена порта, бидејќи ... карактеристиките ви дозволуваат да декларирате методи без имплементација (апстрактни методи). Во овој случај, при креирање на конкретна конфигурација, компајлерот ќе бара од нас да обезбедиме имплементација на апстрактниот метод и да обезбедиме број на порта. Бидејќи го имплементиравме методот, при креирање на одредена конфигурација, можеби нема да наведеме друга порта. Ќе се користи стандардната вредност.

Во конфигурацијата на клиентот, прогласуваме зависност од услугата ехо:

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

Зависноста е од ист тип како и извезената услуга echoService. Конкретно, во клиентот echo го бараме истиот протокол. Затоа, при поврзување на две услуги, можеме да бидеме сигурни дека сè ќе работи правилно.

Имплементација на услуги

Потребна е функција за започнување и запирање на услугата. (Способноста да се запре услугата е критична за тестирање.) Повторно, постојат неколку опции за имплементација на таква функција (на пример, би можеле да користиме класи на типови врз основа на типот на конфигурација). За целите на оваа објава ќе го користиме моделот за торта. Ќе ја претставуваме услугата користејќи класа cats.Resource, бидејќи Оваа класа веќе обезбедува средства за безбедно да се гарантира ослободување на ресурси во случај на проблеми. За да добиеме ресурс, треба да обезбедиме конфигурација и готов контекст за траење. Функцијата за стартување на услугата може да изгледа вака:

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

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

каде што

Config — тип на конфигурација за оваа услуга
AddressResolver — објект за траење што ви овозможува да ги дознаете адресите на другите јазли (видете подолу)

и други видови од библиотеката cats:

F[_] — тип на ефект (во наједноставен случај F[A] може да биде само функција () => A. Во овој пост ќе користиме cats.IO.)
Reader[A,B] - повеќе или помалку синоним за функција A => B
cats.Resource - ресурс што може да се добие и да се ослободи
Timer — тајмер (ви овозможува да заспиете некое време и да ги измерите временските интервали)
ContextShift - аналоген ExecutionContext
Applicative — класа на тип на ефект што ви овозможува да комбинирате поединечни ефекти (речиси монада). Во посложени апликации изгледа подобро да се користи Monad/ConcurrentEffect.

Користејќи го овој потпис на функцијата, можеме да имплементираме неколку услуги. На пример, услуга што не прави ништо:

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

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

Јазол е објект што може да стартува неколку услуги (покренувањето на синџир на ресурси е обезбедено со моделот на торта):

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

Ве молиме имајте предвид дека го одредуваме точниот тип на конфигурација што е потребен за овој јазол. Ако заборавиме да наведеме еден од типовите на конфигурација што ги бара одредена услуга, ќе има грешка при компилацијата. Исто така, нема да можеме да започнеме јазол освен ако не обезбедиме некој објект од соодветен тип со сите потребни податоци.

Резолуција за името на домаќинот

За да се поврземе со оддалечен домаќин, потребна ни е вистинска IP адреса. Можно е адресата да стане позната подоцна од остатокот од конфигурацијата. Значи, ни треба функција која го мапира ID на јазол на адреса:

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

Постојат неколку начини за спроведување на оваа функција:

Ако адресите ни станат познати пред распоредувањето, тогаш можеме да генерираме Scala код со
адреси и потоа извршете ја изградбата. Ова ќе компајлира и ќе изврши тестови.
Во овој случај, функцијата ќе биде позната статички и може да биде претставена во код како мапирање Map[NodeId, NodeAddress].
Во некои случаи, вистинската адреса е позната само откако ќе започне јазолот.
Во овој случај, можеме да имплементираме „услуга за откривање“ која работи пред другите јазли и сите јазли ќе се регистрираат со оваа услуга и ќе побараат адреси на други јазли.
Ако можеме да измениме /etc/hosts, тогаш можете да користите претходно дефинирани имиња на домаќини (како my-project-main-node и echo-backend) и едноставно поврзете ги овие имиња
со IP адреси за време на распоредувањето.

Во овој пост нема да ги разгледуваме овие случаи подетално. За нашите
во пример за играчки, сите јазли ќе имаат иста IP адреса - 127.0.0.1.

Следно, разгледуваме две опции за дистрибуиран систем:

Поставување на сите услуги на еден јазол.
И хостирање на услугата ехо и клиентот за ехо на различни јазли.

Конфигурација за еден јазол:

Конфигурација на еден јазол

object SingleNodeConfig extends EchoConfig[String] 
  with EchoClientConfig[String] with FiniteDurationLifecycleConfig
{
  case object Singleton // identifier of the single node 
  // configuration of server
  type NodeId = Singleton.type
  def nodeId = Singleton

  /** Type safe service port specification. */
  override def portNumber: PortNumber = 8088

  // configuration of client

  /** We'll use the service provided by the same host. */
  def echoServiceDependency = echoService

  override def testMessage: UrlPathElement = "hello"

  def pollInterval: FiniteDuration = 1.second

  // lifecycle controller configuration
  def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 requests, not 9.
}

Објектот ја имплементира конфигурацијата и на клиентот и на серверот. Исто така се користи и конфигурација за време до живеење така што по интервалот lifetime прекинете ја програмата. (Ctrl-C исто така работи и правилно ги ослободува сите ресурси.)

Истиот сет на карактеристики за конфигурација и имплементација може да се користи за да се создаде систем кој се состои од два посебни јазли:

Конфигурација на два јазли

  object NodeServerConfig extends EchoConfig[String] with SigTermLifecycleConfig
  {
    type NodeId = NodeIdImpl

    def nodeId = NodeServer

    override def portNumber: PortNumber = 8080
  }

  object NodeClientConfig extends EchoClientConfig[String] with FiniteDurationLifecycleConfig
  {
    // NB! dependency specification
    def echoServiceDependency = NodeServerConfig.echoService

    def pollInterval: FiniteDuration = 1.second

    def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 request, not 9.

    def testMessage: String = "dolly"
  }

Важно! Забележете како услугите се поврзани. Назначуваме услуга имплементирана од еден јазол како имплементација на методот на зависност на друг јазол. Типот на зависност го проверува компајлерот, бидејќи го содржи типот на протокол. Кога ќе се изврши, зависноста ќе го содржи точниот ID на целниот јазол. Благодарение на оваа шема, точно еднаш го одредуваме бројот на пристаништето и секогаш гарантираме дека ќе се однесува на правилната порта.

Имплементација на два системски јазли

За оваа конфигурација, ги користиме истите сервисни имплементации без промени. Единствената разлика е во тоа што сега имаме два објекти кои имплементираат различни групи на услуги:

  object TwoJvmNodeServerImpl extends ZeroServiceImpl[IO] with EchoServiceService with SigIntLifecycleServiceImpl {
    type Config = EchoConfig[String] with SigTermLifecycleConfig
  }

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

Првиот јазол го имплементира серверот и потребна е само конфигурација на серверот. Вториот јазол го имплементира клиентот и користи различен дел од конфигурацијата. Исто така и на двата јазли им треба доживотно управување. Серверскиот јазол работи на неодредено време додека не се запре SIGTERM'om, и клиентскиот јазол завршува по некое време. Цм. апликација за фрлач.

Општ процес на развој

Ајде да видиме како овој пристап на конфигурација влијае на целокупниот развојен процес.

Конфигурацијата ќе се компајлира заедно со остатокот од кодот и ќе се генерира артефакт (.jar). Се чини дека има смисла да се стави конфигурацијата во посебен артефакт. Тоа е затоа што можеме да имаме повеќе конфигурации врз основа на истиот код. Повторно, можно е да се генерираат артефакти што одговараат на различни конфигурациски гранки. Зависностите од одредени верзии на библиотеките се зачувуваат заедно со конфигурацијата, и овие верзии се зачувуваат засекогаш секогаш кога ќе одлучиме да ја распоредиме таа верзија на конфигурацијата.

Секоја промена на конфигурацијата се претвора во промена на кодот. И затоа, секој
промената ќе биде покриена со нормалниот процес за обезбедување квалитет:

Билет во тракерот за бубачки -> ПР -> преглед -> спојување со соодветните гранки ->
интеграција -> распоредување

Главните последици од спроведувањето на компајлирана конфигурација се:

Конфигурацијата ќе биде конзистентна низ сите јазли на дистрибуираниот систем. Поради фактот што сите јазли добиваат иста конфигурација од еден извор.
Проблематично е да се смени конфигурацијата само во еден од јазлите. Затоа, „поднесувањето на конфигурацијата“ е малку веројатно.
Станува потешко да се прават мали промени во конфигурацијата.
Повеќето промени во конфигурацијата ќе се случат како дел од целокупниот процес на развој и ќе бидат предмет на преглед.

Дали ми треба посебно складиште за складирање на производната конфигурација? Оваа конфигурација може да содржи лозинки и други чувствителни информации до кои би сакале да го ограничиме пристапот. Врз основа на ова, се чини дека има смисла да се складира конечната конфигурација во посебно складиште. Можете да ја поделите конфигурацијата на два дела - еден што содржи јавно достапни поставки за конфигурација и еден што содржи ограничени поставки. Ова ќе им овозможи на повеќето програмери да имаат пристап до заедничките поставки. Ова раздвојување е лесно да се постигне со користење на средни особини кои содржат стандардни вредности.

Можни варијации

Ајде да се обидеме да ја споредиме компајлираната конфигурација со некои вообичаени алтернативи:

Текстуална датотека на целната машина.
Централизирана продавница со вредност на клучот (etcd/zookeeper).
Процес на компоненти кои може да се реконфигурираат/рестартираат без рестартирање на процесот.
Зачувување на конфигурацијата надвор од контролата на артефакт и верзија.

Текстуалните датотеки обезбедуваат значителна флексибилност во однос на мали промени. Администраторот на системот може да се најави во оддалечениот јазол, да направи промени во соодветните датотеки и да ја рестартира услугата. Меѓутоа, за големи системи, таквата флексибилност можеби не е пожелна. Направените промени не оставаат траги во другите системи. Никој не ги разгледува промените. Тешко е да се одреди кој точно ги направил промените и поради која причина. Промените не се тестираат. Ако системот е дистрибуиран, тогаш администраторот може да заборави да ја направи соодветната промена на другите јазли.

(Исто така, треба да се забележи дека користењето на компајлирана конфигурација не ја затвора можноста за користење текстуални датотеки во иднина. Ќе биде доволно да додадете парсер и валидатор што произведува ист тип како излезот Config, и можете да користите текстуални датотеки. Веднаш следи дека сложеноста на системот со компајлирана конфигурација е нешто помала од сложеноста на системот што користи текстуални датотеки, бидејќи текстуалните датотеки бараат дополнителен код.)

Централизирана продавница за клучеви со вредност е добар механизам за дистрибуција на мета параметрите на дистрибуирана апликација. Треба да одлучиме што се конфигурациски параметри, а што се само податоци. Да имаме функција C => A => B, и параметрите C ретко се менува, а податоците A - често. Во овој случај можеме да го кажеме тоа C - параметри за конфигурација, и A - податоци. Се чини дека параметрите за конфигурација се разликуваат од податоците по тоа што тие обично се менуваат поретко од податоците. Исто така, податоците обично доаѓаат од еден извор (од корисникот), а параметрите за конфигурација од друг (од системскиот администратор).

Ако ретко променливите параметри треба да се ажурираат без рестартирање на програмата, тогаш тоа често може да доведе до компликација на програмата, бидејќи ќе треба некако да испорачаме параметри, да складираме, анализираме и проверуваме и да обработуваме неточни вредности. Затоа, од гледна точка на намалување на сложеноста на програмата, има смисла да се намали бројот на параметри кои можат да се променат за време на работата на програмата (или воопшто да не поддржуваат такви параметри).

За целите на овој пост, ќе направиме разлика помеѓу статички и динамички параметри. Ако логиката на услугата бара менување на параметрите за време на работата на програмата, тогаш таквите параметри ќе ги наречеме динамични. Во спротивно, опциите се статични и може да се конфигурираат со помош на компајлираната конфигурација. За динамична реконфигурација, можеби ќе ни треба механизам за рестартирање на делови од програмата со нови параметри, слично на тоа како се рестартираат процесите на оперативниот систем. (Според нас, препорачливо е да се избегне реконфигурација во реално време, бидејќи тоа ја зголемува сложеноста на системот. Ако е можно, подобро е да ги користите стандардните способности на ОС за рестартирање на процесите.)

Еден важен аспект на користење на статичка конфигурација што ги тера луѓето да размислуваат за динамичка реконфигурација е времето потребно за системот да се рестартира по ажурирање на конфигурацијата (време на прекин). Всушност, ако треба да направиме промени во статичката конфигурација, ќе треба да го рестартираме системот за да стапат на сила новите вредности. Проблемот со застојот варира по сериозност за различни системи. Во некои случаи, можете да закажете рестартирање во време кога оптоварувањето е минимално. Ако треба да обезбедите континуирана услуга, можете да имплементирате AWS ELB поврзување одвод. Во исто време, кога треба да го рестартираме системот, стартуваме паралелен примерок од овој систем, го префрламе балансерот на него и чекаме да се завршат старите врски. Откако ќе се прекинат сите стари врски, ја исклучивме старата инстанца на системот.

Сега да го разгледаме прашањето за складирање на конфигурацијата внатре или надвор од артефактот. Ако ја складираме конфигурацијата во артефакт, тогаш барем имавме можност да ја потврдиме исправноста на конфигурацијата за време на склопувањето на артефактот. Ако конфигурацијата е надвор од контролираниот артефакт, тешко е да се следи кој направил промени во оваа датотека и зошто. Колку е важно? Според наше мислење, за многу системи за производство е важно да се има стабилна и висококвалитетна конфигурација.

Верзијата на артефакт ви овозможува да одредите кога е создаден, кои вредности ги содржи, кои функции се овозможени/оневозможени и кој е одговорен за каква било промена во конфигурацијата. Се разбира, складирањето на конфигурацијата во артефакт бара одреден напор, па затоа треба да донесете информирана одлука.

Добрите и лошите страни

Би сакал да се задржам на добрите и лошите страни на предложената технологија.

Предности

Подолу е листа на главните карактеристики на компајлирана конфигурација на дистрибуиран систем:

Проверка на статичка конфигурација. Ви овозможува да бидете сигурни во тоа
конфигурацијата е точна.
Богат конфигурациски јазик. Вообичаено, другите методи на конфигурација се ограничени најмногу на замена на променливата низа. Кога користите Scala, достапни се широк спектар на јазични функции за подобрување на вашата конфигурација. На пример, можеме да користиме
особини за стандардните вредности, користејќи објекти за групирање параметри, можеме да се повикаме на vals декларирани само еднаш (DRY) во оградениот опсег. Можете да инстанцирате какви било класи директно во конфигурацијата (Seq, Map, прилагодени часови).
DSL. Scala има голем број јазични карактеристики кои го олеснуваат креирањето на DSL. Можно е да се искористат предностите на овие карактеристики и да се имплементира конфигурациски јазик кој е попогоден за целната група корисници, така што конфигурацијата е барем читлива од експертите на доменот. Специјалистите можат, на пример, да учествуваат во процесот на преглед на конфигурацијата.
Интегритет и синхронија помеѓу јазлите. Една од предностите на конфигурацијата на цел дистрибуиран систем складирана во една точка е тоа што сите вредности се декларираат точно еднаш, а потоа повторно се користат каде и да се потребни. Користењето фантомски типови за декларирање порти гарантира дека јазлите користат компатибилни протоколи во сите правилни системски конфигурации. Имајќи експлицитни задолжителни зависности помеѓу јазлите осигурува дека сите услуги се поврзани.
Висококвалитетни промени. Правењето промени во конфигурацијата користејќи заеднички процес на развој овозможува да се постигнат високи стандарди за квалитет и за конфигурацијата.
Симултано ажурирање на конфигурацијата. Автоматското распоредување на системот по промените во конфигурацијата осигурува дека сите јазли се ажурираат.
Поедноставување на апликацијата. На апликацијата не и треба парсирање, проверка на конфигурацијата или ракување со неточни вредности. Ова ја намалува сложеноста на апликацијата. (Дел од сложеноста на конфигурацијата забележана во нашиот пример не е атрибут на компајлираната конфигурација, туку само свесна одлука водена од желбата да се обезбеди поголема безбедност на типот.) Сосема е лесно да се вратите на вообичаената конфигурација - само имплементирајте го она што недостасува Делови. Затоа, можете, на пример, да започнете со компајлирана конфигурација, одложувајќи ја имплементацијата на непотребните делови до времето кога навистина е потребно.
Проверена конфигурација. Бидејќи промените во конфигурацијата ја следат вообичаената судбина на сите други промени, излезот што го добиваме е артефакт со единствена верзија. Ова ни овозможува, на пример, да се вратиме на претходната верзија на конфигурацијата доколку е потребно. Можеме дури и да ја користиме конфигурацијата од пред една година и системот ќе работи исто. Стабилната конфигурација ја подобрува предвидливоста и доверливоста на дистрибуираниот систем. Бидејќи конфигурацијата е фиксирана во фазата на компилација, доста е тешко да се лажира во производството.
Модуларност. Предложената рамка е модуларна и модулите може да се комбинираат на различни начини за да се создадат различни системи. Конкретно, можете да го конфигурирате системот да работи на еден јазол во едно отелотворување и на повеќе јазли во друг. Можете да креирате неколку конфигурации за производствени примероци на системот.
Тестирање. Со замена на поединечни услуги со лажни објекти, можете да добиете неколку верзии на системот што се погодни за тестирање.
Тестирање за интеграција. Имањето единствена конфигурација за целиот дистрибуиран систем овозможува да се извршуваат сите компоненти во контролирана средина како дел од тестирањето за интеграција. Лесно е да се емулира, на пример, ситуација кога некои јазли стануваат достапни.

Недостатоци и ограничувања

Компајлираната конфигурација се разликува од другите конфигурациски пристапи и можеби не е погодна за некои апликации. Подолу се дадени некои недостатоци:

Статичка конфигурација. Понекогаш треба брзо да ја поправите конфигурацијата во производството, заобиколувајќи ги сите заштитни механизми. Со овој пристап може да биде потешко. Во најмала рака, сè уште ќе биде потребна компилација и автоматско распоредување. Ова е и корисна карактеристика на пристапот и недостаток во некои случаи.
Генерирање на конфигурација. Во случај конфигурациската датотека да се генерира со автоматска алатка, може да бидат потребни дополнителни напори за интегрирање на скриптата за изградба.
Алатки. Во моментов, алатките и техниките дизајнирани да работат со конфигурација се засноваат на текстуални датотеки. Сите такви алатки/техники нема да бидат достапни во компајлирана конфигурација.
Потребна е промена во ставовите. Програмерите и DevOps се навикнати на текстуални датотеки. Самата идеја за составување конфигурација може да биде малку неочекувана и невообичаена и да предизвика отфрлање.
Потребен е висококвалитетен процес на развој. За удобно користење на компајлираната конфигурација, потребна е целосна автоматизација на процесот на градење и распоредување на апликацијата (CI/CD). Во спротивно ќе биде доста незгодно.

Да се задржиме и на голем број ограничувања на разгледуваниот пример што не се поврзани со идејата за компајлирана конфигурација:

Ако обезбедиме непотребни информации за конфигурација кои не се користат од јазолот, тогаш компајлерот нема да ни помогне да ја откриеме имплементацијата што недостасува. Овој проблем може да се реши со напуштање на моделот за торта и користење на поригидни типови, на пример, HList или алгебарски типови на податоци (класи на случаи) за претставување на конфигурацијата.
Има линии во конфигурациската датотека што не се поврзани со самата конфигурација: (package, import,декларации на предмети; override def's за параметри кои имаат стандардни вредности). Ова може делумно да се избегне ако имплементирате сопствен DSL. Покрај тоа, други видови конфигурации (на пример, XML) исто така наметнуваат одредени ограничувања на структурата на датотеката.
За целите на овој пост, не размислуваме за динамичка реконфигурација на кластер од слични јазли.

Заклучок

Во овој пост, ја истраживме идејата за претставување на конфигурацијата во изворниот код користејќи ги напредните можности на системот од типот Scala. Овој пристап може да се користи во различни апликации како замена за традиционалните методи за конфигурација базирани на xml или текстуални датотеки. Иако нашиот пример е имплементиран во Scala, истите идеи може да се пренесат на други компајлирани јазици (како што се Kotlin, C#, Swift, ...). Овој пристап можете да го испробате во еден од следните проекти и, ако не функционира, преминете на текстуалната датотека, додавајќи ги деловите што недостасуваат.

Секако, компајлираната конфигурација бара висококвалитетен процес на развој. За возврат, се обезбедува висок квалитет и сигурност на конфигурациите.

Разгледаниот пристап може да се прошири:

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

Благодарници

Би сакал да им се заблагодарам на Андреј Саксонов, Павел Попов и Антон Нехаев за нивната конструктивна критика на нацрт-написот.

Извор: www.habr.com

Составена конфигурација на дистрибуиран систем