Грађевински блокови дистрибуираних апликација. Друга апроксимација

Најава

Колеге, средином лета планирам да објавим још једну серију чланака о дизајну система чекања: "ВТраде експеримент" - покушај да се напише оквир за системе трговања. Серија ће испитати теорију и праксу изградње берзе, аукције и продавнице. На крају чланка вас позивам да гласате за теме које вас највише занимају.

Ово је последњи чланак у серији о дистрибуираним реактивним апликацијама у Ерланг/Еликир-у. ИН први чланак можете пронаћи теоријске основе реактивне архитектуре. Други чланак илуструје основне обрасце и механизме за конструисање оваквих система.

Данас ћемо покренути питања развоја базе кодова и пројеката уопште.

Организација услуга

У стварном животу, када развијате услугу, често морате комбиновати неколико образаца интеракције у једном контролеру. На пример, кориснички сервис, који решава проблем управљања профилима корисника пројекта, мора да одговори на рек-респ захтеве и да пријави ажурирања профила преко пуб-суб-а. Овај случај је прилично једноставан: иза размјене порука постоји један контролер који имплементира логику услуге и објављује ажурирања.

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

1. сада сервис треба да обрађује захтеве на 5 чворова кластера,
2. бити у стању да обавља задатке обраде у позадини,
3. и такође бити у могућности да динамички управљате листама претплате за ажурирања профила.

Коментар: Не разматрамо питање доследног складиштења и репликације података. Претпоставимо да су ови проблеми раније решени и да систем већ има поуздан и скалабилан слој складиштења, а руковаоци имају механизме за интеракцију са њим.

Формални опис корисничке услуге је постао компликованији. Са тачке гледишта програмера, промене су минималне због коришћења порука. Да бисмо задовољили први захтев, морамо да конфигуришемо балансирање на тачки размене рек-респ.

Често се јавља захтев за обрадом задатака у позадини. Код корисника, то може бити провера корисничких докумената, обрада преузетих мултимедија или синхронизација података са друштвеним медијима. мреже. Ови задаци се морају некако распоредити унутар кластера и пратити напредак извршења. Због тога имамо две опције решења: или користите шаблон за дистрибуцију задатака из претходног чланка, или, ако не одговара, напишете прилагођени планер задатака који ће управљати скупом процесора на начин који нам је потребан.

Тачка 3 захтева проширење шаблона пуб-суб. А за имплементацију, након креирања пуб-суб тачке размене, потребно је додатно покренути контролер ове тачке у оквиру нашег сервиса. Дакле, као да премештамо логику обраде претплата и одјава са слоја за размену порука у имплементацију корисника.

Као резултат тога, декомпозиција проблема је показала да да бисмо испунили захтеве, потребно је да покренемо 5 инстанци услуге на различитим чворовима и креирамо додатни ентитет - пуб-суб контролер, одговоран за претплату.
Да бисте покренули 5 руковалаца, не морате да мењате сервисни код. Једина додатна радња је постављање правила балансирања на месту размене, о чему ћемо мало касније.
Постоји и додатна сложеност: пуб-суб контролер и прилагођени планер задатака морају да раде у једној копији. Опет, сервис за размену порука, као основни, мора да обезбеди механизам за избор лидера.

Избор лидера

У дистрибуираним системима, избор лидера је процедура за именовање једног процеса одговорног за заказивање дистрибуиране обраде неког оптерећења.

У системима који нису склони централизацији, користе се универзални алгоритми засновани на консензусу, као што су пакос или рафт.
Пошто је размена порука посредник и централни елемент, она зна за све контролоре услуга - лидере кандидата. Мессагинг може именовати лидера без гласања.

Након покретања и повезивања на тачку размене, све услуге добијају системску поруку #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. Ако LeaderPid поклапа се са pid тренутног процеса, именован је за лидера, а листа Servers укључује све чворове и њихове параметре.
У тренутку када се појави нови и радни чвор кластера је искључен, сви сервисни контролери примају #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} респективно.

