Превод на статијата: Модел на нишки за испраќање - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

Овој напис ми беше доста интересен, и бидејќи Envoy најчесто се користи како дел од „istio“ или едноставно како „контролор на влез“ на kubernetes, повеќето луѓе ја немаат истата директна интеракција со него како, на пример, со типичните Инсталации Nginx или Haproxy. Меѓутоа, ако нешто се скрши, би било добро да се разбере како функционира одвнатре. Се обидов да преведам што е можно повеќе од текстот на руски, вклучително и посебни зборови за оние на кои им е болно да го погледнат ова, ги оставив оригиналите во загради. Добредојдовте во мачка.

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

Едно од најчестите технички прашања што ги добивам за Envoy е барањето за опис на ниско ниво на моделот на нишки што го користи. Во овој пост, ќе опишам како Envoy ги мапира врските со нишките, како и системот за локално складирање на нишки што го користи внатрешно за да го направи кодот повеќе паралелен и со високи перформанси.

Преглед на нишки

Envoy користи три различни типови на струи:

• Главна: Оваа нишка го контролира стартувањето и завршувањето на процесот, целата обработка на API-то на XDS (xDiscovery Service), вклучително и DNS, проверка на здравјето, општо управување со кластери и време на траење, ресетирање на статистика, администрирање и генерално управување со процесите - жешко рестартирање на Linux, итн се случува во оваа нишка е асинхрона и „неблокирачка“. Општо земено, главната нишка ги координира сите процеси на критична функционалност за кои не е потребна голема количина на процесорот за извршување. Ова им овозможува на повеќето контролни кодови да се напишат како да е со една нишка.
• Работник: Стандардно, Envoy создава работничка нишка за секоја хардверска нишка во системот, тоа може да се контролира со користење на опцијата --concurrency. Секоја работничка нишка води „неблокирачка“ јамка на настани, која е одговорна за слушање на секој слушател во моментот на пишување (29 јули 2017 година) нема поделба на слушателот, прифаќање нови врски, инстанцирање на стек филтер за; поврзувањето и обработката на сите влезно/излезни (IO) операции за време на траењето на врската. Повторно, ова им овозможува на повеќето кодови за ракување со конекции да бидат напишани како да се со една нишка.
• Прочистувач на датотеки: Секоја датотека што ја пишува Envoy, главно логови за пристап, моментално има независна нишка за блокирање. Ова се должи на фактот дека пишувањето на датотеки кеширани од датотечниот систем дури и кога се користи O_NONBLOCK понекогаш може да се блокира (воздишка). Кога работните нишки треба да запишуваат во датотека, податоците всушност се преместуваат во бафер во меморијата каде што на крајот се мијат низ низата датотека рамна. Ова е една област од кодот каде технички сите работни нишки можат да го блокираат истото заклучување додека се обидуваат да пополнат мемориски бафер.

Ракување со поврзување

Како што беше дискутирано накратко погоре, сите работни нишки ги слушаат сите слушатели без никакво трошење. Така, кернелот се користи за благодатно испраќање прифатени сокети до работните нишки. Современите кернели генерално се многу добри во ова, тие користат функции како што е зајакнувањето на приоритетот на влез/излез (IO) за да се обидат да ја пополнат нишката со работа пред да почнат да користат други нишки кои исто така слушаат на истиот приклучок, а исто така не користат круг-робин заклучување (Spinlock) за обработка на секое барање.
Откако ќе се прифати врската на работничка нишка, таа никогаш не ја напушта таа нишка. Целата понатамошна обработка на врската се обработува целосно во работниот конец, вклучувајќи го секое однесување за препраќање.

Ова има неколку важни последици:

• Сите базени за поврзување во Envoy се доделени на работничка нишка. Значи, иако базените за поврзување HTTP/2 прават само една врска со секој нагорен хост во исто време, ако има четири работни нишки, ќе има четири HTTP/2 конекции по upstream домаќин во стабилна состојба.
• Причината зошто Envoy работи на овој начин е тоа што со задржување на сè на една работничка нишка, речиси целиот код може да се напише без блокирање и како да е со една нишка. Овој дизајн го олеснува пишувањето многу кодови и неверојатно добро се размерува на речиси неограничен број работни нишки.
• Сепак, еден од главните чекори е дека од гледна точка на мемориски базен и ефикасност на поврзувањето, всушност е многу важно да се конфигурира --concurrency. Ако имате повеќе работни нишки отколку што е потребно, ќе ја потрошите меморијата, ќе создаде повеќе врски во мирување и ќе ја намали стапката на здружување на конекциите. Во Lyft, контејнерите на нашите пратенички странични кола работат со многу мала паралелност, така што перформансите грубо се совпаѓаат со услугите до кои седат. Ние работиме на Envoy како прокси на работ само при максимална истовременост.