На овај начин, све компоненте су свесне свих промена, а кластер гарантовано има једног лидера у сваком тренутку.

Посредници

За имплементацију сложених процеса дистрибуиране обраде, као иу проблемима оптимизације постојеће архитектуре, згодно је користити посреднике.
Да не бисте мењали шифру услуге и решавали, на пример, проблеме додатне обраде, рутирања или евидентирања порука, пре сервиса можете да омогућите прокси руковалац, који ће обављати сав додатни посао.

Класичан пример пуб-суб оптимизације је дистрибуирана апликација са пословним језгром која генерише догађаје ажурирања, као што су промене цена на тржишту, и слој приступа - Н сервери који обезбеђују вебсоцкет АПИ за веб клијенте.
Ако се одлучите директно, онда служба за кориснике изгледа овако:

• клијент успоставља везе са платформом. На страни сервера који прекида саобраћај, покреће се процес за сервисирање ове везе.
• У контексту процеса услуге, долази до ауторизације и претплате на ажурирања. Процес позива методу претплате за теме.
• Када се догађај генерише у кернелу, он се испоручује процесима који опслужују везе.

Замислимо да имамо 50000 претплатника на тему „вести“. Претплатници су равномерно распоређени на 5 сервера. Као резултат, свако ажурирање, које стигне на тачку размене, биће реплицирано 50000 пута: 10000 пута на сваком серверу, у складу са бројем претплатника на њему. Није баш ефикасна шема, зар не?
Да бисмо побољшали ситуацију, уведемо проки који има исто име као и тачка размене. Глобални регистратор имена мора бити у могућности да врати најближи процес по имену, ово је важно.

Хајде да покренемо овај проки на серверима приступног слоја, и сви наши процеси који опслужују вебсоцкет апи ће се претплатити на њега, а не на оригиналну тачку размене пуб-суб у кернелу. Прокси се претплаћује на језгро само у случају јединствене претплате и реплицира долазну поруку свим својим претплатницима.
Као резултат, 5 порука ће бити послато између кернела и приступних сервера, уместо 50000.

Рутирање и балансирање

Рек-Респ

У тренутној имплементацији порука постоји 7 стратегија дистрибуције захтева:

• default. Захтев се шаље свим контролорима.
• round-robin. Захтеви се набрајају и циклично дистрибуирају између контролора.
• consensus. Контролори који служе служби деле се на вође и робове. Захтеви се шаљу само лидеру.
• consensus & round-robin. Група има вођу, али се захтеви дистрибуирају међу свим члановима.
• sticky. Хеш функција се израчунава и додељује одређеном руковаоцу. Накнадни захтеви са овим потписом иду истом руковаоцу.
• sticky-fun. Приликом иницијализације тачке размене, функција израчунавања хеша за sticky балансирање.
• fun. Слично лепљивој забави, само ви то можете додатно преусмерити, одбацити или претходно обрадити.

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

Поред балансирања, размена порука вам омогућава да означите ентитете. Хајде да погледамо типове ознака у систему:

• Ознака везе. Омогућава вам да разумете кроз коју везу су догађаји дошли. Користи се када се процес контролера повезује на исту тачку размене, али са различитим кључевима за рутирање.
• Сервис ознака. Омогућава вам да комбинујете руковаоце у групе за једну услугу и проширите могућности рутирања и балансирања. За образац рек-респ, рутирање је линеарно. Шаљемо захтев на место размене, а онда га он прослеђује сервису. Али ако треба да поделимо руковаоце у логичке групе, онда се подела врши помоћу ознака. Приликом навођења ознаке, захтев ће бити послат одређеној групи контролора.
• Захтевај ознаку. Омогућава вам да разликујете одговоре. Пошто је наш систем асинхрони, за обраду одговора услуге морамо бити у могућности да наведемо РекуестТаг приликом слања захтева. Из ње ћемо моћи да разумемо одговор на који нам је захтев стигао.

Пуб-суб

За паб-суб све је мало једноставније. Имамо место размене на које се објављују поруке. Тачка размене дистрибуира поруке међу претплатницима који су се претплатили на кључеве за рутирање који су им потребни (можемо рећи да је то аналогно темама).