Што значи неблокирање?

Терминот „не-блокирање“ е користен неколку пати досега кога се дискутираше за тоа како функционираат главните и работните нишки. Целиот код е напишан под претпоставка дека ништо никогаш не е блокирано. Сепак, ова не е целосно точно (што не е целосно точно?).

Envoy користи неколку долги процесни брави:

• Како што беше дискутирано, кога се пишуваат дневници за пристап, сите работни нишки го добиваат истото заклучување пред да се пополни баферот за дневници во меморијата. Времето на држење на бравата треба да биде многу ниско, но можно е бравата да се оспорува при висока истовременост и висока пропусност.
• Envoy користи многу сложен систем за да се справи со статистиката што е локална на нишката. Ова ќе биде тема на посебен пост. Сепак, накратко ќе спомнам дека како дел од локалното обработување на статистиката на нишките, понекогаш е неопходно да се стекне брава на централна „статистика“. Ова заклучување никогаш не треба да се бара.
• Главната нишка периодично треба да се координира со сите работнички нишки. Ова се прави со „објавување“ од главната нишка до работничките нишки, а понекогаш и од работните нишки назад до главната нишка. Испраќањето бара заклучување за да може објавената порака да се чека на ред за подоцнежна испорака. Овие брави никогаш не треба сериозно да се оспоруваат, но сепак технички можат да бидат блокирани.
• Кога Envoy пишува дневник на протокот на системски грешки (стандардна грешка), тој добива заклучување на целиот процес. Општо земено, локалната сеча на Envoy се смета за ужасна од гледна точка на изведбата, така што не се посвети многу внимание на нејзиното подобрување.
• Постојат неколку други случајни брави, но ниту една од нив не е критична за перформансите и никогаш не треба да се оспорува.

Локално складирање на нишки

Поради начинот на кој Envoy ги одвојува одговорностите на главната нишка од одговорностите на работниот конец, постои услов да може да се изврши сложена обработка на главната нишка и потоа да се обезбеди на секоја работничка нишка на многу истовремен начин. Овој дел го опишува локалното складирање на Envoy Thread (TLS) на високо ниво. Во следниот дел ќе опишам како се користи за управување со кластер.


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

Системот TLS (Thread local storage) на Envoy работи на следниов начин:

• Кодот што работи на главната нишка може да одвои слот за TLS за целиот процес. Иако ова е апстрахирано, во пракса тоа е индекс во вектор, обезбедувајќи O(1) пристап.
• Главната нишка може да инсталира произволни податоци во својот слот. Кога ова е направено, податоците се објавуваат во секоја работничка нишка како нормален настан на циклусот на настани.
• Работничките нишки можат да читаат од нивниот слот за TLS и да ги преземат сите локални податоци што се достапни таму.

Иако е многу едноставна и неверојатно моќна парадигма, таа е многу слична на концептот на блокирање RCU (Read-Copy-Update). Во суштина, работните нишки никогаш не гледаат никакви промени на податоци во слотови TLS додека работи работата. Промената се случува само во периодот на одмор помеѓу работните настани.

Претставникот го користи ова на два различни начини:

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

Ниво за ажурирање на кластерот

Во овој дел, ќе опишам како се користи TLS (локално складирање на нишки) за управување со кластер. Управувањето со кластерот вклучува xDS API и/или DNS обработка, како и здравствена проверка.


Управувањето со протокот на кластерот ги вклучува следните компоненти и чекори:

1. Управувачот со кластери е компонента во рамките на Envoy што управува со сите познати кластери нагоре, API-то на услугата за откривање кластери (CDS), API-то на услугата за тајно откривање (SDS) и услугата за откривање крајна точка (EDS), DNS и активните надворешни проверки на здравјето. Тој е одговорен за создавање „евентуално конзистентен“ приказ на секое горно кластер, кое ги вклучува откриените домаќини, како и здравствената состојба.
2. Здравствениот проверувач врши активна здравствена проверка и ги известува промените на здравствената состојба до менаџерот на кластерот.
3. CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS се вршат за да се одреди членството во кластерот. Промената на состојбата се враќа на менаџерот на кластерот.
4. Секоја работничка нишка континуирано извршува циклус на настани.
5. Кога менаџерот на кластерот ќе утврди дека состојбата на кластерот е променета, тој создава нова слика само за читање на состојбата на кластерот и ја испраќа до секоја работничка нишка.
6. Во текот на следниот тивок период, работничката нишка ќе ја ажурира снимката во доделениот слот за TLS.
7. За време на I/O настан што треба да го одреди балансот на домаќинот за вчитување, балансерот на оптоварување ќе побара слот TLS (Thread local storage) за да добие информации за домаќинот. Ова не бара брави. Забележете исто така дека TLS исто така може да активира настани за ажурирање, така што балансирачите на оптоварување и другите компоненти можат повторно да пресметуваат кешови, структури на податоци итн. Ова е надвор од опсегот на овој пост, но се користи на различни места во кодот.