Скалабилност и толеранција грешака

Скалабилност система у целини зависи од степена скалабилности слојева и компоненти система:

• Услуге се скалирају додавањем додатних чворова у кластер са руковаоцима за ову услугу. Током пробног рада, можете изабрати оптималну политику балансирања.
• Сама услуга за размену порука унутар засебног кластера се генерално скалира или премештањем посебно оптерећених тачака размене у одвојене чворове кластера, или додавањем прокси процеса у посебно учитане области кластера.
• Скалабилност целог система као карактеристика зависи од флексибилности архитектуре и могућности комбиновања појединачних кластера у заједничку логичку целину.

Успех пројекта често зависи од једноставности и брзине скалирања. Размена порука у својој тренутној верзији расте заједно са апликацијом. Чак и ако нам недостаје кластер од 50-60 машина, можемо прибећи федерацији. Нажалост, тема федерације је ван оквира овог чланка.

Резервација

Када смо анализирали балансирање оптерећења, већ смо разговарали о редундантности сервисних контролера. Међутим, поруке такође морају бити резервисане. У случају пада чвора или машине, размена порука треба аутоматски да се опорави и то у најкраћем могућем року.

У својим пројектима користим додатне чворове који преузимају оптерећење у случају пада. Ерланг има стандардну имплементацију дистрибуираног режима за ОТП апликације. Дистрибуирани режим врши опоравак у случају квара покретањем неуспеле апликације на другом претходно покренутом чвору. Процес је транспарентан; након квара, апликација се аутоматски помера на чвор за прелазак преко грешке. Можете прочитати више о овој функцији овде.

Перформансе

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

У ставу 6.14.1.2.1.2.2. Оригинални документ приказује резултат РПЦ ЦАСТ-а:

Нећемо унапред вршити никаква додатна подешавања за језгро ОС-а или ерланг ВМ. Услови за тестирање:

• ерл бира: +А1 +сбту.
• Тест унутар једног ерланг чвора се изводи на лаптопу са старим и7 у мобилној верзији.
• Кластер тестови се спроводе на серверима са 10Г мрежом.
• Код се покреће у доцкер контејнерима. Мрежа у НАТ режиму.

Тест код:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

Сценарио 1: Тест се изводи на лаптопу са старом и7 мобилном верзијом. Тест, размена порука и услуга се извршавају на једном чвору у једном Доцкер контејнеру:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

Сценарио 2: 3 чвора који раде на различитим машинама под доцкер-ом (НАТ).

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

У свим случајевима, искоришћеност ЦПУ-а није прелазила 250%

Резултати

Надам се да овај циклус неће изгледати као сметлиште ума и да ће моје искуство бити од стварне користи и истраживачима дистрибуираних система и практичарима који су на самом почетку изградње дистрибуираних архитектура за своје пословне системе и са интересовањем гледају на Ерланг/Еликир , али сумњам да ли вреди...

Фотографија @цхуттерснап

Само регистровани корисници могу учествовати у анкети. Пријавите се, Добродошао си.

Које теме треба да покријем детаљније у оквиру серије ВТраде Екперимент?

• Теорија: Тржишта, налози и њихово време: ДАИ, ГТД, ГТЦ, МОЦ, ФОК, МОО, МОЦ, ЛОО, ЛОЦ

• Књига наређења. Теорија и пракса имплементације књиге са групацијама

• Визуелизација трговања: Тикови, шипке, резолуције. Како чувати и како лепити

• Канцеларија за подршку. Планирање и развој. Праћење запослених и истрага инцидента

• АПИ. Хајде да схватимо који су интерфејси потребни и како их имплементирати

• Складиштење информација: ПостгреСКЛ, Тимесцале, Тарантоол у ​​системима за трговање

• Реактивност у системима трговања

• Остало. Писаћу у коментарима

Гласало је 6 корисника. 4 корисника су била уздржана.

Извор: ввв.хабр.цом