Користејќи ја горенаведената процедура, Envoy може да го обработи секое барање без никакво блокирање (освен како што е опишано претходно). Настрана од сложеноста на самиот TLS код, поголемиот дел од кодот не треба да разбере како функционира мултинишката и може да се напише со една нишка. Ова го олеснува пишувањето на поголемиот дел од кодот, покрај супериорните перформанси.

Други потсистеми што користат TLS

TLS (Thread local storage) и RCU (Read Copy Update) се широко користени во Envoy.

Примери за употреба:

• Механизам за промена на функционалноста за време на извршувањето: Тековната листа на овозможена функционалност се пресметува во главната нишка. Секоја работничка нишка потоа добива слика само за читање користејќи RCU семантика.
• Замена на табелите на маршрутата: За табелите за маршрути обезбедени од RDS (Услуга за откривање маршрути), табелите за маршрути се креираат на главната нишка. Снимката само за читање последователно ќе биде обезбедена за секоја работничка нишка користејќи RCU (Read Copy Update) семантика. Ова го прави менувањето на табелите на рути атомски ефикасни.
• Кеширање на заглавието на HTTP: Како што се испоставува, пресметувањето на заглавието на HTTP за секое барање (додека работи ~25K+ RPS по јадро) е прилично скапо. Envoy централно го пресметува заглавието приближно на секои половина секунда и го обезбедува на секој работник преку TLS и RCU.

Има и други случаи, но претходните примери треба да дадат добро разбирање за што се користи TLS.

Познати стапици на перформансите

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

• Како што е опишано во овој напис, моментално сите работни нишки добиваат заклучување кога пишуваат во меморискиот бафер за дневник за пристап. При висока конкурентност и висока пропусност, ќе треба да ги групирате дневниците за пристап за секоја работничка нишка на сметка на ненарачана испорака при запишување во конечната датотека. Алтернативно, можете да креирате посебен дневник за пристап за секоја работничка нишка.
• Иако статистиките се високо оптимизирани, при многу висока истовременост и пропусната моќ, најверојатно, ќе има атомска расправа за поединечни статистики. Решението за овој проблем е бројачи по работничка нишка со периодично ресетирање на централните бројачи. За ова ќе се дискутира во наредниот пост.
• Сегашната архитектура нема да работи добро ако Envoy се распореди во сценарио каде што има многу малку врски кои бараат значителни ресурси за обработка. Не постои гаранција дека врските ќе бидат рамномерно распоредени меѓу работните нишки. Ова може да се реши со спроведување на балансирање на работните врски, што ќе овозможи размена на врски помеѓу работните нишки.

Заклучок

Моделот на нишки на Envoy е дизајниран да обезбеди леснотија на програмирање и масовен паралелизам на сметка на потенцијално непотребната меморија и врски, доколку не се правилно конфигурирани. Овој модел му овозможува да работи многу добро при многу висок број на нишки и пропусната моќ.
Како што накратко спомнав на Твитер, дизајнот може да работи и на мрежен стек со целосен кориснички режим, како што е DPDK (Комплет за развој на рамнина на податоци), што може да резултира со конвенционални сервери кои ракуваат со милиони барања во секунда со целосна обработка L7. Ќе биде многу интересно да се види што ќе се изгради во следните неколку години.
Еден последен брз коментар: многупати ме прашуваа зошто избравме C++ за Envoy. Причината останува тоа што тој сè уште е единствениот широко користен индустриски јазик на кој може да се изгради архитектурата опишана во овој пост. C++ дефинитивно не е погоден за сите, па дури и за многу проекти, но за одредени случаи на употреба сепак е единствената алатка за да се заврши работата.

Врски до кодот

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

• github.com/lyft/envoy/blob/master/include/envoy/thread_local/thread_local.h
• github.com/lyft/envoy/blob/master/source/common/thread_local/thread_local_impl.h
• github.com/lyft/envoy/blob/master/include/envoy/upstream/cluster_manager.h
• github.com/lyft/envoy/blob/master/source/common/upstream/cluster_manager_impl.h

Извор: www.habr.com